On 25 Feb 2016, at 12:20, Ted Lemon wrote:
Saying "without DNSSEC" doesn't seem like a better way to address any
problem...
Depends on how far in front of the horse you want to put the cart, I
guess. By "without DNSSEC," I mean "without requiring DNSSEC." Of
course we want DNSSEC, but it's not widely enough deployed yet to
really make a difference, is it?
How can one argue with logic like that? (That's a serious question.)
If a protocol requires DNSSEC (which more are these days), then only
systems that have DNSSEC can implement them. That's an operational
choice.
Or are you saying we should not deploy any protocols that require DNSSEC
(such as DANE) until some group decides that DNSSEC has been widely
enough deployed?
As for your question about complexity, I'm going to include an answer
from our engineering team here, because I don't think I can paraphrase
their explanation in a way that would improve on it:
Consider a zone with names "@", "aa", "bb", ... "zz". ("@" being "the
empty name", and I'm using relative names for brevity.)
You query for "m" and get an NSEC proving there's nothing between "ll"
and "mm", and a proof that there is no wildcard. Let this be denoted
by "!ll->mm" and "!@->aa".
Meanwhile, at the authority, "m" is added and "ll" is deleted.
You query for "l". The authority gives back "!kk->m" and "!@->aa".
How should you update your state as a resolver? The !ll->mm and
!kk->m rules are mutually inconsistent. Do you store inconsistent
data? If asked about "m" do you answer "NXDOMAIN" or go recurse to
find out the answer? Do you flush any specific NXDOMAIN entries you
have in your O(1) cache that might be affected (maybe you made them
for performance reasons), or do changes to the tree only affect new
resolutions?
RFC 4035 is silent on this situation, I believe. At least, I don't see
it covered in Section 4.5. Maybe this should be an update to RFC 4035.
IMO, the only "right" thing to do is to drop !ll->mm and keep !kk->m
since it is more recent. (In this example, we know it is more recent,
but in the real world how do you know you're not talking to a slave
that's behind? Are you meant to look at the serial in the SOA RR too
or signature expiration times?) I'm OK with not flushing things out
of the O(1) cache.
This sounds right, but I hope someone more familiar with RFC 403[3-5]
would chime in.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
