[Dnsmasq-discuss] CNAME trouble with no AAAA
Dominick C. Pastore
dominickpastore at dcpx.org
Sat Oct 19 17:19:37 BST 2019
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 :(
Thanks for the detailed explanation. That makes sense and sounds very reasonable. Thank you for all the help!
More information about the Dnsmasq-discuss