Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-29 Thread Petr Mensik 

Hi Dominick,

more below

On 10/17/19 3:41 AM, 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  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  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.
Is there any reason you want CNAME used? I think they unnecessary 
complicate the setup without obvious advantage. Just provide directly 
either local or public addresses for those names. Why is CNAME used?


The problem is, some clients cache their DNS requests. When these clients send 
a  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?
Just make sure client's DNS cache is flushed after connection type 
change. That is important for split-horizon.


Thanks,
Nick

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-26 Thread Simon Kelley 
On 26/10/2019 03:47, Dominick C. Pastore wrote:
> On Fri, Oct 25, 2019, at 4:48 PM, Simon Kelley wrote:
>> 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  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.
> 
> To be fair, the man page doesn't say that this should work. Although I 
> suppose it also doesn't say that "host-record" should work and that one does. 
> If it would be helpful, I don't mind contributing documentation updates, 
> although I'm not sure what Dnsmasq's conventions are for external 
> contributions.

We bite the hand of anyone who improves docs..


> 
>>> 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  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?
> 
> Here is how I am able to reproduce it:
> 
> 1. Query Dnsmasq for type A on a nonexistent domain (using dig). Get NXDOMAIN.
> 2. Query Dnsmasq for type  on the same domain. Get NODATA.
> 3. Send SIGHUP to Dnsmasq to clear cache.
> 4. Query Dnsmasq for type  on the same domain again. This time, get 
> NXDOMAIN.
> 
> Here are the actual commands and output pasted from the shell:
> 
> dominickpastore@platinum:~$ dig @127.0.0.1 +nocmd +nostats +noquestion 
> vlvtdnpxed.com A
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46341
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; AUTHORITY SECTION:
> com.899 IN  SOA a.gtld-servers.net. 
> nstld.verisign-grs.com. 1572043374 1800 900 604800 86400
> dominickpastore@platinum:~$ dig @127.0.0.1 +nocmd +nostats +noquestion 
> vlvtdnpxed.com 
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40388
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> dominickpastore@platinum:~$ sudo killall -HUP dnsmasq
> [sudo] password for dominickpastore:
> dominickpastore@platinum:~$ dig @127.0.0.1 +nocmd +nostats +noquestion 
> vlvtdnpxed.com 
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31058
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; AUTHORITY SECTION:
> com.899 IN  SOA a.gtld-servers.net. 
> nstld.verisign-grs.com. 1572043429 1800 900 604800 86400
> 
> Querying the upstream server directly always results in NXDOMAIN.
> 
> The other thing I noticed is that only an A or  request triggers this. 
> SRV, TXT, and MX requests do not. But once an A or  request is made for a 
> nonexistent domain, all other request types for that domain result in NODATA 
> until the cache is flushed. To demonstrate what I mean:
> 
> sudo killall -HUP dnsmasq
> dig @127.0.0.1 vlvtdnpxed.com TXT# gives NXDOMAIN
> dig @127.0.0.1 vlvtdnpxed.com SRV# gives NXDOMAIN
> dig @127.0.0.1 vlvtdnpxed.com    # gives NXDOMAIN
> dig @127.0.0.1 vlvtdnpxed.com TXT# gives NODATA
> dig @127.0.0.1 vlvtdnpxed.com SRV# gives NODATA
> dig @127.0.0.1 vlvtdnpxed.com A  # gives NODATA
> dig @127.0.0.1 vlvtdnpxed.com    # gives NXDOMAIN
> 

You're running 2.80, right? I think we (not me) nailed this one already

Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-25 Thread Dominick C. Pastore 
On Fri, Oct 25, 2019, at 4:48 PM, Simon Kelley wrote:
> 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  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.

To be fair, the man page doesn't say that this should work. Although I suppose 
it also doesn't say that "host-record" should work and that one does. If it 
would be helpful, I don't mind contributing documentation updates, although I'm 
not sure what Dnsmasq's conventions are for external contributions.

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

Here is how I am able to reproduce it:

