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

[Thomas Erbesdobler]

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