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

[Paul Vixie <[e-mail]>]

> From: Florian Weimer <[e-mail]>
> 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 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.