Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals

[Colm MacCárthaigh <[e-mail]>]

On Wed, Mar 30, 2011 at 3:48 PM, Paul Vixie <[e-mail]> wrote:
> if we don't want to do that with rbldnsd given its 0.00005% market share
> and that really is the consensus of the working group, we can remove the
> text.  i'd like to hear from different voices to help judge consensus.

The behavior isn't limited to rbldnsd. It is also manifest in TinyDNS,
and probably other non-tree-indexed implementations.

These implementations may not have a plurality of domain names on
them, but I think they do meet the "widely deployed" bar.

Given that, it seems imprudent for resolvers to make inferences about
empty sub-trees based merely on NXDOMAIN.

At least one EDNS0 capable implementation exists that exhibits this
behavior [1] . So for the moment, making inferences on EDNS0 also
seems unwise.

Making inferences based on returning DNSSEC data may be safe, I
haven't yet found any counter-examples. I wouldn't be surprised to
find one though.

My vote would be for;

  Recommending that authoritative servers implementing DNSSEC SHOULD
NOT return NXDOMAIN for non-terminal labels.

  Recommending that caches SHOULD NOT infer empty sub-trees based on NXDOMAIN.

My reason for saying "implementing DNSSEC" is that inferring sub-tree
emptiness is another dangerous poisoning case (along with spoofed
DNAME and NS responses) that can poison a very large name-space in a
cache for very low effort. DNSSEC is a reasonable mitigation against
that problem.

On the historical point, I don't agree with djb's interpretation of
RFC2308. That RFC says;

  "A negative answer that resulted from a name error (NXDOMAIN) should
   be cached such that it can be retrieved and returned in response to
   another query for the same <QNAME, QCLASS> that resulted in the
   cached negative response."

It doesn't say "only returned". To say that inferences about empty sub-trees
is "outlawed" goes too far. But I think there's so little clarity in
the standards, that
no particular "side" has great support there. Greater clarity from now
on will definitely help!

[1]   dig +edns=0 terminal-label.non-terminal.notesfromthesound.com
@ns-431.awsdns-53.com
       dig +edns=0 non-terminal.notesfromthesound.com @ns-431.awsdns-53.com

-- 
Colm