On Jan 4, 2011, at 10:44 PM, John Levine wrote:
NXDOMAIN for c.b.a simply means that there is no RR for c.b.a.
It tells you absolutely nothing about the existence of an RR for
d.c.b.a, and any recursive resolver that synthesized results for such
based on any RRset for c.b.a would be, simply, broken.
You might want to look at RFC 4592, particularly section 2.2.2,
which explains this corner of DNS arcana and the difference between
NOERROR and NXDOMAIN.
4592 is contradicted by some other RFCs and, more importantly, by
common behavior.
What's "correct" behaviour would be an interesting thing to bring
up with the IETF DNS folks (pick a standard, any standard), but
what's implemented is what's important when it comes to relying
on that behaviour.
I agree that synthesizing results would be risky, since there is a
substantial amount of DNS software that doesn't properly report the
difference between NOERROR and NXDOMAIN. If DNS servers followed the
specs, it should work, perhaps in a more perfect world than this one.
The authoritative nameservers I've used recently all do the "right thing"
there: no RRs => NXDOMAIN. And the recursive servers I have handy
also do the "right thing" and don't synthesize fake answers.
For layering something on top of DNS the deployed implementation is
the only spec that matters - what's implemented trumps what would be nice.
With that said, I still like my b-tree hack, which makes queries that
shouldn't get either NOERROR or NXDOMAIN, a lot better as a way to
publish ranges of addresses in a DNSxL.
If you're going to the effort of adding that much functionality
at the client end, switching to a better matched protocol instead
might be better. All the high traffic DNSBL users already use
a push protocol of sorts. Moving to a better, more standardized
one might be a win. A local server for protocol X could still offer
a DNS interface to the MTA to ease implementation
Cheers,
Steve
[1] and potentially CNAMEs and suchlike.
[2] or maybe a delegation, if there's a domain cut somewhere above
c.b.a.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg