[Dnsmasq-discuss] non-recursive DNS ansewers patch

Nikolay P nikolay.p at cos.flag.org
Thu Feb 19 16:18:14 GMT 2015


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" <simon at thekelleys.org.uk>
To: dnsmasq-discuss at 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" 
> <simon at thekelleys.org.uk> To: 
> dnsmasq-discuss at 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,
> 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 at lists.thekelleys.org.uk 
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> 
> _______________________________________________ Dnsmasq-discuss 
> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> 
> 
> _______________________________________________ Dnsmasq-discuss 
> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJU47D3AAoJEBXN2mrhkTWiI+QP/RM0OGaVsYsBGoJtu/tWRPom
DIYWN/kbvKGLphoUAymdHG9H+2EKQmxl6CcF6fK8RioDUiuhbnsWEp2gF/MmKf5h
/ukJC3MMO+FmBqc3pW0ZRbHtje38A5rqRRFHQfnDcGSSinZkseYR1i0F06DEp5CX
93O22iMFuvBTCh329ZpGTCO9eD8Eh5u3OZI8OgQlZTsMndAGPxzvCPGai/vJ8gAc
3q9pxuWiLcRw/dbdLVhhO1VkHZ8v7IsdTWkQTZNJpdjgZbzqFPUjLT6PitKHPa3E
GYVUFpiZ06vKDBUcFR+D28+2rABp4DJq7tQBuIi/1mTt+3wrSLqu7iezkYOrmVU9
4CcbpjkflPe7Ra49VDZbc5thxKig7t1DwqNqWPE52sPJok1KUeuXejjAg0w8mbUh
v9e4DQnTkgAOh/8APXaPG5u84zf6ew/RxZYdqUZua+o640lz8xmdKvFxlhi8mGH6
gUQlJcR3qzgjp2e6Bz4d3jZ5ASbTyQNLVHfSsGuAon0U+IFnLsW8/V896BFRUxe5
rLyeTSG5EffaeXAyOopCcHRSOHrTxxkcfazF48ZmWsEysMgXCuPpj3sFzg3q2Rk8
i0n5xiAo/wrlborxe+k6U+xxn7rH82ezWwIY7z+CX3BOZaQROZZO/r8598AEzNzu
Y0TrCb2ohwr2tUmoUhwr
=Cx7B
-----END PGP SIGNATURE-----

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



More information about the Dnsmasq-discuss mailing list