different serial number in SOA on different interfaces

[Nick Tait]

On 06/11/2024 03:16, Hans Mayer via bind-users wrote:
> I have 3 views:
>
> view badcountry: based on geoip ( the name is self-explanatory )
>
> view internal: all local area networks but not the loopback interfaces 
> for IPv4 and IPv6
> it has only two response policy zones for drop and passthru , nothing 
> else
> there I change for example queries for external NTP names to internal 
> IP addresses.
>
> view foreveryone: as the name says, it has: match-clients { any ; };
> in this view there are all my zones defined
>
> Therefore queries for the same domain name SOA record on different IP 
> addresses goes to different views ( as expected )
> The bind query log shows a query @::1 or @127.0.01 goes to view 
> foreveryone, with real IP goes to "internal"
> So the query for the domain "yer.at" @192.168.241.9 will be logged in 
> view "internal" but the zone itself is defined in view foreveryone.
>
> The TTL in the zone is defined as
>
>                 21600      ; refresh (6 hours)
>                 3600       ; retry (1 hour)
>                 1209600    ; expire (2 weeks)
>                 86400      ; minimum (1 day)
>
> the nsupdate command is using a TTL for 1 day.
>
> doing repeated dig's shows that TTL @real IP counts down but not so 
> @loopback interfaces
>
> # dig +noall +answer yer.at SOA @::1
> yer.at.            86400    IN    SOA    gw.yer.at. dns2008.yer.at. 
> 29820 21600 3600 1209600 86400
> # dig +noall +answer yer.at SOA @::1
> yer.at.            86400    IN    SOA    gw.yer.at. dns2008.yer.at. 
> 29820 21600 3600 1209600 86400
> # dig +noall +answer yer.at SOA @192.168.241.9
> yer.at.            13573    IN    SOA    gw.yer.at. dns2008.yer.at. 
> 29817 21600 3600 1209600 86400
> # dig +noall +answer yer.at SOA @192.168.241.9
> yer.at.            13568    IN    SOA    gw.yer.at. dns2008.yer.at. 
> 29817 21600 3600 1209600 86400
>
> But even after the TTL reaches 0 and starts with a high value the 
> serial number is not updated.
>
> It's still not clear for me where I can turn something in the 
> configuration.
>
Based on what you said it sounds like you don't have any "yer.at" zone 
configured in the internal view, and so when the internal view receives 
a query for "yer.at", it answers it using recursive resolution. To do 
this it will first determine the authoritative name servers for the 
domain, and then query one of those to get the answer. In other words 
when you use dig to query 192.168.241.9 for "yer.at", the answer you get 
may have come from a different authoritative name server (e.g. not 
192.168.241.9). That answer will be cached by the internal view for the 
TTL duration provided in the authoritative response.

Based on your observation that repeated queries result in a decreasing 
TTL, and then when the TTL expires, you still receive a 'stale' response 
(but with the starting TTL), it sounds like the authoritative name 
server that was chosen doesn't know that the zone has been updated. As a 
test, please update the zone using nsupdate, then try running this command:

    dig yer.at +nssearch

This will query the SOA record on all of the authoritative name servers 
for the domain. Hopefully this will show you which name servers aren't 
getting updated when the zone data changes, and (if I'm right) then we 
can troubleshoot that issue?

Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20241106/6cc9a354/attachment.htm>