Discussion:
[Dnsmasq-discuss] DNSSEC and Mozilla domains not working
Marcel Mutter
2016-07-10 08:21:28 UTC
Permalink
I have enabled a few weeks ago DNSSEC and all seems to be working.
Yesterday I wanted to visit Mozilla.org and nothing happened. I see in
that the request is being sent to the upstream nameserver however
nothing is displayed by dnsmasq as response, I am running then "dnsmasq
-d" with log enabled so I can see in realtime the output.

dnsmasq: query[A] ftp.mozilla.org from 192.168.xxx.xxx
dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
dnsmasq: dnssec-query[DS] org to 194.109.9.99
dnsmasq: dnssec-query[DNSKEY] . to 194.109.9.99
dnsmasq: reply . is DNSKEY keytag 19036, algo 8
dnsmasq: reply . is DNSKEY keytag 60615, algo 8
dnsmasq: reply . is DNSKEY keytag 46551, 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 2097, algo 7
dnsmasq: reply org is DNSKEY keytag 3177, 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

Also the same with mozilla.org and mozilla.com and firefox.com

The upstreamserver 194.109.9.99 is using Unbound.

When I directly to the upstream nameserver I get a good response. I am
running dnsmasq 2.76-1 for Debian on the moment and I have updated it a
few a hours ago from 2.72-3.
Simon Kelley
2016-07-11 21:08:31 UTC
Permalink
Post by Marcel Mutter
I have enabled a few weeks ago DNSSEC and all seems to be working.
Yesterday I wanted to visit Mozilla.org and nothing happened. I see in
that the request is being sent to the upstream nameserver however
nothing is displayed by dnsmasq as response, I am running then "dnsmasq
-d" with log enabled so I can see in realtime the output.
dnsmasq: query[A] ftp.mozilla.org from 192.168.xxx.xxx
dnsmasq: forwarded ftp.mozilla.org to 194.109.9.99
dnsmasq: dnssec-query[DS] org to 194.109.9.99
dnsmasq: dnssec-query[DNSKEY] . to 194.109.9.99
dnsmasq: reply . is DNSKEY keytag 19036, algo 8
dnsmasq: reply . is DNSKEY keytag 60615, algo 8
dnsmasq: reply . is DNSKEY keytag 46551, 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 2097, algo 7
dnsmasq: reply org is DNSKEY keytag 3177, 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
Also the same with mozilla.org and mozilla.com and firefox.com
The upstreamserver 194.109.9.99 is using Unbound.
When I directly to the upstream nameserver I get a good response. I am
running dnsmasq 2.76-1 for Debian on the moment and I have updated it a
few a hours ago from 2.72-3.
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.
mmmfotografie
2016-07-11 23:17:25 UTC
Permalink
Post by Simon Kelley
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

Cheers, Marcel
Simon Kelley
2016-07-14 21:22:37 UTC
Permalink
Post by mmmfotografie
Post by Simon Kelley
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.
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
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.
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
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.
mmmfotografie
2016-07-14 23:13:49 UTC
Permalink
Post by Simon Kelley
Post by mmmfotografie
Post by Simon Kelley
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.
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
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.
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
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?
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
mmmfotografie
2016-07-15 10:51:55 UTC
Permalink
Post by mmmfotografie
Post by Simon Kelley
Post by mmmfotografie
Post by Simon Kelley
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.
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
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.
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
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?
Cheers,
Simon.
; (1 server found)
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36160
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 512
;mozilla.org. IN DNSKEY
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;
; (1 server found)
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23980
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 4096
;mozilla.org. IN DNSKEY
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
Simon Kelley
2016-07-16 21:48:11 UTC
Permalink
Post by mmmfotografie
Post by Simon Kelley
Post by mmmfotografie
Post by Simon Kelley
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.
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
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.
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
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?
Cheers,
Simon.
; (1 server found)
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36160
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 512
;mozilla.org. IN DNSKEY
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;
; (1 server found)
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23980
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 4096
;mozilla.org. IN DNSKEY
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.
Post by mmmfotografie
Cheers, Marcel
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
mmmfotografie
2016-10-22 21:50:45 UTC
Permalink
I want to revisit a problem I had three months ago with DNSSEC and some
external domains. I had no problem in that time until I tried to visit
raspberrypi.org and on my tablet I got a time out from DNSmasq. When I
tried on the server itself were DNSmasq is also running I got a instant
correct answer on a nslookup.

