Glue records cached, when they should be coming from zone
Kevin Darcy
kcd at chrysler.com
Tue Nov 13 21:59:04 UTC 2007
ar.lanwan.fi is delegated as a zone to other nameservers, you're not
authoritative for any records underneath the zone cut. So this glue is
treated just the same as any other cached glue. Even when a
non-recursive query is made, the data which has been cached from the
zone itself takes precedence over the glue records from the parent zone.
Once those records have been cached, the only way to see the "submerged"
glue records from the parent would be to do a zone transfer of the
parent zone.
ns.lanwan.fi is *not* from the child zone, so you're authoritative for
it and the TTL does not decrease.
My question is: why do you characterize this as a "problem"? Seems to me
everything is working as designed.
- Kevin
Tuomas Toropainen wrote:
> Hello
>
> We are having problem with glue records. It seems that for some reason,
> instead of retrieving the glue records from zone, bind serves them from
> cache. This causes problems especially when the glue record caches time out.
>
> The problematic glue records are ns1.ar.lanwan.fi and ns2.ar.lanwan.fi.
> They are part of zone ar.lanwan.fi, which has been delegated from
> lanwan.fi. Both zones are public.
>
> Here is the relevant data from lanwan.fi zone file:
>
> ---8<---
> $TTL 1d
> $ORIGIN lanwan.fi.
> @ IN SOA ns.lanwan.fi. hostmaster.lanwan.fi. (
> 2007110201 ; serial
> 10800 ; refresh
> 3600 ; retry
> 7D ; expiry
> 38400 ) ; minimum
>
> IN NS ns.lanwan.fi.
> IN NS ns1.ar.lanwan.fi.
> IN NS ns2.ar.lanwan.fi.
>
> ns IN A 213.255.190.40
> ns2 IN A 213.255.190.40
>
> ns1.ar.lanwan.fi. IN A 213.255.168.10
> ns2.ar.lanwan.fi. IN A 213.255.168.20
> ar.lanwan.fi. IN NS ns1.ar.lanwan.fi.
> ar.lanwan.fi. IN NS ns2.ar.lanwan.fi.
> ---8<---
>
>
> The problem is clearly visible in this dig query. Look at the TTL of
> ns1.ar.lanwan.fi A record. Why does ns2.ar.lanwan.fi have constant
> default TTL while ns1 TTL is decrementing?
>
> ---8<---
> $ dig ns ar.lanwan.fi. @ns.lanwan.fi.
>
> ; <<>> DiG 9.3.4 <<>> ns ar.lanwan.fi. @ns.lanwan.fi.
> ; (1 server found)
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1484
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
>
> ;; QUESTION SECTION:
> ;ar.lanwan.fi. IN NS
>
> ;; AUTHORITY SECTION:
> ar.lanwan.fi. 86400 IN NS ns2.ar.lanwan.fi.
> ar.lanwan.fi. 86400 IN NS ns1.ar.lanwan.fi.
>
> ;; ADDITIONAL SECTION:
> ns1.ar.lanwan.fi. 32535 IN A 213.255.168.10
> ns2.ar.lanwan.fi. 86400 IN A 213.255.168.20
>
> ;; Query time: 4 msec
> ;; SERVER: 213.255.190.40#53(213.255.190.40)
> ;; WHEN: Mon Nov 12 14:57:48 2007
> ;; MSG SIZE rcvd: 98
> ---8<---
>
> Here is another example. As the query is made from outside (recursion
> not allowed), ns2.ar.lanwan.fi A record is missing, because it has
> expired from cache.
>
> ---8<---
> $ dig ns lanwan.fi. @ns.lanwan.fi.
>
> ; <<>> DiG 9.3.4 <<>> ns lanwan.fi. @ns.lanwan.fi.
> ; (1 server found)
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1313
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 2
>
> ;; QUESTION SECTION:
> ;lanwan.fi. IN NS
>
> ;; ANSWER SECTION:
> lanwan.fi. 86400 IN NS ns2.ar.lanwan.fi.
> lanwan.fi. 86400 IN NS ns.lanwan.fi.
> lanwan.fi. 86400 IN NS ns1.ar.lanwan.fi.
>
> ;; ADDITIONAL SECTION:
> ns.lanwan.fi. 86400 IN A 213.255.190.40
> ns1.ar.lanwan.fi. 47998 IN A 213.255.168.10
>
> ;; Query time: 4 msec
> ;; SERVER: 213.255.190.40#53(213.255.190.40)
> ;; WHEN: Tue Nov 13 10:40:05 2007
> ;; MSG SIZE rcvd: 115
> ---8<---
>
>
> Bind is version 9.2.4, running on debian 3.1 w/ latest updates. The
> debian package version is 9.2.4-1sarge3. This bind has a split dns
> setup, in case it makes any difference.
>
> named-checkzone and named-checkconf don't report any problems with zone
> files or bind configuration. I don't know what might be wrong. Could it
> be that I have run into a bug, or is this caused by misconfiguration?
>
> Thank you very much for any help.
>
>
>
>
>
More information about the bind-users
mailing list