Hi,
I’ve Omnia with the latest firmware 3.9.2 and I still experience problems with DNSSEC and with the standard Omnia configuration - nothing special configured. I know about two services that doesn’t work with Omnia DNSSEC. One of them is mozilla.com - my Firefox isn’t able to automatically download new update. The second are HBO Go servers - HBO Client on my LG Smart TV can’t connect them.
Has anybody similar problems?
Thank you! Confirmed.
As the exact issue seems slightly elusive, can you confirm that you use forwarding?
Yes, I use forwarding and my internet provider is Netbox CZ.
Preliminary results: some ISP’s servers are unable to answer cdn.mozilla.net DS, e.g.:
dig @2a02:768:0:1010::3 +dnssec cdn.mozilla.net DS
; <<>> DiG 9.11.2 <<>> @2a02:768:0:1010::3 +dnssec cdn.mozilla.net DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45812
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;cdn.mozilla.net. IN DS
;; Query time: 5 msec
;; SERVER: 2a02:768:0:1010::3#53(2a02:768:0:1010::3)
;; WHEN: Wed Jan 17 12:01:12 CET 2018
;; MSG SIZE rcvd: 44
it seems their validator is confused by DS query when CNAME appears. EDIT: and this case fails also when I add +cd (!!)
As a workaround, disabling forwarding should work, as knot-resolver’s validator doesn’t suffer from this. I can’t really see what your ISP’s server returns, but I assume it’s a similar problem to my ISP’s.
Than you for the analysis.
I’ll try to report the problem to my provider…
DNSSEC answer of my provider Netbox for cdn.mozilla.net is following:
dig cdn.mozilla.net +dnssec DS
; <<>> DiG 9.10.6 <<>> cdn.mozilla.net +dnssec DS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 13615
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;cdn.mozilla.net. IN DS
;; Query time: 24 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan 17 12:14:17 CET 2018
;; MSG SIZE rcvd: 44
That’s returned from localhost (127.0.0.1). You may add @1.2.3.4 to make it query a particular server.
DNSSEC answer of my provider with @83.240.0.136
; <<>> DiG 9.10.6 <<>> cdn.mozilla.net @83.240.0.136 +dnssec DS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27226
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;cdn.mozilla.net. IN DS
;; Query time: 21 msec
;; SERVER: 83.240.0.136#53(83.240.0.136)
;; WHEN: Wed Jan 17 12:42:49 CET 2018
;; MSG SIZE rcvd: 44Just want to add that I also have the same problem witch access Mozilla CDN and I am forwarding DNS requets to the the following DNS servers there are public available (from https://blog.uncensoreddns.org/):
91.239.100.100
89.233.43.71
In all such cases I can mainly recommend to (1) report the failing query to admins of such servers and/or (2) disable forwarding or choose more “reliable” servers. (Or disable DNSSEC validation, but I do not recommend that.)
My internet Netbox provider answered to my bug report, that it is the problem of mozilla DNS see http://dnssec-debugger.verisignlabs.com/cdn.mozilla.net
The same problem with certificate chain is also with cdn.hbogo.cz see http://dnssec-debugger.verisignlabs.com/cdn.hbogo.cz
It’s strange that e.g. Google DNS 8.8.8.8 is able to resolve them with DNSSEC without any problem…
That’s correct. The records don’t exist, because cloudfront.net provably chooses not to use DNSSEC (and their answer also has some minor problems, but nothing too bad). That should lead to NOERROR empty answer, not to SERVFAIL. I also recommend to the link inside to dnsviz.net analysis from Verisign.
I also have problems resolving Mozilla cdn sites (updater, installer …)
dig download-installer.cdn.mozilla.net
; <<>> DiG 9.10.3-P4-Ubuntu <<>> download-installer.cdn.mozilla.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9451
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;download-installer.cdn.mozilla.net. IN A
;; Query time: 11 msec
;; SERVER: 192.168.71.1#53(192.168.71.1)
;; WHEN: Sun Feb 04 09:49:22 CET 2018
;; MSG SIZE rcvd: 52
My Turris Omnia version is 3.9.4.
I have forwarding option “enabled” to Orange (French ISP) DNS (currently 81.253.149.6 and 80.10.246.136)
If I explicitely disable forwarding in Foris interface, resolution of Mozilla CDN is OK.
Laurent
I still have a SERVFAIL error when trying to resolve “download.cdn.mozilla.net” and other Mozilla CDNs with forwarding to my ISP DNS (Orange.fr : 80.10.246.134, 81.253.149.5)
I tried custom kresd config trust_anchors.negative = { 'download.cdn.mozilla.net' } with NO success.
I have Turris Omnia version 3.10.3 with Knot DNS Resolver, version 2.3.0
About kresd, is there a CLI command (via socat - UNIX-CONNECT:rundir/tty/* ) to list currently active FORWARD policies ?
Laurent
Seems either be inssue with kresd and/or the upstream resolver from Orange.
Try with another upstream resolver, e.g. 9.9.9.9 or 1.1.1.1 or 8.8.8.8. If works than the issue would appear to be with Orange’s DNS resolver. If it still happens than it would more likely be an issue with kresd
See if there is a difference in out put between dig @80.10.246.134 download.cdn.mozilla.net +dnssec and dig @9.9.9.9 download.cdn.mozilla.net +dnssec
With unbound just ran dig download.cdn.mozilla.net +dnssec
Note that the AD flag is absent from the response (that is with any upstream resolver I tried). Maybe that leads kresd to SERVFAIL - I am not familiar with the kresd error message causes however
; <<>> DiG 9.11.2-P1 <<>> download.cdn.mozilla.net +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18140
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 8, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;download.cdn.mozilla.net. IN A;; ANSWER SECTION:
download.cdn.mozilla.net. 300 IN CNAME 2-01-2967-001e.cdx.cedexis.net.
download.cdn.mozilla.net. 300 IN RRSIG CNAME 7 4 300 20180814013849 20180811003849 16943 mozilla.net. WS49//AewP6N/MjBUV94vV+MC++R4+YID42wgmj3SG6CmDjG8Dz+YjlN uUIHE4Q8RUBxzqz5ligjXAZrE5Sbtls97U3HtnYkXGUjpYwKgxxqieBX 3T5cSbZeFcuVmvNiQdzugfWF5GeuPQ9ssCE4bO4phPCd1SriDiyhszyP kL4=
2-01-2967-001e.cdx.cedexis.net. 20 IN CNAME cdn-mozilla-net.edgekey.net.
cdn-mozilla-net.edgekey.net. 21600 IN CNAME e8220.dscd.akamaiedge.net.
e8220.dscd.akamaiedge.net. 20 IN A 2.17.1.188;; AUTHORITY SECTION:
dscd.akamaiedge.net. 3539 IN NS n4dscd.akamaiedge.net.
dscd.akamaiedge.net. 3539 IN NS n6dscd.akamaiedge.net.
dscd.akamaiedge.net. 3539 IN NS n7dscd.akamaiedge.net.
dscd.akamaiedge.net. 3539 IN NS n2dscd.akamaiedge.net.
dscd.akamaiedge.net. 3539 IN NS n5dscd.akamaiedge.net.
dscd.akamaiedge.net. 3539 IN NS n3dscd.akamaiedge.net.
dscd.akamaiedge.net. 3539 IN NS n1dscd.akamaiedge.net.
dscd.akamaiedge.net. 3539 IN NS n0dscd.akamaiedge.net.;; Query time: 870 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Aug 11 20:37:07 CEST 2018
;; MSG SIZE rcvd: 523
Forwarding to Google DNS (8.8.8.8) works fine
dig @192.168.71.1 +dnssec download.cdn.mozilla.net
; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> @192.168.71.1 +dnssec download.cdn.mozilla.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3955
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;download.cdn.mozilla.net. IN A
;; ANSWER SECTION:
download.cdn.mozilla.net. 118 IN CNAME 2-01-2967-001e.cdx.cedexis.net.
download.cdn.mozilla.net. 118 IN RRSIG CNAME 7 4 300 20180814013849 20180811003849 16943 mozilla.net. WS49//AewP6N/MjBUV94vV+MC++R4+YID42wgmj3SG6CmDjG8Dz+YjlN uUIHE4Q8RUBxzqz5ligjXAZrE5Sbtls97U3HtnYkXGUjpYwKgxxqieBX 3T5cSbZeFcuVmvNiQdzugfWF5GeuPQ9ssCE4bO4phPCd1SriDiyhszyP kL4=
2-01-2967-001e.cdx.cedexis.net. 19 IN CNAME d2o47bxgqzkcc3.cloudfront.net.
d2o47bxgqzkcc3.cloudfront.net. 59 IN A 54.192.200.208
;; Query time: 387 msec
;; SERVER: 192.168.71.1#53(192.168.71.1)
;; WHEN: Sat Aug 11 21:13:26 CEST 2018
;; MSG SIZE rcvd: 348
I think the problem is within ISP DNS servers.
That seems very likely. You may also want to disable forwarding instead. (It depends a bit on situation, but that’s generally the mode preferred by me.)
AD is ignored on forwarding. Knot-resolver checks the signatures for itself. In this case AD must be missing, as part of the answer is in insecure part of DNS tree (CloudFront.net): http://dnsviz.net/d/download.cdn.mozilla.net/W28f8g/dnssec/
OK, I will disable ‘forwarding’ when I need to access Mozilla CDNs (Firefox updates).
Thanks