[Dnsmasq-discuss] CNAME not resolving for external domain

[Buck Horn]

On 17.08.24 22:24, Alex Malinovich via Dnsmasq-discuss wrote:
> I also own the public "foo.net" domain.
> (...)
> BUT, if I try the same thing with the foo.net domain, I get the CNAME
> record back, but it never resolves to an A record so the lookup fails:
>
> address=/root.foo.net/192.168.0.234
> cname=bar.foo.net,root.foo.net
>
> $ drill -Q bar.foo.net
> root.foo.net.


For me, neither your *.net nor *.lan configuration would work (but then,
my private domain isn't  'lan').

Sharing your complete dnsmasq configuration may help to spot a
difference, but that may not be necessary:
There is a solution available that foregoes using that 'address' option.

According to dnsmasq documentation, 'address' is designed to assign an
IP to a whole set of domains - in your case, root.foo.net and all of its
subdomains (*.root.foo.net).
I'm guessing here, but that may mean that dnsmasq would invent the
required DNS replies on the fly, rather than creating actual DNS records
for them (as that would seem impossible for unknown subdomains).

On the other hand, dnsmasq's 'cname' option states:
 > There is a significant limitation on the target; it must be a DNS
record which is known to dnsmasq

That may suggest that 'cname' may not work with 'address' if that
doesn't create actual DNS records, and it would also explain why either
*.net or *.lan do fail for me.

You should be able to get CNAMEs to resolve correctly by using
'host-record' instead, which would create actual DNS records, e.g.:

host-record=root.foo.lan,192.168.0.123,60
cname=bar.foo.lan,root.foo.lan

Using 'host-record', you'd additionally benefit from PTR records that
dnsmasq would add automatically, and you'd get to control the records'
TTL explicitly (60 seconds in above example).

On a side note:
Your *.net definitions are shadowing a public domain, which is always
good for surprises, e.g. resolution may 'leak' to public resolvers
returning unexpected records of types you haven't told dnsmasq to hold
records for (e.g.  MX or AAAA), or HTTPS connections to servers may fail
for lack of connectivity or in absence of certificates.
If you do not require *.net for a reason, you probably should consider
to stick with just your private 'lan' domain within the bounds of your
home network.

Kind regards,
     Buck