Hi Simon,

thanks for the quick inclusion; looks great.

Regards,
Thomas

On 2/26/26 18:15, Simon Kelley wrote:

Thanks for that,

I reproduced the problem and your analysis looks spot on.

Patch applied to the upstream git repo, with a little tweak from me.

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ca30c826476ba01ad1383f0fbb4e3d51fd998ea3

Cheers,

Simon.


On 25.02.2026 19:29, Thomas Erbesdobler via Dnsmasq-discuss wrote:

Hi all,

I think I've found a bug when using dnsmasq as authoritative nameserver (e.g. to automatically provide RRs for local DHCP clients) when querying the NS RR. In particular I'm using dnsmasq with an auth-zone entry, auth-sec-servers, and an auth-server entry without specifying an interface (such that dnsmasq will still recurse on all interfaces). The config is similar to the one below (though I've changed some fields for anonymity):

interface=<some interface>
bind-interfaces
local=/nonexistingbanana/
domain=nonexistingbanana
no-hosts
#no-resolv
dhcp-range=192.168.0.150,192.168.0.254,12h
server=127.0.0.53
auth-zone=nonexistingbanana.
auth-server=ns1.<externally visible domain>.

auth-sec-servers=ns1.<externally visible domain>.,ns2.<externally visible domain>.

auth-peer=192.168.1.173
auth-soa=20260225153310,<some contact>,7200,1,8

This config might not be minimal to reproduce the issue. To give some context: dnsmasq will be used as a "hidden master", and ns1 will AXFR from it - hence it's required to be specified in auth-server such that the SOA RR will be correct.

Now, if one queries the NS records, dnsmasq returns the following:

;; ANSWER SECTION:

ns2.rbg.tum.de.        600    IN    NS I\137\198H\133\192\015\132\250\236\255\255\139\@4\168\@u\029\168\016\015\132\235\236\255\255H\139\021\244s\002. ns1.rbg.tum.de.        600    IN    NS I\137\198H\133\192\015\132\250\236\255\255\139\@4\168\@u\029\168\016\015\132\235\236\255\255H\139\021\244s\002.

Note that the result is correct if one specifies an interface in the auth-server config option (even if the interface does not exist). It looks like this strange behavior is caused by a bug in the name compression logic. The following patch seems to fix it:

diff --git a/src/auth.c b/src/auth.c
index 7c34522..b95e61a 100644
--- a/src/auth.c
+++ b/src/auth.c

@@ -669,14 +669,19 @@ size_t answer_auth(struct dns_header *header, char *limit, size_t qlen, time_t n

           if (!subnet)

             for (secondary = daemon->secondary_forward_server; secondary; secondary = secondary->next) -             if (add_resource_record(header, limit, &trunc, offset, &ansp, -                                     daemon->auth_ttl, NULL, T_NS, C_IN, "d", secondary->name))

+           {
+             newoffset = ansp - (unsigned char *)header;

+             if (add_resource_record(header, limit, &trunc, -offset, &ansp, +                                     daemon->auth_ttl, NULL, T_NS, C_IN, "d", offset == 0 ? authname : NULL, secondary->name))

                 {
+                 if (offset == 0)
+                   offset = newoffset;
                   if (ns)
                     anscount++;
                   else
                     authcount++;
                 }
+           }
         }

        if (axfr)

I think the bug might have been introduced in git commit b43585c34baf0c5eb478aa07423da534b2118536 , which made a similar add_resource_record call for adding the "primary nameserver" (the one in the SOA RR) conditional. This means that the first NS RR for the "secondary nameserver" has to check if name compression is possible instead of simply referring to the name in the first NS RR. Therefore I've duplicated the logic used with the aforementioned call.

What do you think? And if this was indeed a bug, would it be possible to include my patch upstream or fix the issue in a different way?

Regards,
Thomas (Erbesdobler)


_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss