Subject: using AA in queries

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 26 Jul 2000 13:26:44 -0700

Is there room in the protocol for allowing resolvers to demand that an
authoritative server be used to answer the query? For example, does it
make sense to allow resolvers to set AA in the query message, and for
compliant servers to recognize this bit as a demand that the query be
referred/forwarded to an authoritative server for the domain name?

Here's the scenario that prompted this: When sendmail tries to locate
the server for a mail domain, it issues a query for ANY in an effort to
get the A and MX records for the mail domain in a single response.
Currently, some servers will treat a query for ANY specially, and will
forward/refer the query to an authoritative server for the domain name,
while some other servers do not do this and will answer the query using
any data that is currently available in their cache (more often than not
this is NS data for the domain, provided by the servers for the parent
domain). In the latter case, sendmail has to deal with the incomplete
response by generating multiple unique queries that explicit request the
A and MX records for the domain.

The obvious solution to this point problem is to require that queries
for ANY be resolved by an authoritative server, although that seems like
a heavy-handed solution to this particular problem. Instead, a broader
solution would be to allow the client to specify Authority Required in
the query message by setting the AA flag in the query message.

This might also be useful for some of the security stuff, and might be
useful for many other application-specific problems as well (getting SOA
or RP records, for example). It might also be a way around some lameness
problems, if a resolver knows they can reissue a query with AA if the
original query seems to have failed for some reason.

If the server was unable/unwilling to comply, it could still respond
with AA cleared in the response message, and the resolver could either
(A) accept the answer anyway, or (B) try another server.

Is this a feasible extension? I'm sure somebody else has brought this up
in the past; why didn't it fly?

-- 
Eric A. Hall                                      http://www.ehsco.com/
Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Peter Koch <[email-masked]>
Date: Thu, 27 Jul 2000 11:38:25 +0200

> referred/forwarded to an authoritative server for the domain name?

For that to work sufficiently all the still very old systems in the field
(see e.g. Bill Manning's surveys) would have to be upgraded (silently
assuming that those "servers" also act as full resolvers). Apart from that
there are some drawbacks (see below).

> get the A and MX records for the mail domain in a single response.

Yes, and other MTAs act in a similar fashion, which sometimes leads to
problems if the result to an "ANY" query is larger than fits into a DNS
UDP packet.

> any data that is currently available in their cache (more often than not

RFC 1035 says "all", while "any" is usually implemented.

> A and MX records for the domain.

So that optimization turns out not to be one?

> the query message by setting the AA flag in the query message.

I see two alternatives: first, do not use the "ANY" trick; second (not yet
available): with multiple entries in the query section (EDNSx) it might
be possible to ask for "MX, else A". Anyway, even in the current situation,
the ANY query should only fail the first time (in a given interval) because
afterwards the MX RRSet sits in the local cache and will be delivered for
subsequent queries, whereas with your proposed solution all the queries
would hit the authoritative servers.

> (A) accept the answer anyway, or (B) try another server.

On the other hand it's likely to contribute to the problem should a resolver
insist on an authoritative answer in case of "perfectly lame" delegations.
We're seeing similar problems with negative answers every now and then.

> in the past; why didn't it fly?

I'd worry about the future of DNS caching once the news is spread that you
can request "more valuable" responses by setting the "AA" bit in the query.

-Peter

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 27 Jul 2000 11:06:48 -0700

Peter Koch made some excellent points:

> > make sense to allow resolvers to set AA in the query message, and
> > for compliant servers to recognize this bit as a demand that the
> > query be referred/forwarded to an authoritative server for the
> > domain name?
> 
> For that to work sufficiently all the still very old systems in the
> field (see e.g. Bill Manning's surveys) would have to be upgraded
> (silently assuming that those "servers" also act as full resolvers).

This isn't necessarily true. The only systems that would need to support
it are the stub resolvers that generate the queries, and the recursive
servers that process those queries. All of the other servers in the
world could be ignorant of the auth. desired mechanism, since only the
recursive server would have to find an AA answer. In essence, the
recursive server would ignore answers without AA set, and treat non-AA
answers with authoritative data as referrals until it got to one of
those authoritative servers.

> the ANY query should only fail the first time (in a given interval)
> because afterwards the MX RRSet sits in the local cache and will be
> delivered for subsequent queries, whereas with your proposed solution
> all the queries would hit the authoritative servers.

In the proposal outlined, the use of Auth Desired should be limited to
situations where a non-auth answer was already obtained that the client
application knew to be either incomplete or wrong. For example, query
for ANY results in incomplete answer, rather than following up with
multiple queries for A and MX, issue another query for ANY with the Auth
Desired flag set.

This argument admittedly has pretty weak legs. I suppose this is where
the idea really starts falling down, since we're back to multiple
queries already. If the auth. desired query failed, then discrete
queries would be necessary again, so extra cost would have been
introduced for no real gain in some situations where an AA answer was
not available.

> I'd worry about the future of DNS caching once the news is spread
> that you can request "more valuable" responses by setting the "AA"
> bit in the query.

Yeah, I guess. I'd think most implementations wouldn't bother with it,
and the only applications that would do anything special would be the
ones that needed absolute data. I guess my assumption is that most folks
would be too lazy to do the extra coding unless it was really important
for them to do it.

> > Currently, some servers will treat a query for ANY specially, and
> > will forward/refer the query to an authoritative server for the
> > domain name, while some other servers do not do this and will
> > answer the query using any data that is currently available in
> > their cache (more often than not
> 

OK. Maybe the letter of the law is that "all" implies processing by a
server that knows all records, not just any records.

An auth. desired flag might still be useful in some other situations. I
think you've successfully shot down this situation however.