On the Win10 PC I got the following message:
Server: server-01
Address: 192.168.xxx.xxx
*** server-01 can't find raspberrypi.org: Unspecified error

On the server self:
;; Truncated, retrying in TCP mode.
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: raspberrypi.org
Address: 93.93.128.230
Name: raspberrypi.org
Address: 93.93.130.214

So I looked in the config files if I had anywhere defined
raspberrypi.org that was interfering and did not find it. So I looked in
/etc/hosts and there I had standing "127.0.0.1 raspberrypi" because that
is an alias for server-01. So I removed that alias and had to restart
DNSmasq to read the changed hosts file so testing if that was the
problem is not feasible anymore.

I think it has to do with time and DNSmasq was restarted a day before
and the problem occurs after a while so. What I am thinking (wild guess)
is that the DNSSEC is causing a problem in resolving the
raspberrypi.org. You see the name being split-up in steps and it reaches
the step of raspberrypi and then it is confused because that name is
also in the hosts file with an other IP.

After the restart of DNSmasq I have the following output and that is
working as intended:

dnsmasq: read /etc/hosts - 23 addresses
dnsmasq: query[PTR] 40.21.168.192.in-addr.arpa from 192.168.xxx.xxx
dnsmasq: /etc/hosts 192.168.xxx.xxx is server-01
dnsmasq: query[A] raspberrypi.org from 192.168.xxx.xxx
dnsmasq: forwarded raspberrypi.org to 194.109.9.99
dnsmasq: dnssec-query[DS] org to 194.109.9.99
dnsmasq: dnssec-query[DNSKEY] . to 194.109.9.99
dnsmasq: reply . is DNSKEY keytag 46551, algo 8
dnsmasq: reply . is DNSKEY keytag 19036, algo 8
dnsmasq: reply . is DNSKEY keytag 39291, 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] raspberrypi.org to 194.109.9.99
dnsmasq: dnssec-query[DNSKEY] org to 194.109.9.99
dnsmasq: reply org is DNSKEY keytag 17883, algo 7
dnsmasq: reply org is DNSKEY keytag 9795, algo 7
dnsmasq: reply org is DNSKEY keytag 64353, algo 7
dnsmasq: reply org is DNSKEY keytag 48497, algo 7
dnsmasq: reply raspberrypi.org is DS keytag 17226, algo 10, digest 2
dnsmasq: reply raspberrypi.org is DS keytag 55146, algo 10, digest 2
dnsmasq: dnssec-query[DNSKEY] raspberrypi.org to 194.109.9.99
dnsmasq: reply raspberrypi.org is DNSKEY keytag 55146, algo 10
dnsmasq: reply raspberrypi.org is DNSKEY keytag 17226, algo 10
dnsmasq: reply raspberrypi.org is DNSKEY keytag 20216, algo 10
dnsmasq: reply raspberrypi.org is DNSKEY keytag 4976, algo 10
dnsmasq: validation result is SECURE
dnsmasq: reply raspberrypi.org is 93.93.130.214
dnsmasq: reply raspberrypi.org is 93.93.128.230
dnsmasq: query[AAAA] raspberrypi.org from 192.168.xxx.xxx
dnsmasq: forwarded raspberrypi.org to 194.109.9.99
dnsmasq: validation result is SECURE
dnsmasq: reply raspberrypi.org is 2a00:1098:0:82:1000:13:0:5
dnsmasq: reply raspberrypi.org is 2a00:1098:0:80:1000:13:0:5

I looked up the log when the problem on the tabled occurred and that
does not show anything special except I get CNAME to lb.raspberrypi.org :

