different serial number in SOA on different interfaces

[Nick Tait]

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/20241104/961ef883/attachment.htm>