Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness

In message <39328.1298474414@nsa.vix.com>, Paul Vixie writes:
> > From: Florian Weimer <fweimer@bfk.de>
> > Date: Wed, 23 Feb 2011 10:44:36 +0000
> > 
> > > while i'd like the DNSSEC solution you propose to also be done, i note
> > > that RBLDNSD operators are among the most technically adept name server
> > > operators in the history of the internet.  a campaign to get this
> > > software patched and to get upgrades installed would have a very short
> > > tail (shorter than the BIND4 AXFR example cited earlier).
> > 
> > For a while, I've been sitting on another rbldnsd/resolver interaction
> > bug and have been given the run-around so far.  I'm not convinced that
> > deploying new code is simple.
> 
> sometimes it takes a code fork if the author is no longer supporting a thing
> .
> 
> > > this does seem to me worth doing since i'm not expecting all zones
> > > to be signed and since the specification with respect to empty
> > > non-terminals was never unclear.
> > 
> > If it wasn't unclear, why did almost everyone implement the old behavior?
> 
> who is everyone?  i don't think bind or nominum or microsoft's or
> american internet's (now cisco's) authority servers have ever sent
> nxdomain on an empty non-terminal, and for a long time that was 100%
> of the market.  nlnetlabs nsd and verisign atlas both understood the
> spec in this regard also.

The early DNSSEC RFCs specified that NXDOMAIN was to be returned
and named did.  It took some arguing by me, internally and then to
dnsext, to get that reversed.  While this is listed as a bug it was
a protocol bug which was then corrected in code.

1416.   [bug]           Empty node should return NOERROR NODATA, not NXDOMAIN.
                        [RT #4715]

> the behaviour everyone implemented was on the initiator side, wherein
> they did not stop a downward traversal on a cached nxdomain, even with
> an rfc 2308 proof in cache, thus shortcutting iteration and forwarding.
> the specification was not ambiguous on this point; it was utterly silent.
> however, given that the authority server's behaviour (send NOERROR with
> ANCOUNT=0) has always been unambiguous, this silence looks like a missed
> implication to me rather than omission by intent.
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org