Why making dnsmasq authoritative breaks CNAME resolution

dnsmasqdomain-name-systemnetworking

I have a CNAME set up in dnsmasq as

cname=ch1-lampe-bureau.swtk.info,switch-3

It is resolved correctly (switch-3 is a device which gets its IP via DHCP from dnsmasq):

root@rpi1 ~# host switch-3
switch-3 has address 10.200.0.123
root@rpi1 ~# host ch1-lampe-bureau.swtk.info
ch1-lampe-bureau.swtk.info is an alias for switch-3.
switch-3 has address 10.200.0.123

I then wanted to make dnsmasq authoritative for my domain by adding

auth-zone=swtk.info
auth-server=rpi1.swtk.info
auth-peer=192.168.0.13

Zone-transfer wise, it works: 192.168.0.13 can transfer the zone.

But the resolution of CNAMEs stopped. I can still resolve A records (switch-3 above for instance), CNAMEs are not.

root@rpi1 ~# host switch-3
switch-3 has address 10.200.0.123
root@rpi1 ~# host ch1-lampe-bureau.swtk.info
Host ch1-lampe-bureau.swtk.info not found: 3(NXDOMAIN)

What is the relationship between dnsmasq being authoritative and its abilty to resolve its CNAMEs?

Note: this is an internal DNS, with no relationship with the swtk.info domain registered externally.

Best Answer

This behavior seems to be highly dnsmasq-specific, it's really not obvious how to follow this from a DNS perspective.
In my opinion it would be worthwhile considering setting up a "real" nameserver (at which point generally applicable understanding of DNS will be relevant, instead), but that will undoubtedly make for a less integrated setup.

I'm not a dnsmasq user myself, but it seems to me that the following section from the the dnsmasq manual explains its behavior and requirements in this scenario (emphasis added):

When dnsmasq is configured to act as an authoritative server, the following data is used to populate the authoritative zone.

--mx-host, --srv-host, --dns-rr, --txt-record, --naptr-record, --caa-record, as long as the record names are in the authoritative domain.

--cname as long as the record name is in the authoritative domain. If the target of the CNAME is unqualified, then it is qualified with the authoritative zone name. CNAME used in this way (only) may be wildcards, as in

--cname=*.example.com,default.example.com IPv4 and IPv6 addresses from /etc/hosts (and --addn-hosts ) and --host-record and --interface-name provided the address falls into one of the subnets specified in the --auth-zone.

Addresses of DHCP leases, provided the address falls into one of the subnets specified in the --auth-zone. (If constructed DHCP ranges are is use, which depend on the address dynamically assigned to an interface, then the form of --auth-zone which defines subnets by the dynamic address of an interface should be used to ensure this condition is met.)

In the default mode, where a DHCP lease has an unqualified name, and possibly a qualified name constructed using --domain then the name in the authoritative zone is constructed from the unqualified name and the zone's domain. This may or may not equal that specified by --domain. If --dhcp-fqdn is set, then the fully qualified names associated with DHCP leases are used, and must match the zone's domain.

Ie, based on the above section of their manual, my understanding is that your cname=ch1-lampe-bureau.swtk.info,switch-3 means ch1-lampe-bureau.swtk.info. CNAME switch-3.swtk.info..

Additionally, it appears that names registered from DHCP are only added with names inside the auth zone if the auth-zone=... also specifies a subnet matching their assigned IP address. (as per --auth-zone=<domain>[,<subnet>[/<prefix length>][,<subnet>[/<prefix length>].....][,exclude:<subnet>[/<prefix length>]].....])

So currently switch-3.swtk.info. probably does not exist, but if you specify the appropriate subnet for your zone that name should appear, at which point the --cname also should start working.

Related Topic