[SOLVED] Weird DNS Problem

  • This is a test environment with a fresh installation of pfsense 2.4.4, minimal configuration changes from the defaults, DNS Resolver works. The only firewall rules other than the defaults allow all traffic from LAN to WAN and DNS from LAN to pfsense and from pfsense to its forwarders only. Clients on the test.local LAN run Windows 7, Windows 10, Linux Mint 19, and iOS12.1, including an iPad and an iPhone. Some of the clients are configured with static IPs and gateways, some use DHCP, but all use only the pfsense machine for DNS resolution.

    All of the clients can access most domains. However, DNS for some domains resolves when using Diagnostics/DNS Lookup on pfsense, but the resolution doesn't pass through to any of the clients. For instance, robgillen.com resolves to an IP address using DNS lookup in pfsense, but none of the clients receive that address. For example, on Windows 10, I run this from the command line:

    nslookup robgillen.com
    Server:  pfSense.test.local
    DNS request timed out.
        timeout was 2 seconds.
    *** Request to pfSense.test.local timed-out

    But if I specify the same external DNS server that pfsense uses, it resolves on that same client:

    nslookup robgillen.com
    Server:  one.one.one.one
    Non-authoritative answer:
    Name:    argodev.github.io
    Aliases:  robgillen.com

    On the other hand, this works just fine when using pfsense's DNS Resolover:

    nslookup www.google.com
    Server:  pfSense.eis.local
    Non-authoritative answer:
    Name:    www.google.com
    Addresses:  2607:f8b0:400f:805::2004

    If I change the clients' configurations to use external DNS servers, there are no problems, but if they use pfsense for DNS, that domain does not resolve.

    This happens on all of the clients, regardless of operating system or configuration. As I said, most domains resolve without problems, but a few don't, even though pfsense can resolve the IP addresses for those domains in DNS lookup. Disabling the firewall doesn't fix the problem.

    I'm baffled. This is the simplest and cleanest configuration I can imagine for pfsense and the test network. I'll appreciate any suggestions that anyone can offer.

    UPDATE and Solution: I think that I misunderstandd how DNS forwarding works on pfsense. It appears to work differently than it does on Windows servers. Our lab has a direct connection to the internet, and I'd configured pfsense to forward DNS resolution requests for external domains to Cloudflare's DNS servers by checking "Enable Forwarding Mode" under Services/DNS Resolver/General Settings. Removing that check mark does not stop requests from being forwarded to the DNS servers configured under Settings/General Setup, and the few sites that I was having problems with now resolve. Nevertheless, even though the problem is solved, I'd like to know what is different about those domains that was causing the problem. Maybe one day I'll have the time to research it.

  • Netgate Administrator

    Did you have DNSSec enabled?

    In resolving mode Unbound talks directly to the DNS root servers which reliably support DNSSec. If you put it into forwarding mode it's usually better to disable DNSSec as it's likely something in the chain of forwarded servers will not support DNSSec and will be ignored. Since that can be different for different sites that could explain what you were seeing.


  • Rebel Alliance Global Moderator

    @eveningstarnm said in [SOLVED] Weird DNS Problem:

    from LAN to WAN

    That his not default the default is lan to ANY... There is a HUGE difference... Wan is not the internet - its just the wan network.. Users that set such a rule will break any sort of internet access...

  • Netgate Administrator

    A "DNS from LAN to pfsense" rule should allow that though.


  • @stephenw10 Yes, I thought that, too, and I tried it, but it didn't work. In fact, I tried opening up everything between pfsense and LAN, yet still no joy. But thanks for that observation about how Unbound works in supporting DNSSec. I think you're right: That's probably what caused the problem.