[Dnsmasq-discuss] DNSSEC and Mozilla domains not working

Simon Kelley simon at thekelleys.org.uk
Sat Jul 16 22:48:11 BST 2016


On 15/07/16 00: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.

Just looking up ftp.mozilla.org on the upstream server won't cause
nslookup to make the query for DNSKEY mozilla.org which seems to be the
thing which is not being replied to. However the results of doing that
query with dig look good - which makes it more confusing as to why when
dnsmasq makes that query, it doesn't get an answer.

You may have to use something like Wireshark to try and see if the reply
to that query is arriving.


Cheers,

Simon.

> 
> Cheers, Marcel
> 
> _______________________________________________
> 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