Different ways to setup DNS over TLS

Operations

To be completely honest, i don't even know how to do that. I have installed PFBlocker, is that maybe the source of the problem?

By the way how do i edit that or other conf files? By using SSH?

Edit; also no other custom options. Where would i do that?

pfsvrb

@operations
I was asking about directly editing it, such as with vi.

I don't use PFBlocker, so I'm not sure what impact it may be having here.

The "validator iterator" in the module config basically means that DNSSEC is still enabled on the pfSense resolver. This doesn't make sense because in the screenshots you show this is unchecked. But I suspect that is what is interfering with your DNSSEC test results. However I'm not sure what else might be forcing that feature to stay on.

Operations

@pfsvrb

I have turn it on/off plus reboot now it says:

do-daemonize: yes
module-config: "iterator"
unwanted-reply-threshold: 0
num-queries-per-thread: 512

Is this correct? Cloudflare website + DNSSEC check still fails.

johnpoz

How are you going to do any queries when you don't have any outbound interfaces listed? Be it you forward or resolve?

Operations

@johnpoz

I am sorry but i am not sure how to answer / what you are asking. Could you "dumb it down" a bit? / or tell me if i made a mistake what to change?

johnpoz

The config you posted list no outbound interfaces - so how and the hell would unbound query anything?

Oh you prob have ALL selected..

Operations

@johnpoz

Yes i have selected ALL. Should i have done that differently? (Apart from my DNSSEC problem)

johnpoz

I personally like to just use localhost as outbound.. This will nat to whatever interface your using outbound, be it you have multiple or vpn, etc. Without having to bind to any specific interface - incase the interface is not up when unbound starts..

Operations

@johnpoz

I am not sure what you mean, not binding to a specific interface (by using ALL) will that not have the same result as "use localhost as outbound.. This will nat to whatever interface your using outbound" ?

ALL = whatever interface? Or am i missing something / not getting it.

Operations

@pfsvrb

Any other ideas maybe?

pfsvrb

@operations
Sorry I'm not sure what else to try. I can't replicate the results you're seeing. I get DNSSEC validated results whether I used Quad9 or CloudFlare with the same configs that I've posted in my screenshots.

Operations

@pfsvrb said in Different ways to setup DNS over TLS:

@operations
Sorry I'm not sure what else to try. I can't replicate the results you're seeing. I get DNSSEC validated results whether I used Quad9 or CloudFlare with the same configs that I've posted in my screenshots.

@pfsvrb
I use a Windows domain so my client looks at DC for DNS and the DC (with DNS role) looks at PFSense.

When i use PFSense directly it does work. So the problem is my DC. Sorry i didnt mention this before.

johnpoz

What doesn't work? Exactly? You have your AD DNS forwarding to unbound on pfsense. You can not look up anything, only dnssec stuff fails? What?

Pfsense doesn't care if its a client asking or another NS.. Unless you AD dns is downstream of pfsense networks, and the acl is blocking.. unbound can not tell the difference between just some client asking for www.google.com or your DNS on your AD asking for - to unbound its just another client.

bmeeks

@operations said in Different ways to setup DNS over TLS:

@pfsvrb said in Different ways to setup DNS over TLS:

@operations
Sorry I'm not sure what else to try. I can't replicate the results you're seeing. I get DNSSEC validated results whether I used Quad9 or CloudFlare with the same configs that I've posted in my screenshots.

@pfsvrb
I use a Windows domain so my client looks at DC for DNS and the DC (with DNS role) looks at PFSense.

When i use PFSense directly it does work. So the problem is my DC. Sorry i didnt mention this before.

I had some random issues with DNS lookups on my 2012 R2 AD DNS server when I enabled DNSSEC. Most things worked fine, but every now and then I would get seemingly random DNS errors in the browser (mostly). The one that broke the camel's back, as they say, was a persistent issue with www.cdc.gov. @johnpoz determined that the CDC DNS entries are borked and that was causing the problem. But unbound would resolve it just fine. Only the Windows AD DNS got tripped up.

So I wound up turning off DNSSEC on the Windows AD DNS and changing it to forwarding mode with my pfSense box as the forwarder. So in unbound on pfSense I put in a domain override for my local AD domain that sends unbound to my AD server for those lookups (like pfSense log and ARP entries, for example). Local clients still point to the AD DNS server for DNS. Now everything just seems to work reliably and I have not had a single "random" DNS issue since.

