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();
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to