query[A] raspberrypi.org from 192.168.xxx.xxx
dnsmasq[15846]: forwarded raspberrypi.org to 194.109.9.99
dnsmasq[15846]: query[A] sitecheck2.opera.com from 192.168.xxx.xxx
dnsmasq[15846]: dnssec-query[DS] raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DNSKEY] org to 194.109.9.99
dnsmasq[15846]: reply raspberrypi.org is 93.93.128.230
dnsmasq[15846]: reply raspberrypi.org is 93.93.130.214
dnsmasq[15846]: query[A] raspberrypi.org from 192.168.xxx.xxx
dnsmasq[15846]: forwarded raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DS] raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DNSKEY] org to 194.109.9.99
dnsmasq[15846]: reply raspberrypi.org is 93.93.128.230
dnsmasq[15846]: reply raspberrypi.org is 93.93.130.214
dnsmasq[15846]: query[A] www.raspberrypi.org from 192.168.xxx.xxx
dnsmasq[15846]: forwarded www.raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DS] raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DNSKEY] org to 194.109.9.99
dnsmasq[15846]: reply www.raspberrypi.org is <CNAME>
dnsmasq[15846]: reply lb.raspberrypi.org is 46.235.227.11
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.130.236
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.128.133
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.130.214
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.130.39
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.128.230
dnsmasq[15846]: query[A] www.raspberrypi.org from 192.168.xxx.xxx
dnsmasq[15846]: forwarded www.raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DS] raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DNSKEY] org to 194.109.9.99
dnsmasq[15846]: reply www.raspberrypi.org is <CNAME>
dnsmasq[15846]: reply lb.raspberrypi.org is 46.235.227.11
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.130.236
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.128.133
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.130.214
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.130.39
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.128.230

DNSmasq version 2.76

Cheers, Marcel
mmmfotografie
2016-10-25 20:42:36 UTC
Permalink
I had to wait three days before my tablet did get in trouble again with
DNSmasq. I have now found out that er is a delay of more than six
seconds before the raspberrypi.org webpage is finally show in my PC and
that seems to be to long for the Opera browser on my Android. So no page
because of a time-out on my tablet.

The output of DNSmasq when there is a time-out:

Tablet:

Oct 25 21:24:42 server01 dnsmasq[21862]: forwarded www.raspberrypi.org
to 194.109.9.99
Oct 25 21:24:42 server01 dnsmasq[21862]: dnssec-query[DS]
raspberrypi.org to 194.109.9.99
Oct 25 21:24:42 server01 dnsmasq[21862]: dnssec-query[DNSKEY] org to
194.109.9.99
Oct 25 21:24:42 server01 dnsmasq[21862]: reply www.raspberrypi.org is
<CNAME>
Oct 25 21:24:42 server01 dnsmasq[21862]: reply lb.raspberrypi.org is
46.235.227.11
Oct 25 21:24:42 server01 dnsmasq[21862]: reply lb.raspberrypi.org is
93.93.130.236
Oct 25 21:24:42 server01 dnsmasq[21862]: reply lb.raspberrypi.org is
93.93.130.39
Oct 25 21:24:42 server01 dnsmasq[21862]: reply lb.raspberrypi.org is
93.93.128.133
Oct 25 21:24:42 server01 dnsmasq[21862]: reply lb.raspberrypi.org is
93.93.128.230
Oct 25 21:24:42 server01 dnsmasq[21862]: reply lb.raspberrypi.org is
93.93.130.214

Tablet after restart DNSmasq:

