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
