different serial number in SOA on different interfaces
Hans Mayer
isc at ma.yer.at
Tue Nov 5 14:16:56 UTC 2024
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 11:28 pm, Hans Mayer via bind-users wrote:
>>
>>
>> Dear All,
>>
>> I am running BIND 9.18.32-dev (Extended Support Version) <id:a3b61ad>
>> 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
>>
>> --
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20241105/4295428f/attachment.htm>
More information about the bind-users
mailing list