[Dnsmasq-discuss] DNSSEC and Mozilla domains not working

mmmfotografie info at mmmfotografie.nl
Fri Jul 15 11:51:55 BST 2016


On 15-7-2016 1:13, mmmfotografie wrote:
> On 14-7-2016 23:22, Simon Kelley wrote:
>> On 12/07/16 00:17, mmmfotografie wrote:
>>> On 11-7-2016 23:08, Simon Kelley wrote:
>>>> I just tried all those domains using 2.76 and 8.8.8.8 upstream and all
>>>> behaved correctly. 194.109.9.99 won't talk to me, so I can't try that.
>>>>
>>>> The upstream is clearly answering the direct question OK, but the
>>>> stalling of some of the DNSSEC queries needed to verify it. That could
>>>> be an upstream problem, or a problem with the authoritative servers 
>>>> for
>>>> the domain. ftp.mozilla.org is signed, but it's a CNAME to
>>>> cloudfront.org, so the DS from .org proving that cloudfront.org is not
>>>> signed is also required.
>>>>
>>>> Are you still seeing the problem now, or has this resolved itself?
>>>>
>>>> Cheers,
>>>>
>>>> Simon.
>>> Thanks Simon for your reply and testing. I have now tried with 8.8.8.8
>>> and I have the same problem.
>>>
>>> I see that the DNSSEC on firefox.com and mozilla.com are now disabled
>>> and I don't get a "ad" on them when I use dig and the output of DNSmask
>>> states INSECURE. So maybe Mozilla is now working around that problem.
>>>
>>> mozilla.org will not resolve on 8.8.8.8 or 194.109.9.9  and the
>>> ftp.mozilla goes indeed through Cloudfront bit is not secure.
>>> .
>>> .
>>> .
>>> I have been testing a few setting...a lot of settings and combinations
>>> in the past hours and have now way to get a good response from DNSmasq.
>>>
>>> I first use "/dig +dnssec +multi mozilla.org @127.0.0.1/" which 
>>> seems to
>>> have more patience in waiting for a response. DNSmasq seems to do only
>>> one try when using dig and not three as with nslookup. DNSmasq is
>>> thinking about four seconds and then give a valid response using dig.
>>>
>>> dnsmasq: dnssec-query[DNSKEY] mozilla.org to 8.8.8.8
>>> dnsmasq: reply mozilla.org is DNSKEY keytag 22205, algo 7
>>> dnsmasq: reply mozilla.org is DNSKEY keytag 65337, algo 7
>>> dnsmasq: reply mozilla.org is DNSKEY keytag 44421, algo 7
>>> dnsmasq: reply mozilla.org is DNSKEY keytag 42422, algo 7
>>> dnsmasq: validation result is SECURE
>>> dnsmasq: reply mozilla.org is 63.245.215.20
>>>
>>> So on my standard upstream server:
>>> dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
>>> dnsmasq: reply mozilla.org is DNSKEY keytag 65337, algo 7
>>> dnsmasq: reply mozilla.org is DNSKEY keytag 22205, algo 7
>>> dnsmasq: reply mozilla.org is DNSKEY keytag 44421, algo 7
>>> dnsmasq: reply mozilla.org is DNSKEY keytag 42422, algo 7
>>> dnsmasq: validation result is SECURE
>>> dnsmasq: reply mozilla.org is 63.245.215.20
>>>
>>> Now the information is in the cache and a next request is instant.
>>>
>>> Also ftp.mozilla.org is instant now but insecure:
>>>
>>> dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
>>> dnsmasq: validation result is INSECURE
>>> dnsmasq: reply ftp.mozilla.org is <CNAME>
>>> dnsmasq: reply d34chcsvb7ug62.cloudfront.net is 52.85.250.4
>>> dnsmasq: query[AAAA] ftp.mozilla.org from 192.168.21.190
>>> dnsmasq: cached ftp.mozilla.org is <CNAME>
>>> dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
>>> dnsmasq: validation result is INSECURE
>>> dnsmasq: reply ftp.mozilla.org is <CNAME>
>>>
>>> And if I don't use dig mozilla.org or ftp.mozilla.org before the
>>> nslookup, it times out again:
>>>
>>> dnsmasq: reply . is DNSKEY keytag 46551, algo 8
>>> dnsmasq: reply . is DNSKEY keytag 19036, algo 8
>>> dnsmasq: reply org is DS keytag 9795, algo 7, digest 1
>>> dnsmasq: reply org is DS keytag 9795, algo 7, digest 2
>>> dnsmasq: dnssec-query[DS] mozilla.org to 194.109.9.99
>>> dnsmasq: dnssec-query[DNSKEY] org to 194.109.9.99
>>> dnsmasq: reply org is DNSKEY keytag 3177, algo 7
>>> dnsmasq: reply org is DNSKEY keytag 2097, algo 7
>>> dnsmasq: reply org is DNSKEY keytag 9795, algo 7
>>> dnsmasq: reply org is DNSKEY keytag 17883, algo 7
>>> dnsmasq: reply mozilla.org is DS keytag 44421, algo 7, digest 1
>>> dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
>>> dnsmasq: query[AAAA] ftp.mozilla.org from 192.168.21.190
>>> dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
>>> dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
>>> dnsmasq: query[A] ftp.mozilla.org from 192.168.21.190
>>> dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
>>> dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
>>> dnsmasq: query[AAAA] ftp.mozilla.org from 192.168.21.190
>>> dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
>>> dnsmasq: dnssec-query[DNSKEY] mozilla.org to 194.109.9.99
>>>
>>
>> So the problem seems to be that the reply to the query for DNSKEY on
>> mozilla.org is not being replied to in a reliable way.
>>
>> One possibility is that the reply is quite large (886 bytes) and
>> probably larger than most DNS replies. It has been known for firewalls
>> to do crazy things like rejecting all DNS packets >512 bytes, so it's
>> worth exploring that a bit more.
>>
>>
>> What happens when you use dig to make the same query?
>>
>> dig @8.8.8.8 dnskey mozilla.org
>> dig @194.109.9.99 dnskey mozilla.org
>>
>>
>> Cheers,
>>
>> Simon.
>
> Underneath you will find the outputs of the two dig requests:
>
> ; <<>> DiG 9.9.5-9+deb8u6-Raspbian <<>> @8.8.8.8 dnskey mozilla.org
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36160
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;mozilla.org.                   IN      DNSKEY
>
> ;; ANSWER SECTION:
> mozilla.org.            3829    IN      DNSKEY  257 3 7 
> Av//qpFLcHzrAyY8QUvs71dy1DDDUB2+8x36MDPAerY4fgV9P2Xp8xen 
> RYj8TeMiNLe82+1Uy77C6xTyNLRX61AHRUeRZ5oeI5oyjQ7756q3NGBY 
> C79o4ySY4KnMly3aKdIirApJ+TWu1RIII2r6A/e7yLYI/MJ2hIf91+nE 
> EJJDFyuAY6l2P52yffvmPqBnCQ2JslYewxh2Xd8H1ci/F95+RdZ7Q0EO 
> hiWLEDDs+Ox6xIec3oZK/iTuJ8O2MONtpX8fNd8mi/AKKi4CL0qI1khy 
> 9rYuIWOAu8ku7kOXMAedJd34jHvOesUqGLv7/fbU90rU3ZBEWkm3aQDY ouN7SGIe9w==
> mozilla.org.            3829    IN      DNSKEY  256 3 7 
> AwEAAcNjOiPUXVGfzePQkckHukkmO+WHLlK7qdJvTLv23zLDiGX61uyM 
> 42N1fqMxZ+a9e1MF7zc8IFH2JVrHTupIxKptdmmWbvTE03wOETR3PbDd 
> KfF1VW51mumpEW1YvXtJXWBtUAKGPJLykiEWpOp2NGnM/gPBYMaOiEg/ r2SnkVgH
> mozilla.org.            3829    IN      DNSKEY  256 3 7 
> AwEAAcE25kyUZz315hQhehOzJTrrOBqXQg2pCrY4ycw+Bpo/Kwdqwpwd 
> 0YTYAKya4Nl4IFkZJS9MCJmUysOLTLPCxTf0smw55oA1nFy0Ni1ZBbkQ 
> 2ZLJNpSvlN3s0sS3G0UJAjkWibJOuosgFBzdOdvqFoUgDQ3Fek/e5Ubv uRJo81Kb
> mozilla.org.            3829    IN      DNSKEY  257 3 7 
> Av//szWRDSGz3g4JkiuQqws79YZ6nwxk0f9PF9MCQSYrRGd0f4Vuuouf 
> aKdeFvdeY4x9tGmh7FQ51Qi6EEr9LLy2Q8qTtEuN2fJ4PnWBNRfKwhWb 
> SNQWvq1jwhsXlsAelLz7tO5kptI7TO16p2ncpnhJqfzT5mWJ4nK76YPZ 
> lu+MZlIYJOMv/OQWD2nVmsjXeO0dnsrL8MyC5wdyPy2gbksWBscsbwN2 
> 34APEYO48B6sovy2fuTVWnj7LDsEh3NzrhjGYlhWmtvrXg3mlFelz/MZ 
> XrK6uAlp6206Hc669ylfhIcD9d7w0rc9Ms1DFCh5wzVRbnJJF51mW2nC mh5C8E7xSw==
>
> ;; Query time: 9 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Fri Jul 15 00:22:10 CEST 2016
> ;; MSG SIZE  rcvd: 886;
>
>
> <<>> DiG 9.9.5-9+deb8u6-Raspbian <<>> @194.109.9.99 dnskey mozilla.org
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23980
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;mozilla.org.                   IN      DNSKEY
>
> ;; ANSWER SECTION:
> mozilla.org.            7149    IN      DNSKEY  257 3 7 
> Av//qpFLcHzrAyY8QUvs71dy1DDDUB2+8x36MDPAerY4fgV9P2Xp8xen 
> RYj8TeMiNLe82+1Uy77C6xTyNLRX61AHRUeRZ5oeI5oyjQ7756q3NGBY 
> C79o4ySY4KnMly3aKdIirApJ+TWu1RIII2r6A/e7yLYI/MJ2hIf91+nE 
> EJJDFyuAY6l2P52yffvmPqBnCQ2JslYewxh2Xd8H1ci/F95+RdZ7Q0EO 
> hiWLEDDs+Ox6xIec3oZK/iTuJ8O2MONtpX8fNd8mi/AKKi4CL0qI1khy 
> 9rYuIWOAu8ku7kOXMAedJd34jHvOesUqGLv7/fbU90rU3ZBEWkm3aQDY ouN7SGIe9w==
> mozilla.org.            7149    IN      DNSKEY  256 3 7 
> AwEAAcNjOiPUXVGfzePQkckHukkmO+WHLlK7qdJvTLv23zLDiGX61uyM 
> 42N1fqMxZ+a9e1MF7zc8IFH2JVrHTupIxKptdmmWbvTE03wOETR3PbDd 
> KfF1VW51mumpEW1YvXtJXWBtUAKGPJLykiEWpOp2NGnM/gPBYMaOiEg/ r2SnkVgH
> mozilla.org.            7149    IN      DNSKEY  256 3 7 
> AwEAAcE25kyUZz315hQhehOzJTrrOBqXQg2pCrY4ycw+Bpo/Kwdqwpwd 
> 0YTYAKya4Nl4IFkZJS9MCJmUysOLTLPCxTf0smw55oA1nFy0Ni1ZBbkQ 
> 2ZLJNpSvlN3s0sS3G0UJAjkWibJOuosgFBzdOdvqFoUgDQ3Fek/e5Ubv uRJo81Kb
> mozilla.org.            7149    IN      DNSKEY  257 3 7 
> Av//szWRDSGz3g4JkiuQqws79YZ6nwxk0f9PF9MCQSYrRGd0f4Vuuouf 
> aKdeFvdeY4x9tGmh7FQ51Qi6EEr9LLy2Q8qTtEuN2fJ4PnWBNRfKwhWb 
> SNQWvq1jwhsXlsAelLz7tO5kptI7TO16p2ncpnhJqfzT5mWJ4nK76YPZ 
> lu+MZlIYJOMv/OQWD2nVmsjXeO0dnsrL8MyC5wdyPy2gbksWBscsbwN2 
> 34APEYO48B6sovy2fuTVWnj7LDsEh3NzrhjGYlhWmtvrXg3mlFelz/MZ 
> XrK6uAlp6206Hc669ylfhIcD9d7w0rc9Ms1DFCh5wzVRbnJJF51mW2nC mh5C8E7xSw==
>
> ;; Query time: 5 msec
> ;; SERVER: 194.109.9.99#53(194.109.9.99)
> ;; WHEN: Fri Jul 15 00:22:33 CEST 2016
> ;; MSG SIZE  rcvd: 886
>
> I am going through a Mikrotik/RouterOS firewall. The firewall 
> (iptables), on the DNSmasq server self, is disabled. The Mikrotik 
> supports 4096 bytes according to the documentation.
>
> If the firewall would cause the problem then the timeout shoot also 
> occur when I do a nslookup at the 194.109.9.99 upstream server which 
> is not the case. Browsing by using directly the upstream DNS server 
> works fine. Only when the DNSmasq server is used the timeouts and 
> delays are present.
>
> Cheers, Marcel
>
I tried something new because I experienced that domains that could be 
found just after restarting DNSmasq a few hours later times out. So I 
put cache-size to zero but then on restarting DNSmasq did not returned 
because when with enabled DNSSEC this can not be zero. So I went back to 
default and disabled no-negcache that was still enabled.

In a few hours I will know if disabling no-negcache helped.

Cheers, Marcel



More information about the Dnsmasq-discuss mailing list