only the response has aa flag can be cached?

Mark Andrews marka at isc.org
Wed Jan 12 03:15:22 UTC 2011


In message <4D2D0689.7010101 at chrysler.com>, Kevin Darcy writes:
> The answers will be cached regardless of the setting of the AA flag. I 
> would suspect that most -- or at least a large percentage -- of DNS 
> queries made by endpoint clients are to upstream resolvers which don't 
> happen to be authoritative for the zone(s) in question, so AA=0 is very 
> common in practice and lookup caching wouldn't work very well if it were 
> limited to only AA=1 responses.

Authoritative servers should be setting "aa" in their responses if
it is a answer and not a referral (RFC 1034).  Referrals don't have
normally have "aa" set, the exception is for out of zone CNAME/DNAME
responses where "aa" should be set for the CNAME/DNAME and a referral
is returned as well.

There are also some older servers that are broken, BIND 4/8 failed
to set "aa" for CNAMES (fixed in later versions) and promoted glue
to answer without setting "aa" when offering recursive service to
the client.

Then there are a few authoritative servers that don't set "aa" even
on responses to A queries.  These triggered the release of 9.7.2-P1
when we were rejecting these after tightening the response processing
to treat glue to answer responses as referrals to address the issue
of named return glue records from the parent zones rather than the
actual answers in the child zones.  After that we shouldn't have
needed to accept non "aa" answers.

> Note that if a "full" resolver gets "better" data in a DNS response than 
> what it has already cached, it may overwrite the existing cache data 
> with the new data. The determination of what is "better" is spelled out 
> in the data ranking rules in RFC 2181 and isn't directly related to the 
> setting of the AA flag. Among other things, this means that when 
> following a delegation chain, the NS records directly from the 
> authoritative nameservers for a zone, if available, will overwrite the 
> delegating NS records encountered earlier in the resolution process.
> 
>                                                                          
>                                                                          
>                                                      - Kevin
> 
> P.S. You did notice that you're performing recursive queries against 
> nameservers which don't offer recursion, right? That might be a possible 
> source of confusion.
> 
> On 1/4/2011 10:28 PM, pyh at mail.nsbeta.info wrote:
> > Hello,
> > I'm not sure about, is it true that only the response which has 
> > included the "aa" in flags can be cached by client DNS Cache?
> > For example, for my domain, there are two queries below, the result 
> > for the first query won't be cached, but the second will be cached, am 
> > I right?
> > $ dig mail.nsbeta.info ns @ns34.domaincontrol.com
> > ; <<>> DiG 9.4.2-P2 <<>> mail.nsbeta.info ns @ns34.domaincontrol.com
> > ;; global options:  printcmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12892
> > ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
> > ;; WARNING: recursion requested but not available
> > ;; QUESTION SECTION:
> > ;mail.nsbeta.info.              IN      NS
> > ;; ANSWER SECTION:
> > mail.nsbeta.info.       1800    IN      NS      dwdns2.nsbeta.info.
> > mail.nsbeta.info.       1800    IN      NS      dwdns1.nsbeta.info.
> > ;; ADDITIONAL SECTION:
> > dwdns2.nsbeta.info.     3600    IN      A       219.129.239.5
> > dwdns1.nsbeta.info.     3600    IN      A       120.132.133.48
> > --------------------------------------------------
> > $ dig mail.nsbeta.info ns @dwdns2.nsbeta.info
> > ; <<>> DiG 9.4.2-P2 <<>> mail.nsbeta.info ns @dwdns2.nsbeta.info
> > ;; global options:  printcmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28561
> > ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
> > ;; WARNING: recursion requested but not available
> > ;; QUESTION SECTION:
> > ;mail.nsbeta.info.              IN      NS
> > ;; ANSWER SECTION:
> > mail.nsbeta.info.       3600    IN      NS      dwdns1.nsbeta.info.
> > mail.nsbeta.info.       3600    IN      NS      dwdns2.nsbeta.info.
> > _______________________________________________
> > bind-users mailing list
> > bind-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> >
> >
> >
> 
> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



More information about the bind-users mailing list