In message <[email protected]>, "Paul Hoffman" writ es: > On 25 Feb 2016, at 12:20, Ted Lemon wrote: > > 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.
Why? The DNS is loosely coherent. There isn't any requirement for the SOA records from servers to be consitent so you can't tell which answer is the "newest" as apposed to which was returned the latest which you do know. They may not be the same. A sane implemention doesn't re-construct negative proofs sets. They store them as a set. These result in self consistent answers being returned. It also means that a cache can return answers that say a record does not exist and a also return the record at the same time depending upon which QNAME/QTYPE is being queries for. I can query for example/A and have a proof that says AAAA does not exist and at the same time query for example/AAAA and get a RRset as the cache has learnt the answers from two different version of the zone. This is expected behaviour from 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. With RFC 403[45] the answers to <QNAME,QTYPE,QCLASS> are independent of each other. There is no need to clean anything. About the only thing that happens is that when you learn about a NXDOMAIN it wipes out anything that is cached at that <QNAME,QCLASS>. This also what happens with RFC 103[45] but is implementation dependent. That the extent of the "cleaning" of other records that is potentially expected. Now caches could be made that don't do this cleaning (only cache NXDOMAIN against the <QNAME,QTYPE,QCLASS> tuple) or only see the NXDOMAIN if there is not a explict record cached for <QNAME,QTYPE,QCLASS> or clean out everything below a QNAME on NXDOMAIN (not currently specified behaviour). Some of this is like do you overwrite the delegating NS RRset when you get a answer from the child zone that contains a NS RRset in the authority section. There are implementations that do and implementations that don't. I'm actually fine with different behaviours in different implementations. I don't think there is a "correct" behaviour. Some of the behaviours result in resolution failing if the authoritative servers don't return consistent answers for the same instance of a zone but then you are dealing with a broken server / broke delegation. Mark > --Paul Hoffman > > _______________________________________________ > 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