Oct 25 22:16:14 server01 dnsmasq[11258]: dnssec-query[DS]
raspberrypi.org to 194.109.9.99
Oct 25 22:16:14 server01 dnsmasq[11258]: dnssec-query[DNSKEY] org to
194.109.9.99
Oct 25 22:16:14 server01 dnsmasq[11258]: reply org is DNSKEY keytag
48497, algo 7
Oct 25 22:16:14 server01 dnsmasq[11258]: reply org is DNSKEY keytag
64353, algo 7
Oct 25 22:16:14 server01 dnsmasq[11258]: reply org is DNSKEY keytag
9795, algo 7
Oct 25 22:16:15 server01 dnsmasq[11258]: reply org is DNSKEY keytag
17883, algo 7
Oct 25 22:16:15 server01 dnsmasq[11258]: reply raspberrypi.org is DS
keytag 17226, algo 10, digest 2
Oct 25 22:16:15 server01 dnsmasq[11258]: reply raspberrypi.org is DS
keytag 55146, algo 10, digest 2
Oct 25 22:16:15 server01 dnsmasq[11258]: dnssec-query[DNSKEY]
raspberrypi.org to 194.109.9.99
Oct 25 22:16:15 server01 dnsmasq[11258]: reply raspberrypi.org is DNSKEY
keytag 20216, algo 10
Oct 25 22:16:15 server01 dnsmasq[11258]: reply raspberrypi.org is DNSKEY
keytag 5104, algo 10
Oct 25 22:16:15 server01 dnsmasq[11258]: reply raspberrypi.org is DNSKEY
keytag 55146, algo 10
Oct 25 22:16:15 server01 dnsmasq[11258]: reply raspberrypi.org is DNSKEY
keytag 17226, algo 10
Oct 25 22:16:15 server01 dnsmasq[11258]: validation result is SECURE
Oct 25 22:16:15 server01 dnsmasq[11258]: reply www.raspberrypi.org is
<CNAME>
Oct 25 22:16:15 server01 dnsmasq[11258]: reply lb.raspberrypi.org is
93.93.128.133
Oct 25 22:16:15 server01 dnsmasq[11258]: reply lb.raspberrypi.org is
93.93.128.230
Oct 25 22:16:15 server01 dnsmasq[11258]: reply lb.raspberrypi.org is
93.93.130.236
Oct 25 22:16:15 server01 dnsmasq[11258]: reply lb.raspberrypi.org is
93.93.130.39
Oct 25 22:16:15 server01 dnsmasq[11258]: reply lb.raspberrypi.org is
46.235.227.11
Oct 25 22:16:15 server01 dnsmasq[11258]: reply lb.raspberrypi.org is
93.93.130.214

PC and tablet shows the page instantly now.

