In message <[email protected]>, Ted Lemon writes: > > 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 p > araphrase 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 b > e 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 a > nd !kk->m rules are mutually inconsistent. Do you store inconsistent > data? If asked about "m" do you answer "NXDOMAIN" or go recu > rse to find out the answer? Do you flush any specific NXDOMAIN entries > you have in your O(1) cache that might be affected (maybe y > ou made them for performance reasons), or do changes to the tree only > affect new resolutions?
Well the DLV code, which does do aggresssive negative caching, looks for the NSEC which sorts before the QNAME and uses it to determine if it needs to make a query (is the QNAME covered by the record). You don't have to be perfect as the DNS is loosely coherent, you just need to return a self consistent proof. DLV doesn't have wildcards so it is a little easier but the principle is the same. > 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 maintenanc > e can affect multiple nodes in the tree, as any new truth you learn from > the authority can be inconsistent with some sequence of th > ings you already know. No, you don't need to do that. Just let the negative answer expire when they are scheduled to do so based on TTL. > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
