different serial number in SOA on different interfaces

[Hans Mayer]

Hi Nick,

many thanks for your reply and your very detailed and exact explanation.

Based on your suggestion I realised that I don't get an Authoritative 
Answer if I query @ the IP of eno1 interface but I get an AA flag for 
@::1 and @127.0.0.1
Therefore you are right. It must query something else. So I looked at 
the dns-tap logfile. But when I query at the following 4 IP addresses 
192.168.241.9  2001:470:1f1b:2e4::241:9  ::1  and 127.0.0.1 I can find 8 
times SOA entries, 4 times a query and 4 times the answer.
But not more. Maybe the server does not log its own query or my config 
for dnstap is not perfect.

Next step was to query with +norecurse
I didn't get an answer at the IP of eno1 interface. Which is clear 
because it's not authoritative.

As you mentioned the server tries to find the authoritative name server. 
And yes there is one 188.21.75.154 sitting on the firewall. This bad guy 
is doing a bad caching. It's only a caching server and obviously it 
doesn't care about the TTL. Flushing the cache solves the issue.

Many thanks for your expertise.

Kind regards
Hans


-- 


On 06.11.24 06:41, Nick Tait via bind-users wrote:
> 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/20241107/9fbbc034/attachment-0001.htm>