ANY queries and Recursion

[Kevin Darcy]

Dan Nicolae wrote:

> "Kevin Darcy" <kcd at daimlerchrysler.com> wrote in message
> news:3998B77B.2080B450 at daimlerchrysler.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.
>
> I made the assumption that there was no data in the cache. That's why the
> nameserver had to use a root name server.
> The NS records got in the cache after the Referral was returned from the
> root server.
> The problrm is that, according to the server algorithm in RFC1034, the
> nameserver is not supposed to check the cache again (and find the NS
> records) before going ahead and following the referrals.
>
> > 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.
>
> How the data got in the cache is not relevant. The question is when was it
> cached. If it were there previously I wouldn't have any problem. But it got
> there during the current query.

I understand where you're coming from, but my point is that it's all a matter
of interpretation. Implementations can fill their caches whenever they want,
however they want, using whatever algorithms they choose, RFC-sanctioned or
not, just as long as they follow a certain set of ground rules with respect to
the caching aspect of DNS. I don't know whether ISC makes this argument or not,
but they *could* say that the cache-fetching BIND performs in this situation is
technically unrelated to the query it has received. So the RFC algorithm
terminates at Step 1 because the cache entries already happen to be present.
There's nothing in the RFC, after all, that says all other activity with
respect to a particular name must be suspended between the time a query for the
name is received and when the query is resolved. It is expected that all sorts
of asynchronous events are going to be happening inside a nameserver at any
particular point in time. So some other algorithm just _happens_ to go out and
"spike" the cache before the official start of the RFC algorithm. Maybe it's a
little sleazy, but I don't think it technically violates the RFC.

> > 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.
>
> You're right those two examples are relevant. You can notice that the
> nameserver has at least a chance (first QTYPE=* query), when all caches in
> the path are empty, to return an authoritative, complete answer to my
> resolver. I the resolver sees that the response is authoritative it knows it
> originated from an authoritative name server, thus it can assume (with a
> reasonable doubt) that the response is also complete, and cease making extra
> queries on its own if ALL records are needed. In BIND's case, my resolver
> has no chance (well almost, it is still possible).
>
> > 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.
> >
>
> No doubt that the nameserver has no obligation. The only obligation I could
> see would be to follow the server algorithm in RFC1034.
>
> An application with such rigurous requirements would need to implement its
> own resolver anyway, that is correct. But, if BIND behaved exactly like the
> RFC1034 algorithm, the app could tell if the query worked just by checking
> the AA flag. If AA is set, the data is complete, no need to keep querying.
> If AA is not set, the data came from a cache and is possibly incomplete,
> query ahead.
>
> On the other hand, what if my app can't make queries outside the firewall? I
> must rely on the nameserver or I must give up on ANY queries and query for
> each individual type I want to get.
>
> >
> > - Kevin
> >
>
> Thanks, for the response. I got my answer, the issue I depicted is not seen
> as a BIND deviation from RFC1034.
> I agree with you that it is not a big deal, but I was just wondering what
> made BIND behave like that. Ease of implemenation rationale or else?

I think Mark Andrews has explained some of the technical difficulties involved
with implementing a more expansive QTYPE=* behavior. I think the bottom line is
that QTYPE=* isn't that common, and where it's used, it's used
opportunistically anyway -- the application will still go ahead and query
specific types anyway, if it needs to. At least I believe this is true of
sendmail.


- Kevin