Could interface-automatic block pfSense Unbound Resolver from running proper DoH server?

ddoh94

Hi, I'm new to the forum, please forgive.

TLDR: I think that pfSense implementation of "interface-automatic: yes" option set in unbound.conf is unintentionally? blocking DoH, and can't be overridden by Custom Options. I have confirmed unbound user is not opening any ports configured for DoH with sockstat -l.

Any and all help will be much appreciated. I know I don't know, please let me know your ideas. Thank you :)

I'm trying to accomplish:

pfSense Unbound uses upstream DNS queries over TLS, check.
pfSense Unbound server is available over port 853 (or any port), check.
pfSense Unbound server is available over port 7272, error.
pfSense HAProxy translates TLS port 443 of pfSense to 7272, I got this.. but stuck on 3. Already works for the UI at 444.

Here is my question: How can I configure the pfSense version of Unbound to accept DoH (DNS over HTTPS) requests (not DoT/DNS over TLS)?
I've looked everywhere.. and been digging deep into the configuration options... I can't even find a log that mentions an error or even port 7272 at all.

I've tried many combinations of these settings, and many different ports, including 443:

server:
logfile: "/var/unbound/unbound.log" #uncomment to use logfile.
server:
https-port: 7272
interface: 0.0.0.0@7272
http-endpoint: "/dns-query"
tls-service-pem: "/var/unbound/sslcert.crt"
tls-service-key: "/var/unbound/sslcert.key"

johnpoz

@ddoh94 said in Could interface-automatic block pfSense Unbound Resolver from running proper DoH server?:

version of Unbound to accept DoH (DNS over HTTPS)

Pretty sure unbound requires nghttp2 to do doh, is that available in pfsense? I have never looked into it very deep because well not really of fan of either dot or doh.. Other than blocking it from my clients using it ;) I have zero use for either of them...

While they might have some use in some scenarios.. The way browsers are forcing use of doh on users that have no clue is not good.. And the way it can be leverage to circumvent local dns controls is again not good..

Other than a learning exercise I can really not see a scenario where I would want to use doh locally.. Who would be sniffing dns traffic on my local secure network?? Other than me??

ddoh94

@johnpoz

Thank you, I definitely see your point. Since Windows 11 and Server 2022 now have native DoH support (but not DoT), I want to setup the network to support DoH, as well as understand how Chromium based browsers are interacting with the Windows set DoH in contrast to the OS native .net apps. So far I can't test much because I don't have my own operating DoH server, making it so I can't see what Chrome and Windows really do with DoH.. I would rather do it in pfSense than in another DNS resolver solution.

If I can get this working, I'm happy to submit a pull request on the source.

I believe that 2.7.0-Release does have nghttp2 compiled in unbound.

unbound -V
Version 1.17.1

Configure line: --with-libexpat=/usr/local --with-ssl=/usr --enable-dnscrypt --disable-dnstap --with-libnghttp2 --with-dynlibmodule --enable-ecdsa --disable-event-api --enable-gost --with-libevent --with-pythonmodule=yes --with-pyunbound=yes ac_cv_path_SWIG=/usr/local/bin/swig LDFLAGS=-L/usr/local/lib --disable-subnet --disable-tfo-client --disable-tfo-server --with-pthreads --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/ --build=amd64-portbld-freebsd14.0
Linked libs: libevent 2.1.12-stable (it uses kqueue), OpenSSL 1.1.1t-freebsd 7 Feb 2023
Linked modules: dns64 python dynlib respip validator iterator
DNSCrypt feature available

BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues
[2.7.0-RELEASE]

johnpoz

@ddoh94 those are all good reasons to fire it up - as learning and testing..

I would think off the top of my head since the configure has -with-libnghttp2 that it might be possible..

I can tell you it works with dot, with just picking the cert.. And enable listen..

root@NewUC:/tmp# kdig @192.168.2.253@853 nas.home.arpa +tls
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 46838
;; Flags: qr aa rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
;; PADDING: 406 B

;; QUESTION SECTION:
;; nas.home.arpa.               IN      A

;; ANSWER SECTION:
nas.home.arpa.          3600    IN      A       192.168.9.10

;; Received 468 B
;; Time 2023-10-20 11:14:02 CDT
;; From 192.168.2.253@853(TCP) in 43.6 ms

You might be able to get it to do doh as well with just options in the custom box.. Hmmm got me curious - prob take a look see if just have to call out the crt and key in custom option box..

ddoh94

@johnpoz

I appreciate it. I definitely do have some true production use cases I'd like to explore also, but the first step as I mentioned is to get DoH working at all.

Some use cases I can think of:

Helium miner on LoRAWAN as a study case, and any other 'public' network offered by the public. Possibly xfinitywifi or Boingo WiFi Passpoints could be another variation of this. As a consumer of the end network, I don't want a man in the middle to see any dns queries. As an operator of the end network, I don't want to see what people are running through the LoRAWAN network. I am interested in the concept of the Helium LTE/5g product, which has tremendously higher network throughput requirements than the LoRAWAN predecessor.
Active Directory - More interested in getting ECH working and mutual certificate based authentication, and DoH is possibly a part of that. Protect the identity of your server, so to speak (A Domain Controller is priceless in AD world).
Starlink - or any CGNAT WAN
IPv6 - I try to consider build all networks as though each client is a possible threat actor, even if it's technically inside your private LAN OR actually on the public internet. IPv6 makes this much more relevant in my mind.
If your VPN ingress is on a dynamic public IP, and you're forced (or choose) to use a dynamic DNS entry to locate your VPN tunnel remote endpoint as opposed to static public IPs. I believe the public DNS query of this sensitive endpoint is better made using DoH.

johnpoz

@ddoh94 ok this seemed easy enough. I exported a cert and key from pfsense cert manager.. And put them in the /var/unbound dir, called them doh.crt and doh.key just so I would not forget what I put them there for ;)

Then I set one of the interfaces to listen on 443 setup the crt and key to be used

Now doh sure seems to work via my simple test

Here is tls working.. And then under I did a doh query. Also working.

You prob want to put a feature request for this.. While I am not a fan of dot or doh, I don't think either of them are going away any time soon. So since unbound is capable of doing it.. Might as well expose the ability to turn it on in the gui I guess.

I would want to test with the doh client validating the cert, etc. Which my simple test isn't doing.. But some other client might and should really. So you could run into a problem where the cert not signed by a CA that the client trusts..

edit: looks like a feature request was already put in

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

johnpoz

@ddoh94 some more fun stuff just fired up a few minutes ago.. Again not really a fan of dot or doh, etc. But if your going to play with it - for me its just learning experience, etc.

Since I had setup unbound to do doh the other day.. If finally dawned on me - oh, firefox has some restriction that you can not enable ech unless your using doh.. But hey I have a local doh server now I can point it too ;)

So just to test if I could get firefox using ech, even though I am just resolving via normal dns the https A record it has to pull.

So I pointed firefox to my local doh.home.arpa that created cert for and firefox trusts the CA.,

And what do you know -- its now using ech if the site your going to supports ech and answers the https RR query.

I will turn it back off - not suggesting anyone do this, but using ech is the logical conclusion to encrypted dns - because its kind of pointless if try and encrypt your dns, if your just going to send the sni in the clear anyway.

My setup where I just resolve in the clear, in not a very valid setup - since if you were actually trying to hide your dns query, and you wanted to encrypt your sni.. Since I resolve in the clear, the query for the https RR would still be in the clear, and with that you could figure out where I am going even with the sni encrypted.

I just wanted to see if firefox would actually do ech if the doh requirement was met from the browsers point of view

Simple set of TRR in firefox back to 5 and no longer doing the ech

JonathanLee

https://forum.netgate.com/topic/181338/feature-request-gui-options-to-unbound-resolver-s-new-doh-abilities

Please also check this out. . .

Sergei_Shablovsky

@johnpoz said in Could interface-automatic block pfSense Unbound Resolver from running proper DoH server?:

@ddoh94 said in Could interface-automatic block pfSense Unbound Resolver from running proper DoH server?:

version of Unbound to accept DoH (DNS over HTTPS)

Pretty sure unbound requires nghttp2 to do doh, is that available in pfsense? I have never looked into it very deep because well not really of fan of either dot or doh.. Other than blocking it from my clients using it ;) I have zero use for either of them...

Sorry, I’m little bit shocked about You: with a so lot of knowledge, ignoring the fact that DoH/DoL become standard (because incredibly rapidly growing numbers of DNS-related attacks in both on private business/industrial and government level) - that’s looks like no having “bird view” what happened in communication world. Am I wrong ?
Take my apologies again, I appreciate You in general.

While they might have some use in some scenarios.. The way browsers are forcing use of doh on users that have no clue is not good.. And the way it can be leverage to circumvent local dns controls is again not good..

But IN EVERYDAY’S REALITY most browsers (Safari, Chrome, Firefox) extensively using DoT/DoH.
So this is reality (also like TTL of DNS records decreasing year by year) in which we may live.

Other than a learning exercise I can really not see a scenario where I would want to use doh locally.. Who would be sniffing dns traffic on my local secure network?? Other than me??

For example: any black hacker, that compromise one node and obtain access to one of pfSense’s internal LANs. And this is not only about CARP.