<!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 pointing me a little bit more to
the solution. <br>
</p>
<p>I have 3 views:</p>
<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>
<p><br>
</p>
<p>Kind regards <br>
Hans <br>
</p>
<p>-- <br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 03.11.24 21:03, Nick Tait via
bind-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3ba59cee-8993-48c7-96a4-a3da7ba653eb@tait.net.nz">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Hans.</p>
<p>Based on what you described, it sounds like DNS queries you
issue to your server (using dig) are processed by one view for
loopback addresses and a different view for eno1 addresses? If
that is the case it would be interesting to see how the (same)
zone is defined in those two views? And which of these views is
the one that is being updated by nsupdate? Depending how the
views are defined it could also make a difference whether you
include +recurse or +norecurse in your dig queries.</p>
<p>I'd suggest you set up query logging, and then do some testing
and watch the logs to confirm if this is the case? FYI In case
it helps, this is the logging that I use:<br>
</p>
<blockquote>
<pre>logging {
category default { syslog; logfile; default_debug; server_log; };
category dnssec { syslog; logfile; default_debug; };
category lame-servers { syslog; logfile; default_debug; };
category queries { syslog; logfile; default_debug; query_log; };
category query-errors { syslog; logfile; default_debug; query_log; };
category resolver { syslog; logfile; default_debug; };
category rpz { syslog; logfile; default_debug; query_log; };
category rpz-passthru { syslog; logfile; default_debug; query_log; };
category unmatched { logfile; };
channel syslog {
syslog daemon;
severity notice;
};
channel logfile {
file "/var/log/named/all.log" versions 5 size 10m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
channel query_log {
file "/var/log/named/query.log" versions 5 size 10m;
print-time yes;
print-category yes;
severity info;
};
channel server_log {
file "/var/log/named/server.log" versions 5 size 10m;
print-time yes;
print-category yes;
severity info;
};
};
</pre>
</blockquote>
<p>On the assumption my theory is correct, the most likely
explanation for what you're describing is that records are being
cached in some views, which is why you aren't getting the latest
results for those views. How long a record is cached is based on
TTL parameters in the zone. Depending on the types of updates
you are doing (with nsupdate) you might like to consider using a
shorter TTL value on either individual records or all records,
and/or the negative response caching TTL (5th parameter in the
SOA record)?</p>
<p>Nick.<br>
</p>
<div class="moz-cite-prefix">On 3/11/2024 11:28 pm, Hans Mayer via
bind-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a3c5dc24-eca7-493d-b90a-94b5f133953b@ma.yer.at">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<p> </p>
<div class="moz-text-flowed"
style="font-family: -moz-fixed; font-size: 12px;"
lang="x-unicode"> <br>
Dear All, <br>
<br>
I am running BIND 9.18.32-dev (Extended Support Version)
<id:a3b61ad> <br>
running on Linux x86_64 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC
Debian 6.1.106-3 (2024-08-26) <br>
<br>
This server has several interfaces based on docker but in
general a physical interface "eno1" and a loopback interface
"lo". <br>
Both interfaces have each an IPv4 and an IPv6 address. So in
total 4 combinations. <br>
The named service has several dynamic zones as master in three
different views. The server does also inline-signing for some
zones. There is also RPZ in use to rewrite some queries. <br>
<br>
Most of the time I get on all 4 IP address the same answer for
the serial number doing a dig for a specific domain name and
SOA record. <br>
<br>
Doing a dynamic update for a signed master zone with
"nsupdate" I have the situation that I get from IP "127.0.0.1"
and "::1" an increased serial number but on real interface
"eno1" with IPv4 and IPv6 the old serial number. <br>
The interesting part is doing a zone-transfer with "dig axfr"
from a remote server and therefore to the real interface
"eno1" I get the updated serial number. Therefore all
secondary DNS servers are getting the updates. Also a "dig"
for the SOA RR from remote gives the updated information. <br>
<br>
In my mind came, maybe there is an other DNS service running
on the same machine. Checking the daemon log shows that bind
has no error at start and is listening on all interface. To be
sure I stopped "named" and without named I didn't get any
answer at all on all interfaces. Therefore it is "named" which
gives different answers on different interfaces. <br>
<br>
A "rndc reload" doesn't help but after some time ( long time )
the serial numbers on all interfaces are identical. <br>
The same with restarting the named process, it doesn't help. <br>
<br>
Finally I assumed it has something to do with DNSSEC. I
realized that validation for all views was disabled after
reboot. So I run "rndc validation on". <br>
In the first moment it looks fine. All serial numbers
identical. But doing an update again, the serial numbers are
different. So maybe it was a coincidence that it changed in
that moment. <br>
<br>
Any ideas where I can look deeper into this issue ? Any help
would be appreciated. <br>
<br>
Kind regards <br>
Hans <br>
<br>
<div class="moz-txt-sig"><span class="moz-txt-tag">-- <br>
</span> <br>
<br>
</div>
</div>
<p><br>
</p>
<p><br>
</p>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
</body>
</html>