ANY queries and Recursion

[Mark.Andrews at nominum.com]

> 
> 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 tha
> t
> 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* answe
> rs
> to the query. The nameserver, after all, is not obligated to seek out the bes
> t
> _possible_ answer to a QTYPE=* query, even if it's providing recursive servic
> e.
> If an application has such rigorous requirements, then it should implement it
> s
> own full-service resolver; stub resolvers were intended only for simple queri
> es
> and responses.
> 
> 
> - Kevin

	On top of that, caching of ANY queries, if they were required to be
	complete answers (all rrsets), would be incredibly complicated for
	almost no benefit.

	Mark
> 
> 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 an
> d
> > eventually Additional sections.
> >
> > If you look at the resolver algorithm in RFC 1034 page 34, the resolver jus
> t
> > 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 i
> t
> > 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
> 
> 
> 
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com