On 25/02/2013 17:27, Paul Wouters wrote:
On Mon, 25 Feb 2013, Olafur Gudmundsson wrote:
You have to be more strict then just "validation succeeds". You MUST
ensure the proper DNSKEY's matching the CDS records exist on ALL
secondary servers, and must wait AT LEAST a TTL time before being
willing to update the DS record.
New version says:
If present the Parental Agent MUST validate [<xref
target="RFC4035"></xref>] the CDS RRset. If the validation
succeeds
with a DNSKEY that is represented in the current DS RRset in
parent.
Hope that is strong enough
I'm not sure. I don't see RFC 4035 talking about what a recursor should
do when it needs to find DNSKEY x1 and it contacts a (random) child name
server and x1 is not there. Is that a bogus response, or will it try the
other child name servers in an attempt to find the x1 DNSKEY?
local policy for each validator implementation possibly configurable and
possibly
affected on what is observed, the general principle is "If it validates:
done"
in your example it is not clear if the DNSKEY RRset validates
but is missing the key you are looking for.
or if you expect the set to be validated by key x1.
I think for a name server to roll its DS for the child, it should really
ensure the CDS records point to DNSKEYs that have been available in the
child zone for TTL(DNSKEY) time on _all_ child zone name servers.
I realized that while we can add that as guidance there is a missing
part of the rule in the draft:
The Parental Agent MUST/SHOULD make sure that replacing the DS with the
CDS will not break the
delegation. (Principle: Child can shoot itself in the foot but Parent
should avoid to harm Child)
This might be different from the "regular" policy of DNSSEC capable
resolvers.
Paul
Olafur
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
