How to Use DNS Over TLS Server Option

ProfessorManhattan

I have encrypted DNS set up with CloudFlare. So pfSense to CloudFlare is encrypted. I saw that there is an option that says " Respond to incoming SSL/TLS queries from local clients". I checked/saved it. I then set up systemd-resolved on my Ubuntu computer to use the following configuration:

[Resolve]
DNS=10.0.0.1
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
DNSOverTLS=yes
#Cache=yes
#DNSStubListener=yes
#ReadEtcHosts=yes

The 10.0.0.1 address is the same default DNS server that shows up in the NetworkManager GUI (retrieved via DHCP from pfSense). However, with it set up like this, the DNS is not resolving. I tried this all with pfSense interfaces with allow any so it's not the firewall that's blocking this.

Does anyone know how I can make use of this feature to encrypt DNS on my LAN?

kiokoman

i don't use unbound or dnsmasq from pfsense but i'm using bind9 on a dedicated server
i'm actualing experimenting with Stunnel, it's a package available for pfsense

if you want to try you just need to change Listen on IP with the ip of your pfsense LAN interface
and redirect to 127.0.0.1 if you are using unbound

laboratorio@server:~$ kdig -d @192.168.10.254 +tls A example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(192.168.10.254), port(853), protocol(TCP)
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, O=\ stunnel Self-Signed Certificate,CN=-5f59f89235517
;; DEBUG:      SHA-256 PIN: 5DvHFGivDD6/4BZjcNeIk1dNTmTEkq+CZyNadX9pWEw=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, skipping certificate verification
;; TLS session (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 16661
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1432 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; example.com.                 IN      A

;; ANSWER SECTION:
example.com.            73918   IN      A       93.184.216.34

;; Received 56 B
;; Time 2020-09-10 15:50:30 CEST
;; From 192.168.10.254@853(TCP) in 32.1 ms

you can use kdig like on my example to test DoT
part of knot-dnsutils

I still don't know if a browser will work happily with this
it's a work in progress
also i don't even know how i will ever use this... it's pretty useless, i'm just doing it to learn and understand this stuff

JeGr

@ProfessorManhattan said in How to Use DNS Over TLS Server Option:

Does anyone know how I can make use of this feature to encrypt DNS on my LAN?

Are you getting any logs or reports on your client to what is not working? Otherwise check with a tcpdump on pfsense and your client, if it really is talking on tcp/853 and pfSense receiving it. If that's the case, check if the certificate you use for unbound/DNS Resolver is a valid one or your client does accept it. After all it's TLS thus requiring a valid TLS certificate.

johnpoz

Why would anyone want to do this? Is your local lan hostile where someone is sniffing the traffic and taking your dns queries and monetizing them?

Is your dns not slow enough using tls? So you want to add more overhead on your own local part of it to make it even slower?

Just because something can do X, doesn't mean it makes sense in your scenario to use X..

Why would dns queries on your own local network need to be encrypted inside a tunnel?

kiokoman

i'm selling the dns query of my wife... if someone is interested.. he can bid for it ...

ProfessorManhattan

@johnpoz Yes, a possibly hostile LAN

johnpoz

@ProfessorManhattan said in How to Use DNS Over TLS Server Option:

hostile LAN

For my own curiosity, could you explain how a lan that you control? You for sure control the router pfsense.. How exactly the L2 your devices connected to so outside your control that it could be hostile?

If hostile lan is the case - then you should actually VPN from your client to pfsense, and send all traffic through the vpn..

Please explain the scenario where it makes sense to put my dns inside a tunnel, but NOT all traffic.. Especially when the L2 is now hostile.. DNS would be the least of my concerns on a hostile L2..

A Former User

I talked to a guy in the coffee shop who knows a guy who said his father-in-law read somewhere...

Come on people, it is possible to do better than this. If you don't trust a device, don't put it on your network. Take it back to best-buy and get your money back. Oh yeah, don't let your neighbors 13 year old use your wifi.

A Former User

This post is deleted!

johnpoz

@jwj said in How to Use DNS Over TLS Server Option:

I talked to a guy in the coffee shop who knows a guy who said his father-in-law read somewhere...

This is clearly in the top right corner of gartner for where and how to get your security information ;)

A Former User

@johnpoz said in How to Use DNS Over TLS Server Option:

@jwj said in How to Use DNS Over TLS Server Option:

I talked to a guy in the coffee shop who knows a guy who said his father-in-law read somewhere...

This is clearly in the top right corner of gartner for where and how to get your security information ;)

In all honesty I've taken the less than smart path a time or two. You set me straight more than once. It happens...

ProfessorManhattan

@johnpoz Without encrypted DNS, anyone on the network can listen for DNS requests and know exactly what everyone is looking at. Also, every network is potentially hostile IMO.

