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.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
