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