[SOLVED] DNS Requests From Clients Failing

[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.