<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<p>Hi Nick, <br>
</p>
<p>many thanks for your reply and your very detailed and exact
explanation. <br>
</p>
<p>Based on your suggestion I realised that I don't get an <span
style="color: rgb(12, 13, 14); font-size: 15px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-indent: 0px; text-transform: none; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">Authoritative
Answer if I query @ the IP of eno1 interface but I get an AA
flag for @::1 and @127.0.0.1 <br>
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. <br>
But not more. Maybe the server does not log its own query or my
config for dnstap is not perfect. <br>
</span></p>
<p><span
style="color: rgb(12, 13, 14); font-size: 15px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-indent: 0px; text-transform: none; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">Next
step was to query with +norecurse <br>
I didn't get an answer at </span><span
style="color: rgb(12, 13, 14); font-size: 15px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-indent: 0px; text-transform: none; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">the
IP of eno1 interface. Which is clear because it's not </span><span
style="color: rgb(12, 13, 14); font-size: 15px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-indent: 0px; text-transform: none; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">authoritative.
<br>
</span></p>
<p><span
style="color: rgb(12, 13, 14); font-size: 15px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-indent: 0px; text-transform: none; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">As
you mentioned </span> 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. <br>
</p>
<p>Many thanks for your expertise. <br>
</p>
<p>Kind regards <br>
Hans <br>
</p>
<p><br>
</p>
<p>-- <br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 06.11.24 06:41, Nick Tait via
bind-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:bc4faddc-570a-4a70-bc80-b5ecca7eff84@tait.net.nz">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 06/11/2024 03:16, Hans Mayer via
bind-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:07ac41c7-f33d-40fc-b2cd-81625ad0d0b7@ma.yer.at">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
I have 3 views:
<p>view badcountry: based on geoip ( the name is
self-explanatory ) <br>
</p>
<p>view internal: all local area networks but not the loopback
interfaces for IPv4 and IPv6 <br>
it has only two response policy zones for drop and passthru ,
nothing else <br>
there I change for example queries for external NTP names to
internal IP addresses. <br>
</p>
<p>view foreveryone: as the name says, it has: match-clients {
any ; };<br>
in this view there are all my zones defined <br>
</p>
<p>Therefore queries for the same domain name SOA record on
different IP addresses goes to different views ( as expected )
<br>
The bind query log shows a query @::1 or @127.0.01 goes to
view foreveryone, with real IP goes to "internal"<br>
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. <br>
</p>
<p>The TTL in the zone is defined as </p>
<p> 21600 ; refresh (6 hours)<br>
3600 ; retry (1 hour)<br>
1209600 ; expire (2 weeks)<br>
86400 ; minimum (1 day)<br>
</p>
<p>the nsupdate command is using a TTL for 1 day. <br>
</p>
<p>doing repeated dig's shows that TTL @real IP counts down but
not so @loopback interfaces <br>
</p>
<p># dig +noall +answer yer.at SOA @::1<br>
yer.at. 86400 IN SOA gw.yer.at.
dns2008.yer.at. 29820 21600 3600 1209600 86400<br>
# dig +noall +answer yer.at SOA @::1<br>
yer.at. 86400 IN SOA gw.yer.at.
dns2008.yer.at. 29820 21600 3600 1209600 86400<br>
# dig +noall +answer yer.at SOA @192.168.241.9 <br>
yer.at. 13573 IN SOA gw.yer.at.
dns2008.yer.at. 29817 21600 3600 1209600 86400<br>
# dig +noall +answer yer.at SOA @192.168.241.9 <br>
yer.at. 13568 IN SOA gw.yer.at.
dns2008.yer.at. 29817 21600 3600 1209600 86400</p>
<p>But even after the TTL reaches 0 and starts with a high value
the serial number is not updated. <br>
</p>
<p>It's still not clear for me where I can turn something in the
configuration. <br>
</p>
</blockquote>
<p>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.</p>
<p>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:<br>
</p>
<blockquote>
<pre>dig yer.at +nssearch
</pre>
</blockquote>
<p>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?<br>
</p>
<p>Nick.<br>
</p>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</body>
</html>