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 _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
