Fwd: IPv6 client and negative cache - some doubts

Kevin Darcy kcd at chrysler.com
Fri Feb 26 22:36:31 UTC 2010


As Mark explained, the server is marked as bad because it returned an 
illegal response.

If *all* of the nameservers which would be used to answer a particular 
query are marked as bad, then the query fails. This is as it should be.

The fact that you see some residue in the cache that _could_, in some 
way, shape or form, allow the query to be answered, doesn't change the 
fact that named doesn't trust nameservers that give illegal responses 
and is perfectly within its rights to avoid those nameservers for some 
period of time.

                                                                         
                                                                         
                                                                         
     - Kevin

On 2/24/2010 1:48 AM, Michal Wesolowski wrote:
> On Tue, Feb 23, 2010 at 11:19 PM, Mark Andrews <marka at isc.org 
> <mailto:marka at isc.org>> wrote:
>
>
>     In message
>     <f677fefa1002230600n4694161cu315e5dd4beaaab02 at mail.gmail.com
>     <mailto:f677fefa1002230600n4694161cu315e5dd4beaaab02 at mail.gmail.com>>,
>     Micha
>     l Wesolowski writes:
>     >
>     > sorry for replying directly, still have some problems with gmail UI.
>     >
>     > ---------- Forwarded message ----------
>     > From: Michal Wesolowski <gmickyw at gmail.com
>     <mailto: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 <mailto:Sam.Wilson at ed.ac.uk>>
>     >
>     >
>     > On Tue, Feb 23, 2010 at 1:33 PM, Sam Wilson <Sam.Wilson at ed.ac.uk
>     <mailto:Sam.Wilson at ed.ac.uk>> wrote:
>     >
>     > > In article
>     <mailman.529.1266923597.21153.bind-users at lists.isc.org
>     <mailto:mailman.529.1266923597.21153.bind-users at lists.isc.org>>,
>     > >  Michal Wesolowski <gmickyw at gmail.com
>     <mailto: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 <http://www.goleszow.pl>" has bad NS
>     delegation on country root servers
>     > > level
>     > > > because virtual.sincom.pl <http://virtual.sincom.pl> is not
>     resolvable:
>     > > >
>     > > > goleszow.pl <http://goleszow.pl>.        86400    IN    NS
>     virtual.sincom.pl <http://virtual.sincom.pl>.
>     > > > goleszow.pl <http://goleszow.pl>.        86400    IN    NS
>     virtual.jasnet.pl <http://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 <http://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 <http://goleszow.pl>.            85994   NS
>     virtual.jasnet.pl <http://virtual.jasnet.pl>.
>     > > >                         85994   NS virtual.sincom.pl
>     <http://virtual.sincom.pl>.
>     > > > virtual.jasnet.pl <http://virtual.jasnet.pl>.      3194    A
>           85.202.208.254
>     > > > virtual.sincom.pl <http://virtual.sincom.pl>.      3194  
>      \-ANY   ;-$NXDOMAIN
>     > > > ; virtual.jasnet.pl <http://virtual.jasnet.pl> alias
>     jasnet.pl <http://jasnet.pl> [v4 TTL 3194] [target TTL 3194] [v4
>     > > > success] [v6 unexpected]
>     > > > ; virtual.sincom.pl <http://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
>     <http://virtual.jasnet.pl> alias jasnet.pl <http://jasnet.pl>".
>     jasnet.pl <http://jasnet.pl>
>     > > is delegated to ns10.az.pl <http://ns10.az.pl> and ns11.az.pl
>     <http://ns11.az.pl>.  If you ask them for an A
>     > > record for virtual.jasnet.pl <http://virtual.jasnet.pl> you
>     get an A record; if you ask for AAAA
>     > > you get a CNAME pointing to jasnet.pl <http://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
>     <http://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 <http://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
>
>     Well one of the nameservers does not exist and the other is a CNAME.
>     Both of these are fatal errors for the particular nameserver and
>     as there are only two nameservers for the zone lookups fail.
>
>     Add A records to the sincom.pl <http://sincom.pl> and jasnet.pl
>     <http://jasnet.pl> zones for virtual.sincom.pl
>     <http://virtual.sincom.pl>
>     and virtual.jasnet.pl <http://virtual.jasnet.pl> respectively.
>
>     Mark
>
>
> My server is caching only, I don't administer ns*.az.pl <http://az.pl> 
> servers. I'm just trying to understand if binds copes well with such 
> an external error. As you pointed out both servers fails in some 
> (different) way but second one does this only when queried for 
> something other than A record. For A everything is ok. THERE IS A 
> record for virtual.jasnet.pl <http://virtual.jasnet.pl>. Why bad 
> response from external server for AAAA record affects subsequent 
> queries for A? Which entry of cache is responsible for this:
>
> root at kellys # cat named_dump.db| egrep 'vir|gol|jas|sin|az'
> ns10.az.pl <http://ns10.az.pl>.             86397   A       62.146.113.3
> ns11.az.pl <http://ns11.az.pl>.             86397   A       62.146.68.200
> goleszow.pl <http://goleszow.pl>.            86397   NS 
> virtual.jasnet.pl <http://virtual.jasnet.pl>.
>                         86397   NS virtual.sincom.pl 
> <http://virtual.sincom.pl>.
> www.goleszow.pl <http://www.goleszow.pl>.        3597    CNAME 
> goleszow.pl <http://goleszow.pl>.
> jasnet.pl <http://jasnet.pl>.              86397   NS ns10.az.pl 
> <http://ns10.az.pl>.
>                         86397   NS ns11.az.pl <http://ns11.az.pl>.
> virtual.jasnet.pl <http://virtual.jasnet.pl>.      3597    A       
> 85.202.208.254
>                         3597    CNAME jasnet.pl <http://jasnet.pl>.
> sincom.pl <http://sincom.pl>.              86397   NS ns10.az.pl 
> <http://ns10.az.pl>.
>                         86397   NS ns11.az.pl <http://ns11.az.pl>.
> virtual.sincom.pl <http://virtual.sincom.pl>.      3597    \-ANY   
> ;-$NXDOMAIN
> ; virtual.jasnet.pl <http://virtual.jasnet.pl> alias jasnet.pl 
> <http://jasnet.pl> [v4 TTL 3597] [target TTL 3597] [v4 success] [v6 
> unexpected]
> ; virtual.sincom.pl <http://virtual.sincom.pl> [v4 TTL 3597] [v6 TTL 
> 3597] [v4 nxdomain] [v6 nxdomain]
> ; ns10.az.pl <http://ns10.az.pl> [v4 TTL 7] [v4 success] [v6 unexpected]
> ; ns11.az.pl <http://ns11.az.pl> [v4 TTL 7] [v4 success] [v6 unexpected]
>
> Is it a case that unexpected response to AAAA query from ns10.az.pl 
> <http://ns10.az.pl> marks virtual.jasnet.pl <http://virtual.jasnet.pl> 
> invalid even for A queries?
> Sorry for my persistence
>
> Regards
>
> Michal
>
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

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


More information about the bind-users mailing list