Problem looking up a few domains
-
I don't use Unbound myself- I'm more of a Bind man - but every DNS server has to have forwarders in order to resolve non-authoritative queries. Check your configuration and see where the entry is for putting in your forwarders. This is almost certainly going to be the cause of the issue.
I'm not using any forwarders. I'm using a resolver. It should be going directly to the roots.
so it fails dnssec validation for one
Found DNSKEY, but no RRSIG, for algorithm 7
Which might be part of the problem.
Is this something on my end, or a misconfiguration on OSHA.gov's end?
-
Might be worth going through the steps outlined here: https://doc.pfsense.org/index.php/Unbound_DNS_Resolver#Configuration
In particular, there is a sections which states:
"Enable Forwarding Mode: Controls whether Unbound will query root servers directly (unchecked, disabled) or if queries will be forwarded to the upstream DNS servers defined under System > General or those obtained by DHCP/PPPoE/etc (checked, enabled). Forwarding mode may be enabled if the upstream DNS servers are trusted and also provide DNSSEC support. Forwarding mode is necessary for Multi-WAN Configurations. "So if you're failing to resolve hostnames against a root server, you could always test it using a public forwarder, such as '8.8.8.8', though from what I read you'd have to disable DNSSEC first.
-
Is this something on my end, or a misconfiguration on OSHA.gov's end?
No, most certainly not on your end. http://dnssec-debugger.verisignlabs.com/osha.gov
-
If you going to setup dnssec, you have to make sure you keep it updated and follow through that its working, etc.
Its really sad, but it is also sad the lack of support for it with registrars and dns providers. I put up a domain on dynadot to play with their dnssec support, and seems they do not allow different DS records pointing to the same key id. Yet the way I read the rfc there should be no issue with your different DS records pointing to the same key using different hashes, for example the older sha-1 and the newer sha-256.. You would want the older one so older validators could still work, etc. I can find multiple tlds with 2 DS records pointing to same key id, etc.
As to this osha.gov - their dnssec seems broken, which means your resolver shouldn't hand out their info, so you get servfail from the resolver. Might be nicer if they had some other error that says dnssec failure or something. But if you turn off dnssec support it resolves just fine
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.osha.gov. IN A;; ANSWER SECTION:
www.osha.gov. 3600 IN CNAME www.osha.gov.edgekey.net.
www.osha.gov.edgekey.net. 300 IN CNAME e6329.dscb.akamaiedge.net.
e6329.dscb.akamaiedge.net. 20 IN A 23.210.67.144But this sure seems to be on their end if you ask me. See attached, dnssec off works fine, enable dnssec and servfail because their dnssec setup is not valid.
-
If you going to setup dnssec, you have to make sure you keep it updated and follow through that its working, etc.
Its really sad, but it is also sad the lack of support for it with registrars and dns providers. I put up a domain on dynadot to play with their dnssec support, and seems they do not allow different DS records pointing to the same key id. Yet the way I read the rfc there should be no issue with your different DS records pointing to the same key using different hashes, for example the older sha-1 and the newer sha-256.. You would want the older one so older validators could still work, etc. I can find multiple tlds with 2 DS records pointing to same key id, etc.
As to this osha.gov - their dnssec seems broken, which means your resolver shouldn't hand out their info, so you get servfail from the resolver. Might be nicer if they had some other error that says dnssec failure or something. But if you turn off dnssec support it resolves just fine
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.osha.gov. IN A;; ANSWER SECTION:
www.osha.gov. 3600 IN CNAME www.osha.gov.edgekey.net.
www.osha.gov.edgekey.net. 300 IN CNAME e6329.dscb.akamaiedge.net.
e6329.dscb.akamaiedge.net. 20 IN A 23.210.67.144But this sure seems to be on their end if you ask me. See attached, dnssec off works fine, enable dnssec and servfail because their dnssec setup is not valid.
From PFSense, what needs to be done to keep DNSSec updated or did you mean on their end again?
-
There is no issue with pfSense here. Move on.
-
Their system, they have a broke dnssec config, anyone trying to validate it will fail.. Guess not a lot of people going there doing dnssec validation ;)
Dok gave you the link that can check a domains dnssec setup - theirs fails.. So you would hope your dnssec enabled resolver would not resolve it.. So unbound is doing what it was asked do
I just think it would be good idea when you do a query via like dig or drill to dns and the problem is with dnssec that it gives a different error other than servfail. Not something pfsense would have anything to do with.,
-
Their system, they have a broke dnssec config, anyone trying to validate it will fail.. Guess not a lot of people going there doing dnssec validation ;)
Dok gave you the link that can check a domains dnssec setup - theirs fails.. So you would hope your dnssec enabled resolver would not resolve it.. So unbound is doing what it was asked do
I just think it would be good idea when you do a query via like dig or drill to dns and the problem is with dnssec that it gives a different error other than servfail. Not something pfsense would have anything to do with.,
I agree there, it'd be nice to see something like DNSSECFAIL if it's failing on DNSSEC rather than just SERVFAIL which seems rather generic.
So far this is the first case of legitimate domain failing to load for this reason that I've run into. I switched to this setup after running into significant cache poisoning. -
So far this is the first case of legitimate domain failing to load for this reason that I've run into.
It's either signed properly, or it ain't legit… Needs to be fixed by the domain owner.
-
So far this is the first case of legitimate domain failing to load for this reason that I've run into.
It's either signed properly, or it ain't legit… Needs to be fixed by the domain owner.
I figured, but now… osha**.gov**
Maybe it'll work in a few years.
