On 17/10/2019 02:41, Dominick C. Pastore wrote:
> Hello,
> 
> I'm having a bit of a problem with the "cname" option in Dnsmasq. I have some 
> configuration options like these in dnsmasq.conf, where "host1" and "host2" 
> have IPv4 addresses from DHCP:
> 
> domain=philadelphia.example.com
> local=/philadelphia.example.com/
> cname=git.example.com,host1.philadelphia.example.com
> cname=nas.example.com,host2.philadelphia.example.com
> 
> This works well for A lookups on git.example.com and nas.example.com, but the 
> cname options are ignored for AAAA lookups. I think this is by design, since 
> the man page says the target of a cname must be known or it will be ignored. 
> (Although, maybe this is unintentional in this case? It does seem like a bit 
> of a bug for a name to *sometimes* be a CNAME, depending on the request 
> type.) Unfortunately, it's causing problems when the AAAA queries are 
> forwarded upstream, but I'm not sure how to fix it since these servers don't 
> have IPv6 addresses.
> 
> For some background:
> 
> The goal is to provide something like split-horizon DNS. Host1 and host2 
> reside behind NAT. On public DNS, philadelphia.example.com resolves to their 
> public address, with git.example.com and nas.example.com both being CNAMEs to 
> that name. But within the LAN, git.example.com and nas.example.com should be 
> CNAMEs to their local names.
> 
> The problem is, some clients cache their DNS requests. When these clients 
> send a AAAA request, it gets forwarded upstream and they end up caching the 
> public CNAME record. Then, they use the (incorrect) cached CNAME for A 
> requests, too.
> 
> Is there a good way to solve this?

The obvious way is to provide an AAAA record for the "local names". The
problem with that is it has to be real, or timeouts and stuff will
happen, so those hosts need to be dual-stack.

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.

> 
> 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

Reply via email to