[SOLVED] DNS Requests From Clients Failing

[lawrencedol]

I get:

nslookup
Default Server:  pfsense.lan
Address:  10.70.80.1

But I'd expect OpenDNS to show as the final server, since that's what I've configured.

I did not edit the LAN rules.

[Derelict]

The default configuration is a DNS Resolver.

The DNS resolver does not use configured name servers to resolve client requests. It starts at the root name servers and works down hierarchically until it obtains the answers from the authoritative name servers for that zone/domain.

If you want to leverage OpenDNS, Quad9, etc, you must use either the DNS Forwarder or the DNS Resolver in forwarding mode so all answers are obtained from those specific servers.

There are three different things to keep in mind:

• What servers the clients are configured to use as DNS servers (The configuration of the client itself - often via DHCP)

• What servers the firewall itself uses as DNS servers (The settings in System > General)

• Where/how the DNS server software on pfSense is configured to obtain answers to client queries. (The choice between the DNS Forwarder or DNS Resolver and the configuration of the same)

[KOM]

Actually, I wanted you to manually use pfSense as your DNS server for this test by issuing the command:

server (pfSense hostname or IP)

Then you would try to resolve google.com or whatever and see what you get on your client.

[lawrencedol]

KOM,

Sorry about that. I'd not used nslookup before.

Despite the fact the ipconfig /all reports the correct local IP address of the pfSense box for the DNS server, I had to set the server to the IP address, from the default DNS name. That resulted in the following (successful) queries:

nslookup
Default Server:  pfsense.lan
Address:  10.70.80.1

> google.com
Server:  pfsense.lan
Address:  10.70.80.1

> server 10.80.80.1
Default Server:  [10.80.80.1]
Address:  10.80.80.1

> google.com
Server:  [10.80.80.1]
Address:  10.80.80.1

Non-authoritative answer:
Name:    google.com
Addresses:  2607:f8b0:400a:806::200e
          216.58.216.142

> exit

Derelict,

I have the resolver configured for forwarding mode (Enable Forwarding Mode), now, but still with no success. (Screenshot attached.)


[lawrencedol]

I just noticed the typo in my IP address… 10.80 instead of 10.70... I wonder why that worked, since I don't have a 10.80 network?

It seems that the problem is having the DNS IP set to 10.70.80.1 (the LAN address of the pfSense box). If I set it to something unknown lookups work??

nslookup
Default Server:  pfsense.lan
Address:  10.70.80.1

> google.com
Server:  pfsense.lan
Address:  10.70.80.1

*** pfsense.lan can't find google.com: Server failed
> server 10.70.80.1
Default Server:  pfsense.lan
Address:  10.70.80.1

> google.com
Server:  pfsense.lan
Address:  10.70.80.1

*** pfsense.lan can't find google.com: Server failed
> server 10.1.2.3
Default Server:  [10.1.2.3]
Address:  10.1.2.3

> google.com
Server:  [10.1.2.3]
Address:  10.1.2.3

Non-authoritative answer:
Name:    google.com
Addresses:  2607:f8b0:400a:806::200e
          216.58.216.142

> exit

Wuhuh?

[KOM]

You're getting nothing back when you do a manual lookup?  It should come back with either a resolution or an error.  Here is how it should work (from my location):

PS C:\Users\kom> nslookup
Default Server:  ad.kom.local
Address:  10.10.0.1

server pfsense.kom.local
Default Server:  pfsense.kom.local
Address:  10.10.4.1

www.google.com
Server:  pfsense.kom.local
Address:  10.10.4.1

Non-authoritative answer:
Name:    www.google.com
Addresses:  2607:f8b0:400b:808::2004
          172.217.0.228

[lawrencedol]

Yes, successful lookup is what my output, above, shows… but only afer I change the server to an invalid IP address, like 10.1.2.3. As long as the server is the name or IP address of the pfSense box (10.70.80.1) the lookup fails (which the above output also shows, first).

[KOM]

Sorry, I'm a dummy.  I didn't notice the scroll bars in your output and thought that was all.

It certainly shouldn't be resolving when you supply a bogus DNS.  I'm starting to get suspicious about your extra router in the mix.

What do you have under System - General - DNS Server Settings?

[lawrencedol]

General DNS settings attached.


[Derelict]

First off, OpenDNS does not properly support DNSSEC (last I heard) so uncheck that in the resolver.

Second, you should be getting some kind of response. Are you POSITIVE you didn't dork with the firewall rules on that inside interface such that DNS is now blocked?

Or the listen interfaces?

[lawrencedol]

Derelict,

It was IPSEC doing it! If I turn that off and apply, then I can ping; if I turn it back on, apply and flush DNS on the client then it fails; turning it back off allows the client to work again.

Thank you!

PS: The only firewall rules I have are those created automatically on the LAN interfaces.

[Derelict]

DNSSEC or IPsec?

And don't confuse "ping" with "resolve names".

You could probably always ping the correct IP address. You just couldn't resolve the correct IP address from the name.

[Gertjan]

@Lawrence:

It was IPSEC doing it! If I turn that off and apply, then I can ping; if I turn it back on, apply and flush DNS on the client then it fails; turning it back off allows the client to work again.

IPSEC ? Or DNSSEC ?

The pfSense Resolvers uses DNSSEC by default - some sort of future secured DNS - and, you should know that OpenDNS doesn't work with DNSSEC.
When you flush the DNS on your client, you didn't flush the DNS cache on pfSense, so it still seems to work. But as soon as the cache times out, things will be 'broken' again.
Rule of thumb : when using OpenDNS, disable your local (pfSense) resolver the DNSSEC capabilities - or use the forwarder, this is one of the reasons it still exists in pfSense : for those who want to send all their DNS traffic to some off-site DNS service like OpenDNS.

[lawrencedol]

All,

Sorry, I did mean DNSSEC.

I do know that I was flushing the client cache, but since it was only the client which was failing to resolve DNS names (resolving from the pfSense box has been working since inception) and since pinging with a host name requires a DNS resolution first, that seems a valid test to me. Specifically what I did was ping google.com => fail. Disable DNSSEC, then ping google.com => success. Enable DNSSEC again, then ping google.com => success (address still cached on client). Then ipconfig /flushdns and ping google.com => fail (expected). Finally, disable DNSSEC then ping google.com => success again. Which demonstrates conclusively that DNSSEC is causing an issue with the client (given that there was no problem resolving names from the pfSense diagnostic tool). Of course, my initial and subsequent posts did make clear that I could ping and access hosts by their IP address the whole time.

[This train of logic actually suggests that it is the client (Windows 10) not OpenDNS which can't do DNSSEC, since with DNSSEC enabled resolving names from the pfSense box works. But that is an aside for me right now since the problem is resolved.]

Again, thanks for your help.

PS: Is there a way to mark this thread as resolved?

[johnpoz]

"This train of logic actually suggests that it is the client (Windows 10) not OpenDNS which can't do DNSSEC"

Sorry but that is not what that train of non logic suggests at all…  Suggest you research how dnssec works, and why asking opendns for dnssec is not going to work..  But why it does work when you acktually resolve, etc.