Cheers Marcel
Post by mmmfotografie
I want to revisit a problem I had three months ago with DNSSEC and
some external domains. I had no problem in that time until I tried to
visit raspberrypi.org and on my tablet I got a time out from DNSmasq.
When I tried on the server itself were DNSmasq is also running I got a
instant correct answer on a nslookup.
Server: server-01
Address: 192.168.xxx.xxx
*** server-01 can't find raspberrypi.org: Unspecified error
;; Truncated, retrying in TCP mode.
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: raspberrypi.org
Address: 93.93.128.230
Name: raspberrypi.org
Address: 93.93.130.214
So I looked in the config files if I had anywhere defined
raspberrypi.org that was interfering and did not find it. So I looked
in /etc/hosts and there I had standing "127.0.0.1 raspberrypi" because
that is an alias for server-01. So I removed that alias and had to
restart DNSmasq to read the changed hosts file so testing if that was
the problem is not feasible anymore.
I think it has to do with time and DNSmasq was restarted a day before
and the problem occurs after a while so. What I am thinking (wild
guess) is that the DNSSEC is causing a problem in resolving the
raspberrypi.org. You see the name being split-up in steps and it
reaches the step of raspberrypi and then it is confused because that
name is also in the hosts file with an other IP.
After the restart of DNSmasq I have the following output and that is
dnsmasq: read /etc/hosts - 23 addresses
dnsmasq: query[PTR] 40.21.168.192.in-addr.arpa from 192.168.xxx.xxx
dnsmasq: /etc/hosts 192.168.xxx.xxx is server-01
dnsmasq: query[A] raspberrypi.org from 192.168.xxx.xxx
dnsmasq: forwarded raspberrypi.org to 194.109.9.99
dnsmasq: dnssec-query[DS] org to 194.109.9.99
dnsmasq: dnssec-query[DNSKEY] . to 194.109.9.99
dnsmasq: reply . is DNSKEY keytag 46551, algo 8
dnsmasq: reply . is DNSKEY keytag 19036, algo 8
dnsmasq: reply . is DNSKEY keytag 39291, 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] raspberrypi.org to 194.109.9.99
dnsmasq: dnssec-query[DNSKEY] org to 194.109.9.99
dnsmasq: reply org is DNSKEY keytag 17883, algo 7
dnsmasq: reply org is DNSKEY keytag 9795, algo 7
dnsmasq: reply org is DNSKEY keytag 64353, algo 7
dnsmasq: reply org is DNSKEY keytag 48497, algo 7
dnsmasq: reply raspberrypi.org is DS keytag 17226, algo 10, digest 2
dnsmasq: reply raspberrypi.org is DS keytag 55146, algo 10, digest 2
dnsmasq: dnssec-query[DNSKEY] raspberrypi.org to 194.109.9.99
dnsmasq: reply raspberrypi.org is DNSKEY keytag 55146, algo 10
dnsmasq: reply raspberrypi.org is DNSKEY keytag 17226, algo 10
dnsmasq: reply raspberrypi.org is DNSKEY keytag 20216, algo 10
dnsmasq: reply raspberrypi.org is DNSKEY keytag 4976, algo 10
dnsmasq: validation result is SECURE
dnsmasq: reply raspberrypi.org is 93.93.130.214
dnsmasq: reply raspberrypi.org is 93.93.128.230
dnsmasq: query[AAAA] raspberrypi.org from 192.168.xxx.xxx
dnsmasq: forwarded raspberrypi.org to 194.109.9.99
dnsmasq: validation result is SECURE
dnsmasq: reply raspberrypi.org is 2a00:1098:0:82:1000:13:0:5
dnsmasq: reply raspberrypi.org is 2a00:1098:0:80:1000:13:0:5
I looked up the log when the problem on the tabled occurred and that
query[A] raspberrypi.org from 192.168.xxx.xxx
dnsmasq[15846]: forwarded raspberrypi.org to 194.109.9.99
dnsmasq[15846]: query[A] sitecheck2.opera.com from 192.168.xxx.xxx
dnsmasq[15846]: dnssec-query[DS] raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DNSKEY] org to 194.109.9.99
dnsmasq[15846]: reply raspberrypi.org is 93.93.128.230
dnsmasq[15846]: reply raspberrypi.org is 93.93.130.214
dnsmasq[15846]: query[A] raspberrypi.org from 192.168.xxx.xxx
dnsmasq[15846]: forwarded raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DS] raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DNSKEY] org to 194.109.9.99
dnsmasq[15846]: reply raspberrypi.org is 93.93.128.230
dnsmasq[15846]: reply raspberrypi.org is 93.93.130.214
dnsmasq[15846]: query[A] www.raspberrypi.org from 192.168.xxx.xxx
dnsmasq[15846]: forwarded www.raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DS] raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DNSKEY] org to 194.109.9.99
dnsmasq[15846]: reply www.raspberrypi.org is <CNAME>
dnsmasq[15846]: reply lb.raspberrypi.org is 46.235.227.11
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.130.236
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.128.133
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.130.214
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.130.39
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.128.230
dnsmasq[15846]: query[A] www.raspberrypi.org from 192.168.xxx.xxx
dnsmasq[15846]: forwarded www.raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DS] raspberrypi.org to 194.109.9.99
dnsmasq[15846]: dnssec-query[DNSKEY] org to 194.109.9.99
dnsmasq[15846]: reply www.raspberrypi.org is <CNAME>
dnsmasq[15846]: reply lb.raspberrypi.org is 46.235.227.11
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.130.236
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.128.133
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.130.214
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.130.39
dnsmasq[15846]: reply lb.raspberrypi.org is 93.93.128.230
DNSmasq version 2.76
Cheers, Marcel
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
mmmfotografie
2016-07-13 19:15:20 UTC
Permalink
Hi, I just had a problem when I wanted to visit a site and when I looked
it up in the log-file I recognize a strange behavior, that I had before
when I had wen I had the "DNSSEC/TLSA Validator" as plug-in of Firefox.
It stopped completely browsing for a minute by becoming unresponsive.
This was only when I used DNSmasq and direct upstream replies went
without a hitch.

