Stephane Bortzmeyer wrote: > On Thu, Mar 10, 2016 at 12:59:49PM -0800, > internet-dra...@ietf.org <internet-dra...@ietf.org> wrote > a message of 47 lines which said: > > > Title : NXDOMAIN really means there is nothing underneath > > Filename : draft-ietf-dnsop-nxdomain-cut-01.txt > ... > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nxdomain-cut-01 > > Main change: reorganisation of the text so that the normative section > 2 is written in a purely protocol-behaviour way, without any reference > to the implementation. Section 5 now discuss implementation.
Hi, I agree with Ted Lemon's comments in this thread. Could the rule be relaxed so that the process of considering whether a cached NXDOMAIN in a parent zone is applicable to the name being looked up can be delayed until immediately prior to transmitting a query to an authoritative server? I.e., what would have traditionally been a cache miss can now be transformed into a cache hit at the last instant. That would move the O(number of labels) lookup from a hot path to a cold path, and there would be no need to argue about exactly how many nanoseconds the O(number of labels) lookup costs, because you were going to wait at least a few milliseconds on the network anyway. If you do it that way, however, a newly cached NXDOMAIN doesn't affect previous positively cached responses at all. This idea was brought up earlier and dismissed: Stephane Bortzmeyer wrote: > On Thu, Nov 12, 2015 at 06:13:04PM +0000, > Wessels, Duane <dwess...@verisign.com> wrote > a message of 57 lines which said: > > > Perhaps a recursive might be designed to negatively cache an entire > > zone (including TLD) but continue answering positively cached > > answers in the zone until they expire normally. > > Clever algorithm but I'm afraid it will make debugging more > difficult. Such a behaviour will be highly non-intuitive for the > user. (One of the motivations for NXDOMAIN cut is to make DNS behave > according to its data model, which is a tree.) (https://mailarchive.ietf.org/arch/msg/dnsop/JchUb-CvQVodkXJmxs1SR_0aIf8) But I'm not sure it should be dismissed so easily. The data model is a tree, yes, but caching up to the maximum TTL value allowed is permitted and widely expected, to the point that flushing the cache and trying again is often one of the first debugging steps performed. And debugging the DNS is already highly unintuitive and can already produce answers of... constrasting levels of coherence... especially when load-balancing is used for recursive service. -- Robert Edmonds _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
