[nsd-users] aa flag not set

[Camiel Dobbelaar]

I see that this was a fix in 3.2.9.  We're on 3.2.8.

We'll do the upgrade first, sorry for the noise.  :-)

Regards,
Camiel


On 19-4-2012 13:05, Camiel Dobbelaar wrote:
> 
> We have problems with the following zone, which is configured for a
> "netscaler".  ( http://support.citrix.com/article/CTX124727 )
> 
> (obfuscated and shortened, real domain/zone on request)
> 
> domain.                 2560    SOA     ns.sentia.nl. postmaster.domain.
> 161803399 16384 2048 1048576 2560
> 
> domain.                 259200  NS      ns.sentia.nl.
> domain.                 259200  NS      ns2.sentia.nl.
> domain.                 259200  NS      ns.sentia.net.
> 
> gslb.domain.                    NS      ns1.gslb.domain.
> 
> ns1.gslb.domain.                A       1.1.1.1
> 
> portal0.domain.                 CNAME   portal0.gslb.domain.
> 
> 
> The point is that queries for "portal0.domain" should ultimately be
> answered by the nameserver running on the loadbalancer, so the gslb
> subdomain is delegated to the loadbalancer.
> 
> 
> Here's what we think is the problem.  NSD does not set the 'aa' flag
> when asked for "portal0.domain".  It does try to be helpful with other
> records though.
> 
> ; <<>> DiG 9.4.2-P2 <<>> @ns.sentia.net portal0.domain
> ; (1 server found)
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64200
> ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; QUESTION SECTION:
> ;portal0.domain.                IN      A
> 
> ;; ANSWER SECTION:
> portal0.domain. 86400   IN      CNAME   portal0.gslb.domain.
> 
> ;; AUTHORITY SECTION:
> gslb.domain.    86400   IN      NS      ns1.gslb.domain.
> domain.         259200  IN      NS      ns.sentia.nl.
> domain.         259200  IN      NS      ns2.sentia.nl.
> domain.         259200  IN      NS      ns.sentia.net.
> 
> ;; ADDITIONAL SECTION:
> ns1.gslb.domain.        86400   IN      A       1.1.1.1
> 
> ;; Query time: 19 msec
> ;; SERVER: 85.158.166.69#53(85.158.166.69)
> ;; WHEN: Thu Apr 19 12:54:02 2012
> ;; MSG SIZE  rcvd: 188
> 
> 
> When asking explicitly for a cname it _does_ set the aa flag:
> 
> ; <<>> DiG 9.4.2-P2 <<>> @ns.sentia.net cname portal0.domain
> ; (1 server found)
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34697
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
> 
> ;; QUESTION SECTION:
> ;portal0.domain.                IN      CNAME
> 
> ;; ANSWER SECTION:
> portal0.domain. 86400   IN      CNAME   portal0.gslb.domain.
> 
> ;; AUTHORITY SECTION:
> domain.         259200  IN      NS      ns.sentia.nl.
> domain.         259200  IN      NS      ns2.sentia.nl.
> domain.         259200  IN      NS      ns.sentia.net.
> 
> ;; Query time: 16 msec
> ;; SERVER: 85.158.166.69#53(85.158.166.69)
> ;; WHEN: Thu Apr 19 12:55:11 2012
> ;; MSG SIZE  rcvd: 154
> 
> 
> This causes problems for a Bind9 resolver.  When we flush the cache it
> cannot resolve "portal0.domain".  Only after asking for the cname
> explicitly first, it can subsequently be resolved.
> 
> One more data point: a dnscache resolver does not seem to have a problem
> with it.
> 
> 
> Regards,
> Camiel
> 
> 
> 
> _______________________________________________
> nsd-users mailing list
> nsd-users at NLnetLabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/nsd-users