Мне было интересно, как проверяющие резолверы работают с несколькими записями DS. Допустим, у нас есть зона с одним KSK и одним ZSK, но после некоторых махинаций по смене ключей в родительской зоне появляются две записи DS: одна указывает на текущий KSK, а другая - на более старый, больше не публикуемый KSK.
Будет ли распознаватель игнорировать старую запись DS и проверять зону до тех пор, пока набор DNSKEY RRset подписан ключом, на который указывает хотя бы одна из записей DS в родительском элементе?
Большинство операторов ожидают, что сирота DS запись будет проигнорирована. Множественный DS RR, один или несколько из которых могут не совпадать с соответствующими DNSKEY RRset, и это хорошо задокументировано.
https://tools.ietf.org/html/rfc4035#section-2.4
2.4. Including DS RRs in a Zone
The DS resource record establishes authentication chains between DNS
zones. A DS RRset SHOULD be present at a delegation point when the
child zone is signed. The DS RRset MAY contain multiple records,
each referencing a public key in the child zone used to verify the
RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS
RRsets MUST NOT appear at a zone's apex.
A DS RR SHOULD point to a DNSKEY RR that is present in the child's
apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
by the corresponding private key. DS RRs that fail to meet these
conditions are not useful for validation, but because the DS RR and
its corresponding DNSKEY RR are in different zones, and because the
DNS is only loosely consistent, temporary mismatches can occur.
Это устанавливает, что несколько DS RR разрешены, и что каждый из этих RR SHOULD быть подписанным соответствующим DNSKEY RR. Хотя точное поведение при встрече с сиротой DS RR не оговаривается явным образом, установлено, что несоответствия могут иметь место и действительно происходят, и их следует ожидать.
Наконец, из признания можно сделать вывод, что DNS is only loosely consistent что ожидания обратного ошибочны. Таким образом, можно было бы написать реализацию валидатора, которая отбрасывает зону как фиктивную, но это было бы не очень полезно. В конце концов, основными факторами, которые следует учитывать, является то, подписана ли зона и есть ли действительный криптографический путь между DS RRset и подписанные RR.
https://tools.ietf.org/html/rfc6840#section-5.11
5.11. Mandatory Algorithm Rules
The last paragraph of Section 2.2 of [RFC4035] includes rules
describing which algorithms must be used to sign a zone. Since these
rules have been confusing, they are restated using different language
here:
The DS RRset and DNSKEY RRset are used to signal which algorithms
are used to sign a zone. The presence of an algorithm in either a
zone's DS or DNSKEY RRset signals that that algorithm is used to
sign the entire zone.
A signed zone MUST include a DNSKEY for each algorithm present in
the zone's DS RRset and expected trust anchors for the zone. The
zone MUST also be signed with each algorithm (though not each key)
present in the DNSKEY RRset. It is possible to add algorithms at
the DNSKEY that aren't in the DS record, but not vice versa. If
more than one key of the same algorithm is in the DNSKEY RRset, it
is sufficient to sign each RRset with any subset of these DNSKEYs.
It is acceptable to sign some RRsets with one subset of keys (or
key) and other RRsets with a different subset, so long as at least
one DNSKEY of each algorithm is used to sign each RRset.
Likewise, if there are DS records for multiple keys of the same
algorithm, any subset of those may appear in the DNSKEY RRset.
This requirement applies to servers, not validators. Validators
SHOULD accept any single valid path. They SHOULD NOT insist that all
algorithms signaled in the DS RRset work, and they MUST NOT insist
that all algorithms signaled in the DNSKEY RRset work. A validator
MAY have a configuration option to perform a signature completeness
test to support troubleshooting.
Здесь общая картина становится более ясной; валидаторы не должны следить за всеми возможными перестановками DS и DNSKEY. Самая важная деталь - существует ли действительный путь.