ANY queries and Recursion

[Kevin Darcy]

When a nameserver answers a QTYPE=* query non-authoritatively, it's answering
from whatever data happens to be in its cache which match QNAME. The fact that
the data got into the cache originally as a referral encountered while trying
to resolve the selfsame query doesn't seem particularly relevant to me. The
example in 6.3.1 -- an authoritative answer to an MX query -- isn't nearly as
relevant as the second and third examples in 6.2.2, which show
non-authoritative answers for a QTYPE=* query containing only *partial* answers
to the query. The nameserver, after all, is not obligated to seek out the best
_possible_ answer to a QTYPE=* query, even if it's providing recursive service.
If an application has such rigorous requirements, then it should implement its
own full-service resolver; stub resolvers were intended only for simple queries
and responses.


- Kevin

Dan Nicolae wrote:

> Hi,
>
> Can somebody explain how come that BIND (8.1.2) is returning Referrals to a
> Recursive query for ANY type?
>
> According to RFC1034, a recursive response to a query can be either an
> answer, a name error indicating that the name does not exist or a temporary
> error indication, but never a referral.
>
> I send a recursive ANY query to a BIND 8.1.2. recursive server. The query
> does not hit any useful data in intermediary caches and the server has to
> start from the root servers. The root servers return a referral.
>
> If you look at the server algorithm in RFC1034 page 24 (steps 1, 2, 3b then
> 6), the root server returns the Referral by filling in the Authoritative and
> eventually Additional sections.
>
> If you look at the resolver algorithm in RFC 1034 page 34, the resolver just
> accomplished steps 1, 2, 3 and 4b (it got a delegation from a root server).
> Now it should start over with step 2 (not step 1) and send the query to an
> authoritative name server. The cycle should end with steps 2, 3, 4a.
>
> You can also look at the example in RFC1034 section 6.3.1 page 47.
>
> If it were a query for something else than ANY, the recursive name server
> would go and query the name servers in the Authoritative section. But
> because it is an ANY query, the recursive name server is happy that it got
> the NS records (referrals) and it sends them back to my resolver, packaged
> in the Answer section so that they look like an Answer although they were
> referrals.
>
> I guess that the referral is returned to my stub resolver (dig or nslookup),
> because it is seen as being enough for an ANY query. The net result is that
> I get back a Referral. The response is not packaged as a referral because it
> has answers in the Answer section, but those answers originated from a
> Referral sent by a root server, so it is ultimately a Referral. Also, I
> can't find anywhere in the examples and algorithms in RFC1034 how come a
> Referral it's repackaged (by copying the Authority section in the Answer
> section) to look like an Answer and sent back to a stub resolver.
>
> Example: do a dig or nslookup for a domain name (ANY type). Make sure that
> you pick one that's not gonna hit any cache and it'll have to start at the
> root servers. Note that you get back only NS records although you are
> absolutely sure there are MX and SOS records.
>
> Is this BIND behavior consistent with RFC1034?
>
> Thanks,
> Dan