Different ways to setup DNS over TLS
-
@pfsvrb i am using DHCP. And the computer gets the IP of the Domain Controller (+DNS) 1 en 2.
But the DNS is configured to use PFSense as a DNS forward. When i the PFSense IP directly as DNS it does not make a difference.
We have a couple of settings differently (advanced tab), why did you change them? I also did that not that it made a difference :)
By the way, "Encrypted SNI" is also not marked green. Shouldn't this option also work when using Cloudflare (or Quad9)?
-
@operations
I'm not sure on SNI but my understanding is that it's only implemented at the browser level when using the browser configured DNS service. In our case, we're offloading DNS to a local resolver on our network, so I don't think we will see SNI. I could be wrong about this but, that's the basic understand that I have on the SNI part.I only posted my advanced settings to show my full config. I've noticed a small performance bump in some DNS test scores by messing around with them but it is very slight. I did notice a nice increase by using the "serve expired" option as this serves the last known good IP while also updating the DNS cache in the background. The risk is that it could also give you stale data. Use at your own risk but, it can be helpful to speed up DNS, especially with using DoT that has more overhead.
I'm sorry I don't have any other tips for you regarding the lack of DNSSEC. I'm sort of wondering if somehow the GRE tunnel is breaking it? But I have no proof of that and I personally am not familiar with them so I don't have a way to troubleshoot it.
As a last try, maybe post the output of this command and see if we notice anything out of the ordinary: cat /var/unbound/unbound.conf
-
Okee i get what you are saying. Here is the output:
##########################
Unbound Configuration
##########################
Server configuration
server:
local-zone: ".168.192.in-addr.arpa" typetransparent
local-zone: ".168.192.in-addr.arpa" typetransparent
local-zone: "*.*172.in-addr.arpa" typetransparentchroot: /var/unbound
username: "unbound"
directory: "/var/unbound"
pidfile: "/var/run/unbound.pid"
use-syslog: yes
port: 53
verbosity: 1
hide-identity: yes
hide-version: yes
harden-glue: yes
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
do-daemonize: yes
module-config: "validator iterator"
unwanted-reply-threshold: 0
num-queries-per-thread: 512
jostle-timeout: 200
infra-host-ttl: 900
infra-cache-numhosts: 10000
outgoing-num-tcp: 20
incoming-num-tcp: 20
edns-buffer-size: 1432
cache-max-ttl: 86400
cache-min-ttl: 0
harden-dnssec-stripped: no
msg-cache-size: 250m
rrset-cache-size: 500m
qname-minimisation: yesnum-threads: 4
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4
outgoing-range: 4096
#so-rcvbuf: 4m
auto-trust-anchor-file: /var/unbound/root.key
prefetch: yes
prefetch-key: yes
use-caps-for-id: no
serve-expired: yesStatistics
Unbound Statistics
statistics-interval: 0
extended-statistics: yes
statistics-cumulative: yesTLS Configuration
tls-cert-bundle: "/etc/ssl/cert.pem"
tls-port: 853
tls-service-pem: "/var/unbound/sslcert.crt"
tls-service-key: "/var/unbound/sslcert.key"Interface IP(s) to bind to
interface: 192.168..1
interface: 192.168..1@853
interface: 172...1
interface: 172...1@853
interface: 172...1
interface: 172...1@853
interface: 10...1
interface: 10...1@853
interface: 192.168..1
interface: 192.168..1@853
interface: fe80::feb6:126e%vmx1
interface: fe80::f:feb6:126e%vmx1@853
interface: fe80::feb6:126e%vmx1.20
interface: fe80::26e%vmx1.20@853
interface: fe8feb6:126e%vmx1.145
interface: fe80::250:126e%vmx1.145@853
interface: fe80::feb6:126e%vmx1.200
interface: fe80::feb6:126e%vmx1.200@853
interface: fe80::250::126e%vmx1.101
interface: fe80::250::126e%vmx1.101@853
interface: 127.0.0.1
interface: 127.0.0.1@853
interface: ::1
interface: ::1@853Outgoing interfaces to be used
DNS Rebinding
For DNS Rebinding prevention
private-address: 127.0.0.0/8
private-address: 10.0.0.0/8
private-address: ::ffff:a00:0/104
private-address: 172.16.0.0/12
private-address: ::ffff:ac10:0/108
private-address: 169.254.0.0/16
private-address: ::ffff:a9fe:0/112
private-address: 192.168.0.0/16
private-address: ::ffff:c0a8:0/112
private-address: fd00::/8
private-address: fe80::/10Set private domains in case authoritative name server returns a Private IP address
private-domain: ".168.192.in-addr.arpa"
domain-insecure: ".168.192.in-addr.arpa"
private-domain: ".168.192.in-addr.arpa"
domain-insecure: ".168.192.in-addr.arpa"
private-domain: "..172.in-addr.arpa"
domain-insecure: "..172.in-addr.arpa"
private-domain: "ad.domain.nl"
domain-insecure: "ad.domain.nl"Access lists
include: /var/unbound/access_lists.conf
Static host entries
include: /var/unbound/host_entries.conf
dhcp lease entries
include: /var/unbound/dhcpleases_entries.conf
Domain overrides
include: /var/unbound/domainoverrides.conf
Forwarding
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853#Cloudflare-dns.comUnbound custom options
server:
include: /var/unbound/pfb_dnsbl.*confRemote Control Config
include: /var/unbound/remotecontrol.conf
-
@operations
This config file still looks weird. It has the module config as "validator iterator". Do you have any other custom options defined? It seems like something is still over riding the pfSense Web GUI selections that were made for the DNS Resolver.Have you edited /var/unbound/unbound.conf?
-
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?
-
@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.
-
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: 512Is this correct? Cloudflare website + DNSSEC check still fails.
-
How are you going to do any queries when you don't have any outbound interfaces listed? Be it you forward or resolve?
-
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?
-
The config you posted list no outbound interfaces - so how and the hell would unbound query anything?
Oh you prob have ALL selected..
-
Yes i have selected ALL. Should i have done that differently? (Apart from my DNSSEC problem)
-
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..
-
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.
-
Any other ideas maybe?
-
@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 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.
-
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.
-
@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
unboundwould 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
unboundon pfSense I put in a domain override for my local AD domain that sendsunboundto 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 letunboundon pfSense take care of the DNSSEC part when resolving external hosts or domains. -
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.
-
@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
unbounddo it. So I switched the Windows DNS to forwarding and sent it to pfSense for external lookups. I haveunbounddoing the DNSSEC when resolving. And since then, not a single "random" hiccup from DNS.