We are in the days of botnet hackers. I'm inclined to believe that there are advanced botnets around that are powered by sophisticated 0-day exploits (after all, some can rebuild a pre-existing hack and include it in their malware). IMO, the more bizarre security measures you have in place, the less likely the bot will be able to adjust to your system.

Anyway, I guess this feature exists in pfSense but I can not figure out how to get it working.

ProfessorManhattan

@JeGr Hey JeGr, I think this is the issue. Can you point me to a guide that shows how I can add a .crt to /etc/ssl/certs to make this work?

johnpoz

@ProfessorManhattan said in How to Use DNS Over TLS Server Option:

anyone on the network can listen for DNS requests and know exactly what everyone is looking at.

So you are using a HUB for you network.. Switches do not allow for just sniffing traffic between other ports on that switch.. So unless you are exploiting or admin that switch.. Sorry host C (hacker) can not see traffic that A (pc) sends to B (dns) via unicast.. Now sure he could see broadcast traffic.. So if your using say mdns to resolve what websites (nobody does - mdns is a local discovery form of dns) your going to - which sorry pfsense not going to response to mdns..

And even in wifi, you can not just sniff every clients traffic.. Because each client has their own unique key, while sure it is from the PMK, but the PTK Pairwise Transient Key is different for unicast traffic. If you want to make sure that can not happen then you use wpa2-enterprise where it would not be possible to get the specific PTK info..

But even when just use wpa2-psk, they would have to snag the specific handshake for that client to derive their PTK used when that client talking to the AP

PTK = PRF (PMK + Anonce + SNonce + Mac (AA)+ Mac (SA))

When you don't want that sort of thing to even be possible, then you just use wpa2-enterprise. Which is easy enough to setup using the radius package of pfsense.

So even when another client A is on the same wifi, your not going to see what user B is sending to the dns server..

Before you think its so freaking easy anyone can just click an app on their phone and see all the dns traffic happening on said network... I suggest you give it a try ;)

There is little reason to encrypt your dns traffic on your LAN.. Other than hey you want to slow shit down and make it harder to troubleshoot.. Or you just want to play with in your lab sort of thing.. But it has really zero use case where it would make any sense to actually do it.

Gertjan

@ProfessorManhattan said in How to Use DNS Over TLS Server Option:

the more bizarre security measures you have in place

I'll give you an easy one.
Block every incoming connection on your LAN, except : a list with well known VPN providers and the TCP/UDP ports they use.
This will enforce that client devices (PC's and the like) will really have to use the software proposed by the VPN provider they choose. Only with a VPN link to this VPN provider people can use your LAN : every LAN client is walled in, you not doing nothing (the close to perfect admin position) to achieve a certain level of security. Just put a note on your office door : the list with accepted VPN providers (and ask them a small fee while your at it ^^ )
The VPN connection URL should be IP based, not FQDN, so you can even block DNS traffic on your LAN.

Done.
Now, when botnets are fighting on your LAN for total control because they broke the 4096 bit VPN encryption( ;) ), the world outside has been already set back several centuries.

jimp

This new recipe doc I added this week should cover all the bases:

https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html

johnpoz

Still have the issue of putting the dns servers like that in the general setup, pfsense itself "can" use those and those connections will not be using tls.

So The SKY will fall in the and the black helicopters will surround you as you "leak" dns ;) when pfsense looks to see if there is an update available.

jimp

@johnpoz said in How to Use DNS Over TLS Server Option:

Still have the issue of putting the dns servers like that in the general setup, pfsense itself "can" use those and those connections will not be using tls.

I didn't see any existing issue on Redmine for that feature, so I added one:

https://redmine.pfsense.org/issues/10931

johnpoz

Sure it will make these tls users happy.. Because the sky would fall for sure if isp saw something doing a query in the clear for netgate.com something..

Much better to hand that over to cloudflare directly - which is more trustworthy ;) They would never in a million years think to monetize any user info...

A Former User

The ultimate solution to this issue is going to have to come from modernized privacy laws. That will only happen if we stop allowing telco's to do as they please. As it stands telco's ask the FCC if they may disregard the rules and Ajit Pai says sure. Look, surveillance capitalism is easy money, everyone wants their piece of the ~~Pai~~ pie.

DoT is the same as building a bank vault around your jar of pennies while the crooks are taking your gold bars out the back door.

But if you insist just do this:

Put localhost only in general settings dns servers.

Add this (cloudflare, change hosts to your own liking) to the DNS resolver custom settings:

server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853
forward-addr: 2606:4700:4700::1111@853
forward-addr: 2606:4700:4700::1001@853

Add whatever NAT rules you want to to catch naughty hosts as documented in the pfsense book.

Do a packet capture on WAN and you will only see traffic on port 853.

(pfblockerng has an option under reports alert settings tab: "Select the DNS server for the DNSBL Whitelist CNAME lookup" that may cause some port 53 traffic)