Unbound, DNSSEC, and co.uk domains
-
I noticed lately that I am unable to resolve any co.uk domain names against unbound in pfSense with DNSSEC enabled. Here is query level log output of trying to lookup google.co.uk - https://pastebin.com/y4CCBws8
The domain lookup is successful in Diagnostics -> DNS Lookup wether DNSSEC is enabled or not, but lookups against 192.168.1.1 return nothing when it is enabled.
#: dig @192.168.1.1 google.co.uk ; <<>> DiG 9.10.6 <<>> @192.168.1.1 google.co.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11563 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.co.uk. IN A ;; Query time: 547 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Aug 19 06:43:38 MST 2018 ;; MSG SIZE rcvd: 41This does not happen with other double TLD's as far as I can tell, for example google.co.nz lookup works with DNSSEC enabled. I did confirm the same behavior with other .co.uk domains as well, so it's not specific to google.co.uk - they all exhibit the same behavior. I've tried both with "Harden DNSSEC Data" and without and get the same result with both settings. Anyone have any idea what I might be doing wrong here?
-
@rjorgenson said in Unbound, DNSSEC, and co.uk domains:
google.co.uk
resolves here
<<>> DiG 9.12.2 <<>> google.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11508
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.co.uk. IN A;; ANSWER SECTION:
google.co.uk. 300 IN A 172.217.1.35;; Query time: 203 msec
;; SERVER: 192.168.3.10#53(192.168.3.10)
;; WHEN: Sun Aug 19 10:12:54 Central Daylight Time 2018
;; MSG SIZE rcvd: 57But I do show them with formerror problems - so they prob have an issue with edns/dnscookies
http://dnsviz.net/d/google.co.uk/dnssec/
Your version of of dig is a dated and I don't think it supports dnscookies.. which I believe were enabled in 9.11
Yeah they clearly have some issues
https://ednscomp.isc.org/ednscomp/044369457eAre you actually resolving - or do you have unbound forwarding?
-
Unbound is set to forward and I have 1.1.1.1 configured as the upstream. I tested the lookup using the same tools against 1.1.1.1 and the domains resolved as expected. I tried turning off forwarding and the domains I tested previously all resolve now. So I can either turn off DNSSEC or disable forwarding and the lookups will work but if either are on it fails.
-
forwarding dnssec is pointless if you ask me.. Either just forward and live with what you get or resolve and use dnssec..
The whole point of dnssec is to validate the records are correct from authoritative ns.. if your just going to forward and ask 1.2.3.4 you have thrown out the whole point of dnssec validation anyway.. The forwarder your asking could hand you anything it wants..
-
I'm not entirely sure if the merits/consequences of doing either, I believe this was the default setting. It has been forever since I originally configured my pfSense though so I can't say for sure. Is there any reason why I would want to forward over resolving myself?
-
Resolving is always better! ;) You are not handing all your dns queries to someone else and trusting they give you the correct and current IP.
With resolving you walk down the tree from roots and actually talk to the authoritative ns for what your looking for.. With dnssec you actually validate is in fact the case all the way down from root.
With forwarding your doing nothing but playing a game of telephone and hoping what you get is correct.. Do what you want, but if your going to forward there is really little reason to ask for dnssec,
The only reason you would want to forward over resolve is if our on some really bad latency connection, or the connection your on prevents it.. Satellite connection for example is not conducive to resolving.
Pfsense out of the box resolves with dnssec enabled.. They didn't pick this mode of operation for no reason.
-
@johnpoz said in Unbound, DNSSEC, and co.uk domains:
With forwarding your doing nothing but playing a game of telephone and hoping what you get is correct.. Do what you want, but if your going to forward there is really little reason to ask for dnssec,
Good to know, thanks =]
For what it's worth to anyone else who stumbles upon this I tried 9.9.9.9 instead and the domains resolve fine with forwarding and DNSSEC. Seems to be something with the way 1.1.1.1 handles the query.
-
You do understand that quad 9 has stated they resolve via dnssec.. So you forwarding dnssec to them is pointless and your just adding to your overall dns traffic for no reason.
https://www.quad9.net/faq/#Does_Quad9_implement_DNSSEC
If your going to forward there is little reason to ask for dnssec, either the end of the tunnel resolver is going to be using it and not returning an answer per what dnssec is suppose to do.. Or they are not going to do anything with it and just forward it upstream to either another forwarder or a resolver - does this resolver support dnssec? Again you do not know because your at the mercy of who you forwarded your traffic too.. Be it they do what they say they do or not, etc.
When you resolve you KNOW exactly what is going on and where your getting the data from - if it fails you can look to why.. When you forward your asking a black box for an answer.. How it got the answer do not actually know, nor do you actually know what they might be doing with said data, etc. etc.
Seems to be something with the way 1.1.1.1 handles the query.
Welcome to the black box you are forwarding your all your queries too ;)
-
Yes I understand that, you explained it pretty well. I was just adding more info in case anyone stumbles upon the the issue created by this particular configuration(which as you stated is pointless) with 1.1.1.1 - Just because it's pointless doesn't mean someone else won't run into the issue with that configuration and want to know why. I was unable to find anything using various searches and just trying to leave something someone else might be able to find in the future. I have turned forwarding off personally.
-
Then why are did you state you have dnssec enabled when forwarding to quad 9? Doesn't seem like you understand from you doing that.
-
Because I didn't understand =] I tried the forwarding with quad9 to see if it was an issue specific to 1.1.1.1 or if it was an overall issue with having those two boxes checked in the Resolver configuration. I just felt it was worth writing down for anyone who makes the same poor decisions I did in the future and doesn't understand them. They can find the answer without having to ask someone. I'm no DNS expert. Beyond "this setting makes it use the DNS servers I configured for lookups" I didn't really know what forwarding meant or why I might want it on or off. It's not a decisions I consciously made to use DNSSEC and forward because I think it's the right thing to do. It's just the state my Resolver configuration ended up in, which didn't work which is how I ended up here. Now I have a better idea and hopefully so will the next person.
-
Agreed, the more discussion of how dns works the better for the end user.. It seems to be a black box for many of them.
-
Strange indeed :
[2.4.3-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: dig @192.168.1.1 google.co.uk ; <<>> DiG 9.11.2-P1 <<>> @192.168.1.1 google.co.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60086 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.co.uk. IN A ;; ANSWER SECTION: google.co.uk. 300 IN A 216.58.212.131 ;; Query time: 167 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Mon Aug 20 07:32:50 CEST 2018 ;; MSG SIZE rcvd: 57Btw : I have "Harden DNSSEC Data" checked
The Resolver is working in resolver mode, right (no forwarding) ?
edit : stupid me, answered to your initial post - didn't saw the follow up, that completely solved the "issue" already.