1. Query Dnsmasq for type A on a nonexistent domain (using dig). Get NXDOMAIN.
2. Query Dnsmasq for type  on the same domain. Get NODATA.
3. Send SIGHUP to Dnsmasq to clear cache.
4. Query Dnsmasq for type  on the same domain again. This time, get 
NXDOMAIN.

Here are the actual commands and output pasted from the shell:

dominickpastore@platinum:~$ dig @127.0.0.1 +nocmd +nostats +noquestion 
vlvtdnpxed.com A
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46341
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; AUTHORITY SECTION:
com.899 IN  SOA a.gtld-servers.net. 
nstld.verisign-grs.com. 1572043374 1800 900 604800 86400
dominickpastore@platinum:~$ dig @127.0.0.1 +nocmd +nostats +noquestion 
vlvtdnpxed.com 
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40388
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
dominickpastore@platinum:~$ sudo killall -HUP dnsmasq
[sudo] password for dominickpastore:
dominickpastore@platinum:~$ dig @127.0.0.1 +nocmd +nostats +noquestion 
vlvtdnpxed.com 
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31058
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; AUTHORITY SECTION:
com.899 IN  SOA a.gtld-servers.net. 
nstld.verisign-grs.com. 1572043429 1800 900 604800 86400

Querying the upstream server directly always results in NXDOMAIN.

The other thing I noticed is that only an A or  request triggers this. SRV, 
TXT, and MX requests do not. But once an A or  request is made for a 
nonexistent domain, all other request types for that domain result in NODATA 
until the cache is flushed. To demonstrate what I mean:

sudo killall -HUP dnsmasq
dig @127.0.0.1 vlvtdnpxed.com TXT# gives NXDOMAIN
dig @127.0.0.1 vlvtdnpxed.com SRV# gives NXDOMAIN
dig @127.0.0.1 vlvtdnpxed.com    # gives NXDOMAIN
dig @127.0.0.1 vlvtdnpxed.com TXT# gives NODATA
dig @127.0.0.1 vlvtdnpxed.com SRV# gives NODATA
dig @127.0.0.1 vlvtdnpxed.com A  # gives NODATA
dig @127.0.0.1 vlvtdnpxed.com    # gives NXDOMAIN

Thanks,
Nick

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-20 Thread Dominick C. Pastore 
I have no complaints about a new thread.

On Sun, Oct 20, 2019, at 6:47 PM, Kurt H Maier wrote:
> On Sun, Oct 20, 2019 at 12:55:44PM -0400, Dominick C. Pastore wrote:
> > 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.)
>
> RFC2181 explicitly forbids MX records from being aliases.  It's a bad
> idea -- best case, it doubles DNS traffic.  MX et al fall into
> additional section processing, which does not contain CNAME records.   
> This means a CNAME-only MX record will cause no-address responses.
> Which means the client, if it's trying hard enough, will just request a
> regular lookup, get the CNAME, resolve that, and hopefully get the MX
> record in additional-section along the way.
>  
> Yes, all sorts of DNS server software allows this crap.  It's still bad
> behavior.  MX records should not be CNAMEs.  RFC5321 has more
> information, including the directive that MX records MUST contain a   
> domain name with an A or  record.
>  
> khm
>

To be clear, I was referring to a CNAME whose target has an MX record (or TXT 
record, or probably others). For example, in Dnsmasq terms:

cname=myhost.example.com,example.com
host-record=example.com,192.168.0.1
mx-host=example.com,mail.example.com
host-record=mail.example.com,192.168.0.2

An MX request for myhost.example.com results in NODATA. Admittedly, I'm not 
100% sure that this is allowed by the RFCs either, but I didn't see anything 
indicating it shouldn't be (but it's entirely possible I missed something).

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-20 Thread Kurt H Maier 
On Sun, Oct 20, 2019 at 12:55:44PM -0400, Dominick C. Pastore wrote:
> 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.)
   
