Fwd: IPv6 client and negative cache - some doubts

Michal Wesolowski gmickyw at gmail.com
Tue Feb 23 14:00:24 UTC 2010


sorry for replying directly, still have some problems with gmail UI.

---------- Forwarded message ----------
From: Michal Wesolowski <gmickyw at gmail.com>
Date: Tue, Feb 23, 2010 at 2:47 PM
Subject: Re: IPv6 client and negative cache - some doubts
To: Sam Wilson <Sam.Wilson at ed.ac.uk>


On Tue, Feb 23, 2010 at 1:33 PM, Sam Wilson <Sam.Wilson at ed.ac.uk> wrote:

> 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
>
>
Thank you Sam for pointing this out. This is probably real source of the
problem. I looked over what could cause such situation and so far found old
bug in PowerDNS (but don't know if they use it!) which generated such
answers when using wildcards.

After some reading my present understanding is that correct response to AAAA
query when there is such record in the zone and there exists another record
of different type for the same name - is to reply with empty answer and no
error (this applies to authoritative NS). So what ns10.az.pl does is not
consistent with specification.
However I'm still not sure if bind shouldn't cope with this somehow. I
understand that if it applied to final query for "www.goliszew.pl" than it
would be correct for bind to cache it as negative for all types of records.
But if it concerns bad respond for NS? - I don't know.

Thanks

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


More information about the bind-users mailing list