On 20/10/2019 17:55, Dominick C. Pastore wrote: > 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".)
This is true, and difficult to fix for very obscure reasons. It should be more explicitly documented, or better, fixed. > > 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.) > Actually it's not, it just that the CNAME code was never generalised to handle stuff not in the cache. I've spent an enjoyable afternoon down the rabbit-hole testing and rewriting, and this should be fixed now. The prohibition on mixing local and upstream continues, but you can now define a TXT/MX/SRV locally and a local CNAME pointing to it, and as long as you define an A or AAAA record of the same name, all will be fine. > 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. I can't reproduce this. Could you provide a simple example? > > 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 > > _______________________________________________ > 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
