Re: different serial number in SOA on different interfaces
Hi Nick,
many thanks for your reply and pointing me a little bit more to the
solution.
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.
Kind regards
Hans
--
On 03.11.24 21:03, Nick Tait via bind-users wrote:
Hi Hans.
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.
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:
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;
};
};
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)?
Nick.
On 3/11/2024 1
different serial number in SOA on different interfaces
Dear All, I am running BIND 9.18.32-dev (Extended Support Version) running on Linux x86_64 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) This server has several interfaces based on docker but in general a physical interface "eno1" and a loopback interface "lo". Both interfaces have each an IPv4 and an IPv6 address. So in total 4 combinations. 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. 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. 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. 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. 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. A "rndc reload" doesn't help but after some time ( long time ) the serial numbers on all interfaces are identical. The same with restarting the named process, it doesn't help. 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". 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. Any ideas where I can look deeper into this issue ? Any help would be appreciated. Kind regards Hans -- -- 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
Re: different serial number in SOA on different interfaces
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.
--
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
dnsviz.net: has errors; select the "Denial of existence" DNSSEC option to see them.
Dear All, I realized that dnsviz.net is showing me 5 errors for some domain names, even some which do not exist. This is not only for one domain. I see this for some domains I manage. I am running BIND 9.18.34-dev (Extended Support Version) This is for example such an error message at dnsviz: ok7gd.aw5sp.iiasa.ac.at/A has errors; select the "Denial of existence" DNSSEC option to see them. Searching for solutions didn't really help. Any idea how to solve this issue ? Or where to dig deeper to find a solution ? Kind regards Hans -- -- 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
Re: dnsviz.net: has errors; select the "Denial of existence" DNSSEC option to see them.
Hi Taavi, It seems I was blind and didn't see the button. Problem solved. Iterations set to 0 and salt to null. Everything green now at DNSviz. Best regards Hans -- On 07.02.25 17:05, Taavi Eomäe wrote: Hi, If you select the "Denial of existence" under options, then you will see the exact details behind those errors. It seems like your NSEC3 iterations count is not 0, but it should be 0 to alleviate computational burdens. See RFC9276, Sec. 3.1. Best regards Taavi -- 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
