Fun with Google DNS 8.8.8.8 & 8.8.4.4

lohphat

@tman222 OoooOOooooh!

I shall try this (didn't know there was this feature). Thanks!

I wonder if DNS over TLS would work too or are these IoT devices looking for actual destination authentication or just want encryption.

I see that question is addressed in the Caveats section at the bottom of the page.

lohphat

@tman222 I seem to have it working but the help pages indicate that the DNS port forward should go to localhost (127.0.0.1) -- but that didn't work.

unbound is set to be listening on all interfaces so it should work.

To get it working, I needed to put the gateway address for each segment in its place, THEN it started working.

I put a temp rule after the rule to log any errant packets to any other address and there were none.

So yes it's working, but now I have to figure out why localhost didn't work in the rule.

Gertjan

@lohphat said in Fun with Google DNS 8.8.8.8 & 8.8.4.4:

I seem to have it working but the help pages indicate that the DNS port forward should go to localhost (127.0.0.1) -- but that didn't work.
unbound is set to be listening on all interfaces so it should work.

Well, it does, or doesn't ?
Ask :

sockstat | grep 'unbound'

and yes :

All means all :

and that includes "127.0.0.1" or Localhost.

lohphat

@gertjan

It's there but why is it running on a different port? (953)

[22.05-RELEASE][root@pfSense.localdomain]/root: sockstat | grep 'unbound'
unbound  unbound    49409 3  udp4   *:53                  *:*
unbound  unbound    49409 4  tcp4   *:53                  *:*
unbound  unbound    49409 5  udp4   *:853                 *:*
unbound  unbound    49409 6  tcp4   *:853                 *:*
unbound  unbound    49409 7  udp6   *:53                  *:*
unbound  unbound    49409 8  tcp6   *:53                  *:*
unbound  unbound    49409 9  stream /var/run/php-fpm.socket
unbound  unbound    49409 10 stream /var/run/php-fpm.socket
unbound  unbound    49409 11 udp6   *:853                 *:*
unbound  unbound    49409 14 tcp6   *:853                 *:*
unbound  unbound    49409 15 tcp4   127.0.0.1:953         *:*
unbound  unbound    49409 16 dgram  -> /var/run/logpriv
unbound  unbound    49409 18 stream -> ??
unbound  unbound    49409 19 stream -> ??
unbound  unbound    49409 20 stream -> ??
unbound  unbound    49409 21 stream -> ??

...

lohphat

@gertjan

I seem to have found it. It seems that by enabling SSL/TLS breaks it. When I disabled it localhost DNS responses started working.

So I have a choice: disable local DNS over TLS for localhost routing to work or enable it and specify the specific .1 address for each network segment in the NAT rules.

Enable SSL/TLS Service
Respond to incoming SSL/TLS queries from local clients Configures the DNS Resolver to act as a DNS over SSL/TLS server which can answer queries from clients which also support DNS over TLS. Activating this option disables automatic interface response routing behavior, thus it works best with specific interface bindings.

Gertjan

Why port 953 ?
Because you => the admin => see the file /var/unbound/remotecontrol.conf ( included by /var/unbound/unbound.conf ) asked it to do so.
@lohphat said in Fun with Google DNS 8.8.8.8 & 8.8.4.4:

unbound unbound 49409 15 tcp4 127.0.0.1:953 :

953 is only used on interface 127.0.0.1.

Port 953 is the control port. Used by unbound-control to control unbound during execution.

This :

...
unbound  unbound    49409 3  udp4   *:53                  *:*
unbound  unbound    49409 4  tcp4   *:53                  *:*
...
unbound  unbound    49409 7  udp6   *:53                  *:*
unbound  unbound    49409 8  tcp6   *:53                  *:*
...

means : unbound on all interfaces using port 53, protocol TCP and UDP
For IPv4 and IPv6

The * is like a wildcard : all interfaces.

unbound  unbound    49409 5  udp4   *:853                 *:*
unbound  unbound    49409 6  tcp4   *:853                 *:*

unbound port 853, TCP and UDP only for IPv4.

edit :
test your 127.0.0.1 :

dig @127.0.0.1 google.com +short

lohphat

@gertjan

The dig test always works on the console but not on the network segments unless I either disable DNS over TLS in unbound and use localhost -- or keep it on and use the segment's f/w .1 address.

Gertjan

@lohphat said in Fun with Google DNS 8.8.8.8 & 8.8.4.4:

but not on the network segments

You mean a PC on your LAN ?

C:\Users\gwkro>nslookup
Serveur par dÚfaut :   pfSense.mynetwork.net
Address:  192.168.1.1

> www.google.com
Serveur :   pfSense.mynetwork.net
Address:  192.168.1.1

Réponse ne faisant pas autorité :
Nom :    www.google.com
Addresses:  2a00:dead:beef:801::2004
          142.250.75.4

I have DNS over TLS (port 853) activated, but I don't know who uses it.
I've no need to hide local DNS traffic (from LAN devices to pfSense) on my own cables.

My unbound listens on every interface, like 192.168.1.1, 192.168.2.1 192.168.3.1 etc.

lohphat

@gertjan said in Fun with Google DNS 8.8.8.8 & 8.8.4.4:

@lohphat said in Fun with Google DNS 8.8.8.8 & 8.8.4.4:

but not on the network segments

You mean a PC on your LAN ?

Yes.

Port Forwarding to localhost only works if DNS over TLS is disabled, otherwise I have to specify the .1 gateway on each segment. I confirmed this with testing.

While DNS over TLS is enabled then the port forward rule doesn't work to localhost. If I disable DNS over TLS it works on localhost.

There's a warning in pfsense warning me of this:

Enable SSL/TLS Service
Respond to incoming SSL/TLS queries from local clients Configures the DNS Resolver to act as a DNS over SSL/TLS server which can answer queries from clients which also support DNS over TLS. Activating this option disables automatic interface response routing behavior, thus it works best with specific interface bindings.

So I've elected to disable DNS over TLS in the resolver and block its use on each segment as I don't want clients to bypass pfBlocker on the gateway. I have a f/w drop rule to log any attempts just to see if any device is trying. I'm mostly curious of this behavior on my isolated IoT segment. I'll keep checking to see if any device is even trying.

If I want to enable DNS over TLS in unbound, then I need to change the DNS Port Forward rules to redirect to the .1 gateway. I've tested this as well. client lookup stops as soon as I activate this rule until I change the redirect to address to the .1 instead of the loopback.

This seems to be a "feature"

Gertjan

@lohphat said in Fun with Google DNS 8.8.8.8 & 8.8.4.4:

Respond to incoming SSL/TLS queries from local clients Configures the DNS Resolver to act as a DNS over SSL/TLS server which can answer queries from clients which also support DNS over TLS. Activating this option disables automatic interface response routing behavior, thus it works best with specific interface bindings.

I'm still wondering what that actuyally means.

I've tested my "port 853" from one of my LAN PCs (Windows 10) : DNS over TLS to pfSense (unbound) works.
I used a program like YogaDNS to enable "DNS over TLS port 853" to add such a DNS access for Windows 10. Windows 11 will have it natively supported I guess.

lohphat

@gertjan
Yeah. I can't explain it other than what I can replicate.

Localhost just stops working for me when DNS over TLS is enabled in unbound.

Gertjan

@lohphat

@lohphat said in Fun with Google DNS 8.8.8.8 & 8.8.4.4:

Localhost just stops working for me when

You mean unbound stops listening on 127.0.0.1 ?

@lohphat said in Fun with Google DNS 8.8.8.8 & 8.8.4.4:

when DNS over TLS is enabled in unbound.

Not a great loss as .... who uses this functionality ?

Btw : "Fun with 8.8.8.8 & 8.8.4.4" : are you sure ?
Why do you think you have use their services ? Why would you give them your DNS requests ? ) What about plain vanilla resolving, as pfSense, the resolver is meant to be used ?!
Nice side effect : DNS over TLS over port 853 locally will work - because it does so for me, using 22.05.

lohphat

@gertjan said in Fun with Google DNS 8.8.8.8 & 8.8.4.4:

Btw : "Fun with 8.8.8.8 & 8.8.4.4" : are you sure ?
Why do you think you have use their services ? Why would you give them your DNS requests ? ) What about plain vanilla resolving, as pfSense, the resolver is meant to be used ?!

Because I have clients who use Google/Nest products and they're hardwired to use 8.8.8.8 and 8.8.4.4 for DNS regardless of what DHCP returns. I have to deal with it.

lohphat

@gertjan said in Fun with Google DNS 8.8.8.8 & 8.8.4.4:

Localhost just stops working for me when

You mean unbound stops listening on 127.0.0.1 ?

Yes. That's why I have to use the .1 address of the network segment instead.

Gertjan

@lohphat said in Fun with Google DNS 8.8.8.8 & 8.8.4.4:

to use 8.8.8.8 and 8.8.4.4 for DNS regardless of what DHCP returns. I have to deal with it.

On the end user side, the pHone, PC, doorbell, printer or whatever : nothing to change.
Leave all settings to the default, which is neraly always 'DHCP'.

pfSense, the DHCP server :

and done.
All clients will receive 8.8.8.8 and 8.8.4.4 as their upstream reslover.

Or : don't add these 8.8.8.8 - 8.8.4.4 - leave the DHCP server with default values.
Switch unbound to 'forwarding mode' : have it forward to 8.8.8.8 - 8.8.4.4.

lohphat

@gertjan But I don't want them to have access to them because I'm running pfBlocker, thus the redirects to .1