Glue records cached, when they should be coming from zone

[Kevin Darcy]

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.
>
>
>
>
>