> 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?
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?
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.
Meanwhile at the authority, everything but @ is deleted.
You query for "b" and get "!@->@". Now you have to delete everything in the
tree. The point here is just that the tree maintenance can affect multiple
nodes in the tree, as any new truth you learn from the authority can be
inconsistent with some sequence of things you already know.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
