Re: Fwd: IPv6 client and negative cache - some doubts
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 ma...@isc.org
mailto:ma...@isc.org wrote:
In message
f677fefa1002230600n4694161cu315e5dd4beaaa...@mail.gmail.com
mailto:f677fefa1002230600n4694161cu315e5dd4beaaa...@mail.gmail.com,
Micha
l Wesolowski writes:
sorry for replying directly, still have some problems with gmail UI.
-- Forwarded message --
From: Michal Wesolowski gmic...@gmail.com
mailto:gmic...@gmail.com
Date: Tue, Feb 23, 2010 at 2:47 PM
Subject: Re: IPv6 client and negative cache - some doubts
To: Sam Wilson sam.wil...@ed.ac.uk mailto:sam.wil...@ed.ac.uk
On Tue, Feb 23, 2010 at 1:33 PM, Sam Wilson sam.wil...@ed.ac.uk
mailto:sam.wil...@ed.ac.uk wrote:
In article
mailman.529.1266923597.21153.bind-us...@lists.isc.org
mailto:mailman.529.1266923597.21153.bind-us...@lists.isc.org,
Michal Wesolowski gmic...@gmail.com
mailto:gmic...@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.86400INNS
virtual.sincom.pl http://virtual.sincom.pl.
goleszow.pl http://goleszow.pl.86400INNS
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
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. 3194A
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
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
Re: Fwd: IPv6 client and negative cache - some doubts
In article mailman.575.1266994115.21153.bind-us...@lists.isc.org, Michal Wesolowski gmic...@gmail.com wrote: My server is caching only, I don't administer ns*.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. Why bad response from external server for record affects subsequent queries for A? Which entry of cache is responsible for this: These: virtual.jasnet.pl. 3597A 85.202.208.254 3597CNAME jasnet.pl. You can't have both a CNAME and an A record for the same name. I'm not sure which version of BIND you're using for your cache, but I'm slightly surprised it retains both records. Is it a case that unexpected response to query from ns10.az.pl marks virtual.jasnet.pl invalid even for A queries? It looks like it. Sorry for my persistence Keep it up. Now you need to talk to the az.pl people and persuade them their server is broken. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fwd: IPv6 client and negative cache - some doubts
In article mailman.564.1266963563.21153.bind-us...@lists.isc.org, Mark Andrews ma...@isc.org wrote: In message f677fefa1002230600n4694161cu315e5dd4beaaa...@mail.gmail.com, Micha l Wesolowski writes: After some reading my present understanding is that correct response to 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. That's correct. 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. I don't either. 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. I hesitate to take issue with you Mark, but the problem is also that one of the nameservers has either an A record or a CNAME depending on how you look it up (A or query), and his caching server is keeping them both. Add A records to the sincom.pl and jasnet.pl zones for virtual.sincom.pl and virtual.jasnet.pl respectively. As the OP has pointed out that's not under his control, and if the same misbehaving servers are responsible there's the chance that both will be screwed up. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Fwd: IPv6 client and negative cache - some doubts
sorry for replying directly, still have some problems with gmail UI. -- Forwarded message -- From: Michal Wesolowski gmic...@gmail.com Date: Tue, Feb 23, 2010 at 2:47 PM Subject: Re: IPv6 client and negative cache - some doubts To: Sam Wilson sam.wil...@ed.ac.uk On Tue, Feb 23, 2010 at 1:33 PM, Sam Wilson sam.wil...@ed.ac.uk wrote: In article mailman.529.1266923597.21153.bind-us...@lists.isc.org, Michal Wesolowski gmic...@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.86400INNSvirtual.sincom.pl. goleszow.pl.86400INNSvirtual.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 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. 3194A 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 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 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fwd: IPv6 client and negative cache - some doubts
In message f677fefa1002230600n4694161cu315e5dd4beaaa...@mail.gmail.com, Micha
l Wesolowski writes:
sorry for replying directly, still have some problems with gmail UI.
-- Forwarded message --
From: Michal Wesolowski gmic...@gmail.com
Date: Tue, Feb 23, 2010 at 2:47 PM
Subject: Re: IPv6 client and negative cache - some doubts
To: Sam Wilson sam.wil...@ed.ac.uk
On Tue, Feb 23, 2010 at 1:33 PM, Sam Wilson sam.wil...@ed.ac.uk wrote:
In article mailman.529.1266923597.21153.bind-us...@lists.isc.org,
Michal Wesolowski gmic...@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.86400INNSvirtual.sincom.pl.
goleszow.pl.86400INNSvirtual.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
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. 3194A 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
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
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
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 and jasnet.pl zones for virtual.sincom.pl
and virtual.jasnet.pl respectively.
Mark
; DiG 9.3.6-P1 virtual.sincom.pl @ns11.az.pl
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 45587
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;virtual.sincom.pl. IN
;; AUTHORITY SECTION:
sincom.pl. 3600IN SOA ns10.az.pl. admin.az.pl.
2009101603 10800 3600 604800 3600
;; Query time: 356 msec
;; SERVER: 62.146.68.200#53(62.146.68.200)
;; WHEN: Wed Feb 24 09:12:16 2010
;; MSG SIZE rcvd: 85
; DiG 9.7.0rc1 virtual.jasnet.pl @ns11.az.pl
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 11702
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;virtual.jasnet.pl. IN
;; ANSWER SECTION:
virtual.jasnet.pl. 3600IN CNAME jasnet.pl.
;; AUTHORITY SECTION:
jasnet.pl.
Re: Fwd: IPv6 client and negative cache - some doubts
On Tue, Feb 23, 2010 at 11:19 PM, Mark Andrews ma...@isc.org wrote: In message f677fefa1002230600n4694161cu315e5dd4beaaa...@mail.gmail.com, Micha l Wesolowski writes: sorry for replying directly, still have some problems with gmail UI. -- Forwarded message -- From: Michal Wesolowski gmic...@gmail.com Date: Tue, Feb 23, 2010 at 2:47 PM Subject: Re: IPv6 client and negative cache - some doubts To: Sam Wilson sam.wil...@ed.ac.uk On Tue, Feb 23, 2010 at 1:33 PM, Sam Wilson sam.wil...@ed.ac.uk wrote: In article mailman.529.1266923597.21153.bind-us...@lists.isc.org, Michal Wesolowski gmic...@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.86400INNSvirtual.sincom.pl. goleszow.pl.86400INNSvirtual.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 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. 3194A 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 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 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 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 and jasnet.pl zones for virtual.sincom.pl and virtual.jasnet.pl respectively. Mark My server is caching only, I don't administer ns*.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. Why bad response from external server for record affects subsequent queries for A? Which entry of cache is responsible for this: r...@kellys # cat named_dump.db| egrep 'vir|gol|jas|sin|az' ns10.az.pl. 86397 A 62.146.113.3 ns11.az.pl. 86397 A 62.146.68.200 goleszow.pl.86397 NS virtual.jasnet.pl. 86397 NS virtual.sincom.pl. www.goleszow.pl.3597CNAME goleszow.pl.
