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

[Thomas Erbesdobler]

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)