Buggy DNS behavior
-
@viragomann
The hostname for DoT is optional, but I included it in the initial post. Also SSL/TLS was already included, but I also edited this part to make sure it's better explained. -
I guess this is expected behavior after all.
In principle the DNS settings are configured for clients connecting to pfSense and for this the behavior is what it should be.DNS over :53 can still occur (unless the workaround is used), but these are only requests from pfSense and not from clients.
It's just a bit confusing IMO and I can imagine situations where you really want all DNS requests following the same path.
Feel free to comment if you have anything to add!
-
@hardware_bxl
I have the setting I mentioned above on a 2.6 it does only DoT requests at port 853.I haven't any custom settings in the Resolver though regarding this. This is not needed if you want to forward requests to the DNS servers in General setup.
-
@viragomann Follow what I said carefully, because you should see :53 over WAN when doing DNS Lookup on pfSense, or when changing settings on pfSense like the mentioned timeserver hostname - packet capture on WAN with filter :53 and you should see them.
-
@hardware_bxl
Ah yeah, pfSense itself doesn't obey this. That's correct.
But the option "Use Local DNS (127.0.0.1), ignore remote DNS Servers" set, as you mentioned above, it should use the Resolver only. -
About the 'time' : the resolver might need, if you are going to use DNSSEC, the exact correct time, otherwise the SEC part of DNSSEC will fail. When the time process 'ntp' starts, local resolving (unbound) didn't started yet. So, probably ntp uses it's own build in DNS logic (if needed).
See the pfSense boot log on the console.Forwarding over TLS does also use TLS (certificates !) so the issue is the same : a good time is needed before unbound starts.
So, initial (right after boot) ntp can / will use direct control for DNS as no DNS entity exist yet on the system at that moment.
Later on, ntp should (I guess) default to 'use 127.0.0.1' = the local DNS resolver (that will forward in this case).If you are forwarding, DNSSEC should be disabled as DNSSEC only makes sense when you resolve.
Another possible issue : unbound DNSSEC rootkey bootstrapping.
When unbound starts, it loads the current 'master DNSSEC key', the one that is used to sign everything else. IMHO : I wouldn't be surprises if unbound wanted to get this info directly from the source, and not from sort of intermediate source, using forwarding.@hardware_bxl said in Buggy DNS behavior:
The hostname for DoT is optional
I'll share my thoughts :
When you do TLS, you have to use a host name.
The host name has to be resolved so an IP is obtained.
The IP is contacted, TLS is started, certificates come in, and these certificates should be valid and contain the host name of the contacted service. if these checks are valid, the connection is valid.
That's the way 'https web browing' works : try to contact a this forum using it's IPv4 or IPv6 : https://208.123.73.199/ : your browser will bark.So, when I had to use forwarding :
I would enter "1.1.1.1" and the correct host name : "one.one.one.one" because :
[23.05.1-RELEASE][root@pfSense.bhf.net]/root: host 1.1.1.1 1.1.1.1.in-addr.arpa domain name pointer one.one.one.one.It might be so that this relation between IP and host name is not enforced by unbound (I'm not sure, as I've people entering nothing or just pure comments in the host name field) when doing DNS over TLS : I find that pretty flawed, as when 1.1.1.1 gets spoof routed' to not the real 1.1.1.1 then ..... bye bye security ...
I do agree with subjetc of this thread : I would though that pfSense local processes that 'go outside' like checking for package updates, the abc backup, bogon list monthly update and some others) should use unbound over the local connection : that's 127.0.0.1 and these requests should be forwarded over the selected 'TLS' method, not plain '53'.
When you see outgoing traffic over '53' (packet capture WAN outgoing), does this match to traffic coming in on 127.0.0.1 port 53 ?
If so, strange indeed. -
@Gertjan
I suspect it will not match the incoming 127.0.0.1:53 traffic, but I will check that to be sure."Later on, ntp should (I guess) default to 'use 127.0.0.1' = the local DNS resolver (that will forward in this case)."
In my simple test setup as explained, single lan and wan, just the dns resolver configured, forwarding, tls, and set dns servers in general setup ->
then just capture :53 on wan, change the timeserver hostname, like 1.ntp to 2.ntp for example and you will see :53 dns going out.
(or from pfSense do a DNS Lookup to any hostname and the same happens).can anyone check this, so at least i know i am not doing anything wrong here?
-
@hardware_bxl said in Buggy DNS behavior:
can anyone check this, so at least i know i am not doing anything wrong here?
can't check for you. I've 'something' against forwarding my DNS to external entities (I'm probably thin foiled hatted, I know) but I know what this page does :
If you have not set this
(if you set that, then also upstream router or ISP DNS becomes part of your local list with DNSs to use , competing with 127.0.0.1, which is the access point to unbound)
then the GUI DNS Lookup does this :
$query_time = exec("/usr/bin/drill " . escapeshellarg($host) . " " . escapeshellarg("@" . trim($dns_server)) . " | /usr/bin/grep Query | /usr/bin/cut -d':' -f2");Let's clean that up.
drill $host @127.0.01$dns_server is the one we're looking for and only 127.0.0.1 on port 53 : so it talks to unbound.
( $host is host name where looking for - the rest is output formatting for the GUI)So, for me, its using 127.0.0.1 == unbound.
What you saw :
Were you using 127.0.0.1 or some of these :
(if you've checked that option)Or, traffic request on 127.0.0.1 don't use the forward+TLS path ? but go out using destination 53, the good old classic way ?
-
@Gertjan
It gets even weirder, because it goes through the Resolver (127.0.0.1) indeed, but something else happens:Single LAN, single WAN, Resolver forwarding over TLS, Cloudflare dns servers
When you do Diagnostics - DNS Lookup - Hostname: ibm.com
Result:
The DNS request is dropped @ 127.0.0.1 (Resolver) and is indeed forwarded to 1.1.1.1:853 etc.
BUT it also creates a DNS request 1.1.1.1:53 (!) and the hostname ibm.com is also resolved over port 53.HOWEVER: DNS Lookup does NOT get any result back from these regular DNS requests, it will simply fail if you change the Cloudflare IPs to something not reachable.
I'm getting really confused now and wondering if for whatever reason it's my setup, but I do nothing, because I install pfSense and do the only config I mentioned before, nothing more. I hope someone can say me...
-
@hardware_bxl said in Buggy DNS behavior:
When you do Diagnostics - DNS Lookup - Hostname: ibm.com
Because that is going to talk to all servers listed in dns.. When loopback 127.0.0.1 is asked, then it will forward. When it asks say 8.8.8.8 that is listed in there or 1.1.1.1 listed in there it would just be over normal dns..
What do you have this set too?
There is a big difference in the diagnostic gui dns lookup, and a client only asking unbound.. If you want to test what unbound does, then ask unbound via a client
-
@johnpoz said in Buggy DNS behavior:
There is a big difference in the diagnostic gui dns lookup, and a client only asking unbound..
Yes I agree and that is why I already earlier wrote that it seems like expected behavior, but even so, it keeps surprising me
DNS Resolution Behavior is set to what you show:
Use Local DNS (127.0.0.1), ignore remote DNS Servers.Forcing the use of the Resolver that is configured for DoT.
I would personally use the dns lookup in diagnostic to also check my dns setup in general (packet capture, see if there are leaks or issues).
It's just strange to see the unexpected regular dns packets and even more because the diagnostic tool is most likely generating them, but not even using them for dns (as told in my previous post).
The packets show the DNS request for what was entered.Anyway, I will focus on clients connecting to unbound for now and make sure everything there is as expected, for whatever reason this is a choice pfSense made and is just confusing me (but I also might be easily confused).
