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. On 18/10/2019 18:05, Dominick C. Pastore wrote: > On Fri, Oct 18, 2019, at 7:41 AM, Simon Kelley wrote: >> I can see a strong argument that a query for a name which is configured >> as a CNAME in dnsmaq, but for a type which is not known to dnsmasq, >> should return a NODATA reply. >> >> In fact I can't see a downside to that. >> >> Anybody else? >> >> >> Simon. > > First, thank you for the patch. > > A question: Would this patch mean the restriction from the manpage I > mentioned will no longer apply? Or would it still apply, but be satisfied as > long as a record of any type is known for the target? (Note that the latter > is the way I originally interpreted the manual, until I observed otherwise.) > > 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. > > Relevant snippet of the manpage copied here for reference: > "There are significant limitations on the target; it must be a DNS name which > is known to dnsmasq from /etc/hosts (or additional hosts files), from DHCP, > from --interface-name or from another --cname. If the target does not satisfy > this criteria, the whole cname is ignored." > > Thanks, > Nick > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
