[Dnsmasq-discuss] CNAME trouble with no AAAA

[Dominick C. Pastore]

I apologize for continuing the discussion on this. The patch (applied on top of 2.80-1 provided by Debian Buster) completely solved the issues I was having, but I did notice a couple other things.

First, locally configured CNAMEs and records other than A or AAAA do not seem to play well together. For example, MX and TXT requests still get forwarded upstream, even after the patch. I played around with this a bit and discovered:

1. Unlike "host-record", "txt-record" and "mx-host" on the target are not enough to keep Dnsmasq from ignoring a locally defined CNAME. (I did not try others, like "srv-host".)

2. In fact, Dnsmasq never follows a CNAME for MX or TXT requests, even when the CNAME does point to a host Dnsmasq knows locally. (I assume this is the reason for #1.)

Second, it seems that when Dnsmasq caches a NXDOMAIN response from upstream, it starts giving a NODATA response for other request types on the same name. Strangely, log-queries indicates the requests are forwarded, but right after a SIGHUP to clear the cache, sending one of the NODATA queries results in NXDOMAIN.

Neither of these are actually causing problems in my case, but I suspect this isn't intended behavior either, so it seemed worth mentioning.

Nick

On Sat, Oct 19, 2019, at 12:19 PM, Dominick C. Pastore wrote:
> On Sat, Oct 19, 2019, at 6:16 AM, Simon Kelley wrote:
> > The restriction still applies. indeed the patch relies on it.
> > 
> > The origin of this is that, for architectural reasons, dnsmasq can only
> > supply a reply which originates completely from locally known data, or
> > completely from a reply from upstream. Since a local CNAME to a target
> > in the public DNS necessarily  has both, it's not possible.
> > 
> > What the patch does, is allow a reply consisting only of the CNAME, of
> > the target isn't locally defined for the type in question. This would be
> > in error if the target was defined for the type in the public DNS, hence
> > the condition disallowing that. The second version of the patch only
> > does this for a locally defined CNAME, otherwise, you get the situation
> > where a CNAME to a A record is cached from upstream, and then a query
> > for an AAAA record on the CNAME name returns just the CNAME, rather than
> > sending it upstream, because the AAAA record for the CNAME target it not
> > currently cached.
> > 
> > >
> > > I ask because in the former case, that could mean Dnsmasq would send a
> > > NODATA reply if the target only exists in public DNS, correct? I'm not
> > > familiar enough with the intricacies of DNS to know if that would
> > > cause a problem for clients.
> > 
> > 
> > Such a reply could, in theory, cause a client to cache the Nodata status
> > of the CNAME target, whereas, if it queried the target directly, it
> > would get public data. A cabeat about that should, possibly be added to
> > the current disclaimer :(
> > 
> > 
> > 
> > Simon.
> 
> Thanks for the detailed explanation. That makes sense and sounds very 
> reasonable. Thank you for all the help!
> 
> Nick