RFC2181 explicitly forbids MX records from being aliases.  It's a bad
idea -- best case, it doubles DNS traffic.  MX et al fall into
additional section processing, which does not contain CNAME records.   
This means a CNAME-only MX record will cause no-address responses.
Which means the client, if it's trying hard enough, will just request a
regular lookup, get the CNAME, resolve that, and hopefully get the MX
record in additional-section along the way.
 
Yes, all sorts of DNS server software allows this crap.  It's still bad
behavior.  MX records should not be CNAMEs.  RFC5321 has more
information, including the directive that MX records MUST contain a   
domain name with an A or  record.
 
khm

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-20 Thread Geert Stappers 
On Sun, Oct 20, 2019 at 12:55:44PM -0400, Dominick C. Pastore wrote:
> ... but I suspect this isn't intended behavior either,
> so it seemed worth mentioning.

Is it OK that I start a new thread (with matching Subject) for it?
[yes/no]

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-20 Thread Dominick C. Pastore 
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  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".)

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

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.

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  record on the CNAME name returns just the CNAME, rather than
> > sending it upstream, because the  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

Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-19 Thread Dominick C. Pastore 
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  record on the CNAME name returns just the CNAME, rather than
> sending it upstream, because the  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

Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-19 Thread Simon Kelley 
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  record on the CNAME name returns just the CNAME, rather than
sending it upstream, because the  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

Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-18 Thread Dominick C. Pastore 
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

Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-18 Thread Simon Kelley 
On 18/10/2019 12:51, Simon Kelley wrote:
> On 18/10/2019 12:41, Simon Kelley wrote:
> 
>> The obvious way is to provide an  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.
>>
> 
> 
> very simple patch to do alter this behaviour.
> 
> diff --git a/src/rfc1035.c b/src/rfc1035.c
> index 0344af7..720713d 100644
> --- a/src/rfc1035.c
> +++ b/src/rfc1035.c
> @@ -1711,7 +1711,9 @@ size_t answer_request(struct dns_header *header,
> char *limit, size_t qlen,
>   {
> char *cname_target =
> cache_get_cname_target(crecp);
> 
> -   if (!dryrun)
> +ans = 1;
> +
> +if (!dryrun)
>   {
> log_query(crecp->flags, name, NULL,
> record_source(crecp->uid));
> if (add_resource_record(header, limit,
> , nameoffset, ,
> 
> 
> 



That breaks CNAMEs cached from upstream. This doesn't

diff --git a/src/rfc1035.c b/src/rfc1035.c
index 0344af7..21be03b 100644
--- a/src/rfc1035.c
+++ b/src/rfc1035.c
@@ -1711,6 +1711,9 @@ size_t answer_request(struct dns_header *header,
char *limit, size_t qlen,
  {
char *cname_target =
cache_get_cname_target(crecp);

+   if (crecp->flags & F_CONFIG)
+ ans = 1;
+
if (!dryrun)
  {
log_query(crecp->flags, name, NULL,
record_source(crecp->uid));


Simon.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-18 Thread Simon Kelley 
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  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  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  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  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

Re: [Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-18 Thread Simon Kelley 
On 18/10/2019 12:41, Simon Kelley wrote:

> The obvious way is to provide an  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.
> 


very simple patch to do alter this behaviour.

diff --git a/src/rfc1035.c b/src/rfc1035.c
index 0344af7..720713d 100644
--- a/src/rfc1035.c
+++ b/src/rfc1035.c
@@ -1711,7 +1711,9 @@ size_t answer_request(struct dns_header *header,
char *limit, size_t qlen,
  {
char *cname_target =
cache_get_cname_target(crecp);

-   if (!dryrun)
+ans = 1;
+
+if (!dryrun)
  {
log_query(crecp->flags, name, NULL,
record_source(crecp->uid));
if (add_resource_record(header, limit,
, nameoffset, ,




___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] CNAME trouble with no AAAA

2019-10-16 Thread Dominick C. Pastore 
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  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  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  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?

Thanks,
Nick

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss