different behavior: A Records in DNS answer, when query of type "any" (existing CNAME)

Kevin Darcy kcd at chrysler.com
Mon Mar 7 20:04:10 UTC 2011


On 3/7/2011 6:36 AM, Diezig Adrian wrote:
>
> Hi,
>
> I have a question concerning answers from DNS servers, when I query a 
> name with type "any" and the name is a CNAME.
>
> I have the following example (works also in Internet) with an ISC BIND 
> server (BIND 9.7.0-P1):
>
> ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> 
> @newton.genesiscom.ch dns.ipam.ch
>
> ; (1 server found)
>
> ;; global options:  printcmd
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25078
>
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
>
> ;dns.ipam.ch.                   IN      A
>
> ;; ANSWER SECTION:
>
> dns.ipam.ch.            600     IN      CNAME   www.ipam.ch.
>
> www.ipam.ch.            600     IN      A       81.18.25.238
>
> ;; Query time: 1 msec
>
> ;; SERVER: 10.10.3.13#53(10.10.3.13)
>
> ;; WHEN: Mon Mar  7 11:52:38 2011
>
> ;; MSG SIZE  rcvd: 63
>
> As you can see, we have a CNAME dns.ipam.ch that points to www.ipam.ch.
>
> www.ipam.ch is an A-Record to 81.18.25.238.
>
> When I do the following query (type=any to dns.ipam.ch), only the 
> CNAME itself will be in the answer section (the A-Record not):
>
> ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> 
> @newton.genesiscom.ch dns.ipam.ch any
>
> ; (1 server found)
>
> ;; global options:  printcmd
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46532
>
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
>
> ;dns.ipam.ch.                   IN      ANY
>
> ;; ANSWER SECTION:
>
> dns.ipam.ch.            600     IN      CNAME   www.ipam.ch.
>
> ;; Query time: 1 msec
>
> ;; SERVER: 10.10.3.13#53(10.10.3.13)
>
> ;; WHEN: Mon Mar  7 11:53:21 2011
>
> ;; MSG SIZE  rcvd: 47
>
That's valid response, albeit a little stingy. You asked about all 
records matching the name "dns.ipam.ch", and it gave you "all records".

Note that RFC 1034's "nameserver algorithm" (section 4.3.2) specifies 
that a query should be "restarted" if QNAME owns a CNAME RR "and QTYPE 
doesn't match CNAME". In a "normal" case, e.g. QTYPE=A, this means that 
the CNAME gets added to the Answer Section and then the query is 
"restarted", as if the target of the alias were QNAME. It either 
produces A records or it doesn't. But in this *special* case, QTYPE=* 
does in fact "match" the CNAME record found by the nameserver, therefore 
the query is not restarted. The nameserver just returns what is has -- 
i.e. the CNAME record -- and its job is done. It jumps to Step 6 of the 
algorithm: return the records along with any Additional Records that it 
deems "helpful", and exit.
>
> When I do a comparable query (also with type=any) to another DNS 
> Server (eg. google.com)....
>
> ; <<>> DiG 9.3.2 <<>> @ns1.google.com. www.google.com. any
>
> ; (1 server found)
>
> ;; global options:  printcmd
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1636
>
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
>
> ;www.google.com.                        IN      ANY
>
> ;; ANSWER SECTION:
>
> www.google.com.         604800  IN      CNAME   www.l.google.com.
>
> www.l.google.com.       300     IN      A       74.125.232.114
>
> www.l.google.com.       300     IN      A       74.125.232.115
>
> www.l.google.com.       300     IN      A       74.125.232.116
>
> www.l.google.com.       300     IN      A       74.125.232.113
>
> www.l.google.com.       300     IN      A       74.125.232.112
>
> ;; Query time: 46 msec
>
> ;; SERVER: 216.239.32.10#53(216.239.32.10)
>
> ;; WHEN: Mon Mar 07 09:44:32 2011
>
> ;; MSG SIZE  rcvd: 132
>
> ... I will get also the associated A Records.
>
Well, ns1.google.com coincidentally *happens* to also be authoritative 
for l.google.com, so it was able to provide the A records. It's 
arguable, however, whether it should have "restarted" the query or not 
(in the sense described above).
>
> Does anybody have an idea, why the behavior is different? Can I 
> configure this on my DNS Server (ISC BIND)?
>
> FYI:
>
> dig @ns1.hp.com. www.hp.com. any
>
> and
>
> dig @ns1.yahoo.com. www.yahoo.com any
>
Understand that ns1.hp.com is *not* authoritative for any A records 
owned by www.hp.com (the name is an alias to www.hpgtm.nsatc.net so the 
authoritative A records would be given from something hosting some 
descendant of nsatc.net), and ns1.yahoo.com is *not* authoritative for 
any A records owned by www.yahoo.com (which is an alias to 
fp.wg1.b.yahoo.com, at least when I query it; the exact target of the 
alias might depend on who is querying it).

> will also answer without any A-Records (like me).
>
> I have the following questions:
>
> -which one is correct (RFC)?
>
An ANY query should return A records if the nameserver being queried is 
actually authoritative for the name being queried and the name owns A 
records. But if -- as in your examples above -- the nameserver only 
holds an alias, it is under no obligation to go and fetch those A 
records on your behalf.
>
> -is it configurable in ISC BIND?
>
Nope.
>
> -does the behavior depends on different BIND version?
>
Nope. As far as I know, BIND has always been this way.
>
> I know that it is not very common to do queries with type any. The 
> problem we have is the following:
>
> A Device/Application in our network is doing always queries from type 
> "any".
>
> From our side it's not possible to change the type, because it's 
> hard-coded in the software.
>
Apparently the app made a bad assumption about how ANY queries work. 
Hopefully it at least has the sense to follow those non-productive ANY 
queries with explicit A/AAAA/MX/SRVwhatever queries for the data it's 
looking for.

                                                                         
                                                             - Kevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110307/bc9a00e2/attachment.html>


More information about the bind-users mailing list