So my takeaway is Windows AD DNS (at least in 2012 R2, which is old I admit) can get tripped up with DNSSEC now and then. That may be your problem, too. Since you state you are forwarding to unbound, just make sure you have turned off DNSSEC on the Windows DNS and let unbound on pfSense take care of the DNSSEC part when resolving external hosts or domains.

johnpoz

He already is I thought?

I use a Windows domain so my client looks at DC for DNS and the DC (with DNS role) looks at PFSense.

If he is forwarding - then yeah enabling dnssec is going to cause issues..

I have been over this atleast 100 times it seems... If you forward.. You do not set dnssec, you forward to a resolver that does dnssec. If you want dnssec, if you don't then forward to a resolver that doesn't do it.. There is no forwarding and asking for dnssec that ever makes sense.. Ever.. Only a resolver does dnssec.

No wonder he could having issues if that is what he is doing.

bmeeks

@johnpoz said in Different ways to setup DNS over TLS:

He already is I thought?

I use a Windows domain so my client looks at DC for DNS and the DC (with DNS role) looks at PFSense.

If he is forwarding - then yeah enabling dnssec is going to cause issues..

I have been over this atleast 100 times it seems... If you forward.. You do not set dnssec, you forward to a resolver that does dnssec. If you want dnssec, if you don't then forward to a resolver that doesn't do it.. There is no forwarding and asking for dnssec that ever makes sense.. Ever.. Only a resolver does dnssec.

No wonder he could having issues if that is what he is doing.

He did say forwarding, but did not say whether he disabled DNSSEC on the Windows side (if you had it on).

Yeah, I originally had Windows AD DNS using the root servers. Later I enabled DNSSEC and that's when the random failures started. They were very sporadic. Most of the time I just attributed them to maybe actual issues with the host domains or something. But the CDC site thing was persistent, and after the info you posted I decided to just stop DNSSEC with Windows and let unbound do it. So I switched the Windows DNS to forwarding and sent it to pfSense for external lookups. I have unbound doing the DNSSEC when resolving. And since then, not a single "random" hiccup from DNS.

johnpoz

If ad dns was resolving - then yeah you can set dnssec. But sure with something like what is going on with cdc.gov.. Its going to be luck of the draw.. I haven't seen a domain so F'd up from a major player for this long in a long time..

Its really sad.. As I mentioned earlier whoever is in charge of their dns shouldn't be doing dns..

There was a link to some cloudlfare thread where cloudlfare was putting in work arounds to try and make sure issue doesn't keep stuff from resolving.. That is the WRONG thing to do.. If their dnssec is borked, then it shouldn't resolve.. And companies like cloudflare and googledns, quad9 should call them out on it vs trying to work around their mess.

bmeeks

@johnpoz said in Different ways to setup DNS over TLS:

If ad dns was resolving - then yeah you can set dnssec. But sure with something like what is going on with cdc.gov.. Its going to be luck of the draw.. I haven't seen a domain so F'd up from a major player for this long in a long time..

Its really sad.. As I mentioned earlier whoever is in charge of their dns shouldn't be doing dns..

Similar to this, the Social Security web site would not work with IPv6 for weeks and weeks like a couple of years ago. They returned IPv6 addresses, but you couldn't connect. I would have to disable my HE IPv6 tunnel in order to access the site (or go through all the steps to get Windows and Chrome to prefer IPv4 first).

Maybe it's the old incompetent government employee thing ... .

johnpoz

I personally don't think ipv6 is really ready for prime time ;) While I have it on the network, and do even provide services to ntp pool on it. I set "my" machines to use IPv4... Until such time there is a resource that only can be gotten to via IPv6 that I actually want/need to get to - it not prime time.

That is many many years off it seems ;) I will be retired from the biz pretty sure.. Even though I would love nothing more for it not to be that.. But for now mobile devices are really the only prime time users of ipv6, and they go through ipv6 to ipv4 gateways to get to most of the net ;)

bmeeks

I'm with you on IPv6. I was trying it out, though, with the HE tunnel. Finally abandoned it for now. Kept getting in the way of the grandkids trying to watch cartoons on their iPads via Netflix. And I didn't want to keep jumping through all the policy routing, DNS mods and ASN aliases to keep their iPads going out via IPv4.

Like you, I have no real need for IPv6, so I just turned off my tunnel for now. If my cable provider ever offers the service, I will enable it on my network. That way I won't have to fight the streaming services blocking Hurricane Electric space. Really that's the biggest reason I disabled the HE tunnel.