[Dnsmasq-discuss] Bug with NS records when using dnsmasq as authoritative nameserver without specific auth-interface

[Simon Kelley]

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
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss