Re: [Dnsmasq-discuss] non-recursive DNS ansewers patch
Simon, thank you for thorough explanation. Now I see what you mean, and I am completely agree with your idea. Thanks a lot. - Original Message - From: Simon Kelley si...@thekelleys.org.uk To: dnsmasq-discuss@lists.thekelleys.org.uk Sent: Tuesday, February 17, 2015 4:21:59 PM GMT -05:00 US/Canada Eastern Subject: Re: [Dnsmasq-discuss] non-recursive DNS ansewers patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/02/15 03:15, Nikolay P wrote: Thank you, Simon. I see what you mean. As I mentioned earlier I have an internal network with two DNS servers which ARE authoritative for the domain I use. It will be great if I can make them recursive, but in this case their logs will be full of warnings that they couldn't reach particular DNS servers - you know many OS have some sort of auto update or NTP clients or other reasons to connect to the outside world by default. By making my DNS servers to be non-recursive I avoid all those messages. Basically I can be careless about requests to any other domain names and can just start using the patch I made, because it will make no harm if some records will be mistakenly cached as an empty answer. But still I want comply to standards and to your recommendations as much as I can. So, based on your answer: Returning that answer to a stub resolver will cause the stub resolver to conclude that the name has no values. Caching it in dnsmasq will do that same thing. I modified the patch. Now it will store the answer in cache if server is non-recursive, BUT the answer IS authoritative. In this case referrals with empty answers should not make to the cache. Did I get it correct? What do you think? This doesn't make any difference with out-of-domain CNAME issue. I found a real example to illustrate. Consider www.bbc.co.uk ; DiG 9.9.5-3ubuntu0.1-Ubuntu www.bbc.co.uk ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 6149 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.bbc.co.uk. IN A ;; ANSWER SECTION: www.bbc.co.uk. 3 IN CNAME www.bbc.net.uk. www.bbc.net.uk. 3 IN A 212.58.244.67 www.bbc.net.uk. 3 IN A 212.58.244.66 Note that the answer is a cname to another domain, bbc.net.uk Now, lets do the exact same query to one of the authoritative nameservers for bbc.co.uk ; DiG 9.9.5-3ubuntu0.1-Ubuntu @ns1.rbsov.bbc.co.uk www.bbc.co.uk ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 8557 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.bbc.co.uk. IN A ;; ANSWER SECTION: www.bbc.co.uk. 300 IN CNAME www.bbc.net.uk. We get an authoritative answer (aa flag set) and we get the CNAME as before, but the A records are missing because they're in a domain that this server isn't authoritative for. Now those A records may really not exist, and a stub resolver will take that answer and assume they don't - it will fail to get an address for www.bbc.co.uk. There are two conditions that cause the CNAME chain to end: either the records it points to don't exist, or they are in another domain and the server you asked isn't a recursive server. There's no way to tell which is the case except to always ask a recursive server, or do the recursion yourself, ie do the query for www.bbc.net.uk. Dnsmasq doesn't do recursion itself, as a design decision, so it has to always has to ask a recursive server or risk getting a wrong answer. Note that this applies even to your recursive server. You can set things up so that only queries to your domain go to your recursive server but if that domain includes CNAMES that go outside that domain, or at sometime in the future someone makes a change that adds such a CNAME, then the answers from dnsmasq will mysteriously and subtly start to be wrong. Note that caching such answers is a last-ditch attempt to not make a bad situation worse, the answer returned is still wrong even without caching. This is why dnsmasq logs an error if an upstream nameserver doesn't offer recursion, and which you shouldn't use non-recursive upstream nameservers with dnsmasq, even for one domain. Cheers, Simon. Best, Nikolay - Original Message - From: Simon Kelley si...@thekelleys.org.uk To: dnsmasq-discuss@lists.thekelleys.org.uk Sent: Sunday, February 15, 2015 4:52:34 PM GMT -05:00 US/Canada Eastern Subject: Re: [Dnsmasq-discuss] non-recursive DNS ansewers patch The risk with this is if you forward a query to a non-recursive nameserver that it _isn't_ authoritative for. In that case you'll get a referal - ie a reply packet with an empty answer section
[Dnsmasq-discuss] non-recursive DNS ansewers patch
This question is for maintainers of Dnsmasq I want to consult you if the attached patch is safe. I am trying to develop a workaround for this: /* Don't put stuff from a truncated packet into the cache. Don't cache replies from non-recursive nameservers, since we may get a reply containing a CNAME but not its target, even though the target does exist. */ As currently implemented in src/rfc1035.c any answer from non-recursive DNS servers will not be cached. if (!(header-hb3 HB3_TC) !(header-hb4 HB4_CD) (header-hb4 HB4_RA) !no_cache_dnssec) cache_end_insert(); The attached patch enables caching of DNS answers from non-recursive servers IF the answer DOES NOT contain a CNAME record. Could you check the patch and let me know if I got it right and it is safe to implement? The patched code compiled successfully and worked OK so far. Best, Nikolaydiff -r -u ./a/src/rfc1035.c ./b/src/rfc1035.c --- ./a/src/rfc1035.c 2015-02-15 11:22:11.260714301 -0500 +++ ./b/src/rfc1035.c 2015-02-15 13:00:38.139708083 -0500 @@ -1152,7 +1152,7 @@ does exist. */ if (!(header-hb3 HB3_TC) !(header-hb4 HB4_CD) - (header-hb4 HB4_RA) + ( (header-hb4 HB4_RA) || ( !(header-hb4 HB4_RA) aqtype != T_CNAME ) ) !no_cache_dnssec) cache_end_insert(); ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] non-recursive DNS ansewers patch
Thank you, Simon. I see what you mean. As I mentioned earlier I have an internal network with two DNS servers which ARE authoritative for the domain I use. It will be great if I can make them recursive, but in this case their logs will be full of warnings that they couldn't reach particular DNS servers - you know many OS have some sort of auto update or NTP clients or other reasons to connect to the outside world by default. By making my DNS servers to be non-recursive I avoid all those messages. Basically I can be careless about requests to any other domain names and can just start using the patch I made, because it will make no harm if some records will be mistakenly cached as an empty answer. But still I want comply to standards and to your recommendations as much as I can. So, based on your answer: Returning that answer to a stub resolver will cause the stub resolver to conclude that the name has no values. Caching it in dnsmasq will do that same thing. I modified the patch. Now it will store the answer in cache if server is non-recursive, BUT the answer IS authoritative. In this case referrals with empty answers should not make to the cache. Did I get it correct? What do you think? Best, Nikolay - Original Message - From: Simon Kelley si...@thekelleys.org.uk To: dnsmasq-discuss@lists.thekelleys.org.uk Sent: Sunday, February 15, 2015 4:52:34 PM GMT -05:00 US/Canada Eastern Subject: Re: [Dnsmasq-discuss] non-recursive DNS ansewers patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The risk with this is if you forward a query to a non-recursive nameserver that it _isn't_ authoritative for. In that case you'll get a referal - ie a reply packet with an empty answer section, but one or more DNS servers in the authority section. Returning that answer to a stub resolver will cause the stub resolver to conclude that the name has no values. Caching it in dnsmasq will do that same thing. This is why dnsmasq logs an warning if any of its upstream nameservers are not recursive. If you insist on forwarding to an authoritative nameserver, it only makes sense to do that with queries for domains it is authoritative for. The patch doesn't make that any more unsafe than it already is, you'll still get the wrong answer if any replies are CNAMES to domains that the server doesn't cover. Dnsmasq really wants recursive upstream servers. Cheers, Simon. On 15/02/15 18:33, Nikolay P wrote: This question is for maintainers of Dnsmasq I want to consult you if the attached patch is safe. I am trying to develop a workaround for this: /* Don't put stuff from a truncated packet into the cache. Don't cache replies from non-recursive nameservers, since we may get a reply containing a CNAME but not its target, even though the target does exist. */ As currently implemented in src/rfc1035.c any answer from non-recursive DNS servers will not be cached. if (!(header-hb3 HB3_TC) !(header-hb4 HB4_CD) (header-hb4 HB4_RA) !no_cache_dnssec) cache_end_insert(); The attached patch enables caching of DNS answers from non-recursive servers IF the answer DOES NOT contain a CNAME record. Could you check the patch and let me know if I got it right and it is safe to implement? The patched code compiled successfully and worked OK so far. Best, Nikolay ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU4RUiAAoJEBXN2mrhkTWibIsP/jKs52JKioUSIrVpNOJhVEph BB+MAYtqAYbXfomfjcAcjzIAMELReYiwaI9jtqUOhnjTJoFrv27a3vBZnYvTqjQM E+yE6dUodveaJHUO2WU06Wd3fmVyUS2wqqKVe4PPF/vlxhrVZIibOglCHChCcTSL 9Uia7R0vOQXcjUB5ZovSWaVeImxDOmVSpWUq1zji7kWNS/+YfsckDSb0ignOSWDe BnznZeNeXkOIdBEA59wTxGa76PxJt4ytYtjR7F+3dK9MHjX2EgLq9oviNlmI+k9R PnH31XiPEXOQllGddiQjqA31jyZHmdc6ghUUsaem9Ql3SBJ0Eg7RJVuj4x8h8kvd zgK/MZHxU0O7JLmfmye3G5fNT8lTv9U6AO36If7nTZwbFKvJZ+4LDPkDUUDP3RQb zGaQN0I7wpoeD4veuLlqzoWUnSK3A5LckOUrXaeYkrtCUe1t9LJ4BsweYu4XENX1 CSPxhYNgdu7ZZy2xI//dAF1EGHXYAYSPFdnjqZ5U5uC7inCsZuvK8fxekxPduJKh pNbNPccj36awqab/n0pZ47PSEKalPn3wQEAOTL1457MU1p+G8/miAtLT7kCWmqFq qxDhUEOM7ImM+cibrJPFFOtdHuFY3T2we2t33SnBXhySIJquM0F3u/z9rFT1U8B9 fVNxCFPw0dWF/5rPk31L =qY65 -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss diff -r -u ./a/src/rfc1035.c ./b/src/rfc1035.c --- ./a/src/rfc1035.c 2015-02-15 11:22:11.260714301 -0500 +++ ./b/src/rfc1035.c 2015-02-15 17:22:23.016647692 -0500 @@ -1152,7 +1152,7 @@ does exist. */ if (!(header-hb3 HB3_TC) !(header-hb4 HB4_CD) - (header-hb4 HB4_RA) + ( (header-hb4 HB4_RA) || ( !(header-hb4 HB4_RA) (header-hb3 HB3_AA) ) ) !no_cache_dnssec) cache_end_insert
Re: [Dnsmasq-discuss] What if external DNS unreachable or timed out
Thank you. Well it looks like dnsmasq does not cache. When I send SIGUSR1 to dnsmasq (with log-queries option enabled) it returns list of cache which consists of one entry - 127.0.0.1 (flags 4FRI H). This is despite the fact that I performed dozen of queries just before. Log file looks like: query[A] host.domain from 127.0.0.1 forwarded host.domain to 10.0.0.1 reply host.domain is 10.0.10.10 query[A] host.domain from 127.0.0.1 forwarded host.domain to 10.0.0.1 reply host.domain is 10.0.10.10 query[A] host.domain from 127.0.0.1 forwarded host.domain to 10.0.0.1 reply host.domain is 10.0.10.10 10.0.0.1 is my internal DNS server (it is authoritative for domain domain) Is there known list of issues which can force dnsmasq not to cache replies? Otherwise I have no idea where to dig. - Original Message - From: /dev/rob0 r...@gmx.co.uk To: dnsmasq-discuss@lists.thekelleys.org.uk Sent: Thursday, February 12, 2015 10:13:40 PM GMT -05:00 US/Canada Eastern Subject: Re: [Dnsmasq-discuss] What if external DNS unreachable or timed out On Thu, Feb 12, 2015 at 08:43:20PM -0500, Nikolay P wrote: I am wondering what will happen if none of the external DNS servers are reachable or suddenly (for any reason) a DNS query to external servers timed out. Will Dnsmasq reply to the client's request from cache? Assume that this particular query is performed frequently and it should be in Dnsmasq cache. If the record is cached, dnsmasq is not going to ask an upstream nameserver. If a query is made to an upstream nameserver, that means the record is NOT in the cache. Then if the upstream query times out or otherwise fails, that's what dnsmasq will tell the client. So, will the Dnsmasq reply to the client's request from cache if none of the external servers replied? No, it wasn't cached. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ 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
[Dnsmasq-discuss] What if external DNS unreachable or timed out
The Dnsmasq home page says: The DNS subsystem provides a local DNS server for the network, with forwarding of all query types to upstream recursive DNS servers and cacheing of common record types (A, , CNAME and PTR, also DNSKEY and DS when DNSSEC is enabled). I am wondering what will happen if none of the external DNS servers are reachable or suddenly (for any reason) a DNS query to external servers timed out. Will Dnsmasq reply to the client's request from cache? Assume that this particular query is performed frequently and it should be in Dnsmasq cache. I am trying to handle a situation when my software sends a DNS query but (very rarely) the reply is being lost and my software runs into timeout. In attempt to resolve this I want to install Dnsmasq on those computers and run it on 127.0.0.1 so instead of asking external servers my software will be asking a local system. So, will the Dnsmasq reply to the client's request from cache if none of the external servers replied? Thank you for your attention. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