The bit of log underneath was without any plug-in so a plain request.
You see that the domain name is split up in parts and it first returns
the dot and then the org part.
forwarded www.raspberrypi.org to 194.109.9.99
dnssec-query[DS] org to 194.109.9.99
dnssec-query[DNSKEY] . to 194.109.9.99
reply . is DNSKEY keytag 46551, algo 8
reply . is DNSKEY keytag 19036, algo 8
reply org is DS keytag 9795, algo 7, digest 1
reply org is DS keytag 9795, algo 7, digest 2
dnssec-query[DS] raspberrypi.org to 194.109.9.99
dnssec-query[DNSKEY] org to 194.109.9.99
reply org is DNSKEY keytag 3177, algo 7
reply org is DNSKEY keytag 2097, algo 7
reply org is DNSKEY keytag 17883, algo 7
reply org is DNSKEY keytag 9795, algo 7
reply raspberrypi.org is DS keytag 21912, algo 10, digest 2
dnssec-query[DNSKEY] raspberrypi.org to 194.109.9.99
reply raspberrypi.org is DNSKEY keytag 23657, algo 10
reply raspberrypi.org is DNSKEY keytag 21912, algo 10
reply raspberrypi.org is DNSKEY keytag 12500, algo 10
validation result is SECURE
Going to try the 8.8.8.8 with the plug-in and see if it can be
replicated on a other nameserver.
Simon Kelley
2016-07-14 21:26:45 UTC
Permalink
Post by mmmfotografie
Hi, I just had a problem when I wanted to visit a site and when I looked
it up in the log-file I recognize a strange behavior, that I had before
when I had wen I had the "DNSSEC/TLSA Validator" as plug-in of Firefox.
It stopped completely browsing for a minute by becoming unresponsive.
This was only when I used DNSmasq and direct upstream replies went
without a hitch.
The bit of log underneath was without any plug-in so a plain request.
You see that the domain name is split up in parts and it first returns
the dot and then the org part.
forwarded www.raspberrypi.org to 194.109.9.99
dnssec-query[DS] org to 194.109.9.99
dnssec-query[DNSKEY] . to 194.109.9.99
reply . is DNSKEY keytag 46551, algo 8
reply . is DNSKEY keytag 19036, algo 8
reply org is DS keytag 9795, algo 7, digest 1
reply org is DS keytag 9795, algo 7, digest 2
dnssec-query[DS] raspberrypi.org to 194.109.9.99
dnssec-query[DNSKEY] org to 194.109.9.99
reply org is DNSKEY keytag 3177, algo 7
reply org is DNSKEY keytag 2097, algo 7
reply org is DNSKEY keytag 17883, algo 7
reply org is DNSKEY keytag 9795, algo 7
reply raspberrypi.org is DS keytag 21912, algo 10, digest 2
dnssec-query[DNSKEY] raspberrypi.org to 194.109.9.99
reply raspberrypi.org is DNSKEY keytag 23657, algo 10
reply raspberrypi.org is DNSKEY keytag 21912, algo 10
reply raspberrypi.org is DNSKEY keytag 12500, algo 10
validation result is SECURE
Going to try the 8.8.8.8 with the plug-in and see if it can be
replicated on a other nameserver.
That's quite normal. Dnsmasq knows the public key for the root zone, and
it has to make queries for DS and DNSKEY records that extend the
chain-of-trust from the root to the domain that you asked for. Those
queries are generated by dnsmasq and logged as "dnssec-query".

Cheers,

Simon.
Post by mmmfotografie
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Loading...