DNS functionality in default Resolver Mode
-
I have read that Unbound when in Resolver Mode queries the Root Servers directly and I believe this is a good thing for sure. Not giving all the DNS lookup data to a particular DNS provider and preventing the centralization of internet services.
What I don’t understand is that when the firewall is set to stock standard vanilla default settings for Resolver Mode, I still get the ISP’s DNS server address showing up in places like dnsleaktest.com and ipleak.net and so forth?
It seems that under the bonnet pfsense retains the DNS server settings it obtains from the DHCP allocation from the ISP and these still register. How do I know that ALL the DNS lookups are going to the root servers and not to the ISP supplied servers?
-
@argonaut if your going to use resolver mode, you can turn off letting dhcp set those in pfsense.
You can also adjust the behavior to never use remote servers.
You sure your client does not have them set? Those sorts of tests are always run from the client, and not pfsense. How would your run a test from pfsense even?
Your clients should only have pfsense IP as their ONLY dns set.
-
@johnpoz Thanks JP for your reply :)
Yes, I have pfsense set exactly as you have shown above...
There is no tick in the checkbox and the DNS Resolution Behavior is set to "Use local DNS, ignore remote DNS Servers"And I have the nic in the client (windows machine) set to static and only receive dns from the firewall.
Yes those tests are run from the client as you say - which makes it all the more puzzling...
-
@argonaut could you post up what site your using and the results.. You sure its reporting isp dns?
For example running the extended test only shows my public IP, which is how it should be when resolving. But it does list my ISP because yes my public IP is owned by my isp ;)
How these test work, is they tell the client hey look up some specific fqdn, that the authoritative ns is managed by the testing site. So they can see what IPs actually query for this specific fqdn they told the client to look for.
When you resolve this will always be your public IP that pfsense uses to do the queries with. If you forward, this could be all kinds of IPs - and will be the IPs of the resolver used by where you forwarded too.. This does not always and quite often does not equal the IP you might be forwarding too. It will end up being the IP of the resolver that actually had to resolve this unique fqdn your client was looking for during the test.
If your seeing some other IP other than the public one pfsense uses to do the queries, its possible your client is asking something your not aware of - doh perhaps? Or it could also be a sign that your isp is doing interception of your queries..
But quite often concern comes from misinterpretation of the results presented. If you could post up your results - sure hide your public IP if it is listed, like I did above in mine.
-
Oh OK I see. I was barking up the wrong tree ;)
I thought the test should return a sample of the root servers being queried...
Thank-you JP for solving the mystery.
All kudos to you!
-
@argonaut no problem - that other test site, isn't even working.. I get this for my dns test ;)
No with how the "test" works you would never see the roots, because the roots are never going to do a query for the unique fqdn your client is seeking out.
When you resolve the resolver only asks the roots for the authoritative servers for .tld, then it asks one of those NS for whatever .tld for NS for domain.tld
Then your resolver will directly ask one of the authoritative NS for domain.tld for uniquesomething.domain.tld
Now the testing site can look and see what IP actually asked for uniquesomething.domain.tld
When you resolve this will be the IP pfsense used to make the query to the authoritative NS for the domain that uniquehost..
And also once unbound has cached the NS for domain.tld, and you look up somethingelse.domain.tld it doesn't have to walk down the tree from . anymore.. It knows who the authoritative NS for domain.tld are - and will just directly ask one of them for somethingelse.domain.tld
edit:
btw - if you want a great way to see how resolving works.. On your pfsense do a dig something.whatever.com +trace +nodnssecI just remove the dnssec queries for this example so it makes for cleaner output..
[21.05.2-RELEASE][admin@sg4860.local.lan]/: dig www.netgate.com +trace +nodnssec ; <<>> DiG 9.16.16 <<>> www.netgate.com +trace +nodnssec ;; global options: +cmd . 45110 IN NS b.root-servers.net. . 45110 IN NS m.root-servers.net. . 45110 IN NS f.root-servers.net. . 45110 IN NS j.root-servers.net. . 45110 IN NS g.root-servers.net. . 45110 IN NS a.root-servers.net. . 45110 IN NS c.root-servers.net. . 45110 IN NS l.root-servers.net. . 45110 IN NS e.root-servers.net. . 45110 IN NS h.root-servers.net. . 45110 IN NS i.root-servers.net. . 45110 IN NS d.root-servers.net. . 45110 IN NS k.root-servers.net. ;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. ;; Received 840 bytes from 193.0.14.129#53(k.root-servers.net) in 47 ms netgate.com. 172800 IN NS ns1.netgate.com. netgate.com. 172800 IN NS ns2.netgate.com. ;; Received 140 bytes from 2001:503:83eb::30#53(c.gtld-servers.net) in 28 ms www.netgate.com. 60 IN CNAME 1826203.group3.sites.hubspot.net. ;; Received 118 bytes from 208.123.73.80#53(ns1.netgate.com) in 37 ms [21.05.2-RELEASE][admin@sg4860.local.lan]/: -
@johnpoz That's great JP.
Yes the dig command certainly returns a good visual of what's going on under the bonnet :)
I will never look at DNS requests the same way again!
And I am sold on the concept of having pfsense in Resolver Mode rather than Forwarding Mode...
