IPv6 client and negative cache - some doubts

[Sam Wilson]

In article <mailman.529.1266923597.21153.bind-users at lists.isc.org>,
 Michal Wesolowski <gmickyw at gmail.com> wrote:

> Hello Everyone
> 
> I have a problem with Bind 9.3.6-P1 (included in Solaris 10) but honestly I
> don't even understand if it is wrong Bind behaviour or my ignorance. It does
> apply only to some specific cases when external domain delegation is also
> somewhat broken. My server is caching only. Let me show it by the example:
> 
> Host "www.goleszow.pl" has bad NS delegation on country root servers level
> because virtual.sincom.pl is not resolvable:
> 
> goleszow.pl.        86400    IN    NS    virtual.sincom.pl.
> goleszow.pl.        86400    IN    NS    virtual.jasnet.pl.
> ;; Received 91 bytes from 149.156.1.6#53(G-DNS.pl) in 19 ms

That may be part of the problem, and it needs to be fixed, but I don't 
think that's all of it.

> When dns client asks my server for A record of "www.goleszow.pl" -
> everything is fine. But when first query (after cache is flushed) asks for
> AAAA record - my server seems to cache negative answer and all subsequent
> queries for A record also fails. ...
> [snip]
> This is what I found in the Bind cache:
> # rndc dumpdb -all
> # cat /var/named/log/named_dump.db | grep virt
> goleszow.pl.            85994   NS      virtual.jasnet.pl.
>                         85994   NS      virtual.sincom.pl.
> virtual.jasnet.pl.      3194    A       85.202.208.254
> virtual.sincom.pl.      3194    \-ANY   ;-$NXDOMAIN
> ; virtual.jasnet.pl alias jasnet.pl [v4 TTL 3194] [target TTL 3194] [v4
> success] [v6 unexpected]
> ; virtual.sincom.pl [v4 TTL 3194] [v6 TTL 3194] [v4 nxdomain] [v6 nxdomain]
> 
> Which for me doesn't explain this behaviour. Please advice.

Note that line beginning "virtual.jasnet.pl alias jasnet.pl".  jasnet.pl 
is delegated to ns10.az.pl and ns11.az.pl.  If you ask them for an A 
record for virtual.jasnet.pl you get an A record; if you ask for AAAA 
you get a CNAME pointing to jasnet.pl.  I can't imagine what sort of 
configuration could cause that to happen.  I'm also not sure how that 
might be screwing up your lookups, but it's certainly weird.  On the 
'fix what you know to be broken' principle I'd try to get that and the 
broken delegation sorted first before looking any further.

Sam


$ dig virtual.jasnet.pl @ns11.az.pl          

; <<>> DiG 9.3.6-APPLE-P2 <<>> virtual.jasnet.pl @ns11.az.pl
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47757
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;virtual.jasnet.pl.             IN      A

;; ANSWER SECTION:
virtual.jasnet.pl.      3600    IN      A       85.202.208.254

;; Query time: 43 msec
;; SERVER: 62.146.68.200#53(62.146.68.200)
;; WHEN: Tue Feb 23 12:24:05 2010
;; MSG SIZE  rcvd: 51

$ dig virtual.jasnet.pl @ns11.az.pl aaaa

; <<>> DiG 9.3.6-APPLE-P2 <<>> virtual.jasnet.pl @ns11.az.pl aaaa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13425
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;virtual.jasnet.pl.             IN      AAAA

;; ANSWER SECTION:
virtual.jasnet.pl.      3600    IN      CNAME   jasnet.pl.

;; AUTHORITY SECTION:
jasnet.pl.              3600    IN      SOA     ns10.az.pl. admin.az.pl. 
2009091500 10800 3600 604800 3600

;; Query time: 44 msec
;; SERVER: 62.146.68.200#53(62.146.68.200)
;; WHEN: Tue Feb 23 12:24:09 2010
;; MSG SIZE  rcvd: 99