TYPE=ANY and missing records

[Kevin Darcy]

Barry Margolin wrote:

> In article <812q76$36d$1 at nnrp1.deja.com>,  <greg_mcdermid at my-deja.com> wrote:
> >Problem is that any requests with TYPE=ANY seem
> >to only return the NS records - which is not good
> >as sendmail only requests ANY, then A (most
> >domains don't have an A record for their domain),
> >thus the mail simply queues up.

I just did a quick test, and, for me, sendmail (8.9.0) seems to be doing ANY/A/MX,
so I'm surprised you're having a problem unless you have misconfigured your
sendmail to not use MX records.

> If you're querying a caching server, an ANY query will return whatever
> happens to be in the cache for the name.  If the NS records are already in
> the cache (because you've looked up something within the domain), they'll
> be returned.  The caching server can't tell whether its information is
> complete without performing another recursive query, so the alternative
> would be for all ANY queries to force recursion, rather than using the
> cache, which would not be good.

Well, theoretically, named could keep track of whether anything relevant has been
removed from the cache since the last ANY query for a given name, so in the worst
case you'd only be recursing as often as the least-persistent matching RR times
out (since it'd refresh the TTL's on everything else). That would be quite a bit
of coding, I imagine, and I doubt anyone thinks it's worth the effort.

> Applications should generally *not* use ANY queries unless they know for a
> fact that they're querying an authoritative server rather than a caching
> server (i.e. they implement their own full resolver, rather than using a
> stub resolver)..

Not to disagree, but I think sendmail is an exception to that general rule, for
performance reasons.1. it usually only runs on machines which are capable of
running their own nameserver, and it's really cheap to send a query and response
over a local interface as long as no recursion is involved. 2.  the names sendmail
queries tend to "cluster", which makes for very good cache hit ratios. 3. sendmail
cares about multiple RR types (A & MX, to a lesser extent CNAME), so if it can
often get answers for both types with a single query (even from a
non-authoritative server), then that is a win, even if occasionally the first
query is wasted and it has to fallback to RR-specific queries anyway.


- Kevin