I think that...

A DNS server is always supposed to answer a query with the best
available data, with best being defined as most trustworthy. (I have
been using "credible" for a while by mistake, I should have been
saying "trustworthy.") BTW, It sounds like there is a small problem
with RFC 2181, 5.4.1. Where "glue" is mentioned, it should be "glue
and zone cut [NS Set]" data.

What this means is that no matter what the setting of the RD is the
server ought to answer with the learned NS set over the authoritative
NS set when the learned set is more trustworthy. (Applying to the
case where the QNAME is a zone cut, etc.)

It's tempting to make (a) DNS (server) be able to answer with the
authoritative data when RD=0 and the learned data when RD=1, but I'd
say this is a "siren's call."

1) Wanting to know the authoritative data in this case is something
only a maintainer or reverse engineer would want to do. (I.e., it's

2) It's more work that just meeting the mission of a simple lookup
service. I.e., Complicates the code (to achieve the unusual case).

3) Let's keep the design such that servers are as aggressive as
possible in returning the final result quickly. (No one likes a slow

As far as clarification ... to me this is pretty clear. However, I
won't say "don't clarify this" because clarity is in the eye of the
beholder and clarity doesn't mean "right." (Ignorance is bliss and
all that.)

I'm no longer against mixing caching and authoritative servers. I
think that the reasons once used to justify separating the two have
largely vanished. I think that there are now valid reasons to
combine them into one (at times).
Edward Lewis +1-571-434-5468

Nothin' more exciting than going to the printer to watch the toner drain...

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.