DNS Resolver (+Fowarding) SERVFAIL For LAN Clients

fhsrthsrh

I'm attempting to configure a virtual network in my home network with pfSense as a virtual machine. There are four machines: a virtual linux client (10.0.1.10), a virtual pfSense (LAN: 10.0.1.1 + WAN: 192.168.1.30), a physical router running DD-WRT + DNS (192.168.1.1), and a HTTP server (192.168.1.100). The HTTP server is registered to the DD-WRT DNS server as server.com, and the pfSense DNS resolver is enabled and forwarding mode is active. The system information page on the pfSense router shows that its' configured DNS servers are 127.0.0.1 and 192.168.1.1, and /etc/resolve.conf on the client machine points to 10.0.1.1.

The client machine can ping the HTTP server (with 'Block private networks and loopback addresses' disabled), but it is unable to lookup 'server.com' instead dig returns SERVFAIL. Interestingly, I am able to lookup the host on the pfSense router itself, just not the client. Diagnostics -> DNS Lookup correctly displays 192.168.1.100. If I run dig server.com on the client, it fails but if I run dig server.com @192.168.1.1 it resolves to 192.168.1.100.

ping google.com also fails with Temporary failure in name resolution.

pfSense is (mostly) configured as default.

Does anyone know what I could have done wrong?

Thanks.

Gertjan

Hi,

@fhsrthsrh said in DNS Resolver (+Fowarding) SERVFAIL For LAN Clients:

If I run dig server.com on the client

Ask dig to tell you what it does.
dig server.com +trace

Also :
@fhsrthsrh said in DNS Resolver (+Fowarding) SERVFAIL For LAN Clients:

The HTTP server is registered to the DD-WRT DNS server as server.com,

@fhsrthsrh said in DNS Resolver (+Fowarding) SERVFAIL For LAN Clients:

If I run dig server.com on the client, it fails but if I run dig server.com @192.168.1.1 it resolves to 192.168.1.100.

Dig using is using what DNS on that client ?
It should be "10.0.1.1 " = pfSense, as you said.
And of course, the DNS = "10.0.1.1 " = pfSense should be listening on port 53 on LAN.
If you force it to use @192.168.1.1 , (the DD-WRT) it works, so I guess the firewall on LAN is ok.
If the Resolver receives the request (pump up the log details and you can see for your self) for server.com, is the request forwarder up stream, to your DD-WRT ? Can you see it doing so ? Can you see it entering n the DD-WRT (dono if these mini devices can log that details)
Why not adding also a domain override for server.com on pfSense ?

Btw : a DD-WRT before pfSense ?
Why ?

I'm using a lot of DD-WRT behind pfSense, all reduced to AP's, true.
One router is more then enough.
You can place your web server behind pfSense, on some DMZ type of LAN.
Simple, easy to maintain, pretty straightforward - no more DNS issues.

johnpoz

@fhsrthsrh said in DNS Resolver (+Fowarding) SERVFAIL For LAN Clients:

pfSense DNS resolver is enabled and forwarding mode is active.

where is it set to forward? dd-wrt ns?

Not a fan of using a tld as your domain, in the case of server.com - better to use say server.yourdomain.tld

Gertjan

@johnpoz said in DNS Resolver (+Fowarding) SERVFAIL For LAN Clients:

@fhsrthsrh said in DNS Resolver (+Fowarding) SERVFAIL For LAN Clients:

pfSense DNS resolver is enabled and forwarding mode is active.

where is it set to forward? dd-wrt ns?

@fhsrthsrh said in DNS Resolver (+Fowarding) SERVFAIL For LAN Clients:

The system information page on the pfSense router shows that its' configured DNS servers are 127.0.0.1 and 192.168.1.1

So he's forwarding to 127.0.0.1 (pfSense itself) and the upstream router 192.168.1.1, the DD-WRT.

johnpoz

No that is not what it means, it means pfsense will ask itself (default resolve) and maybe 192.168.1.1 - but that is not where unbound will forward too, unless actually set to forward.

So yeah that would explain why pfsense can resolve, but when a client asks it does not.

Depending on what unbound sends back, nx or servfail when it resolves would determine if 192.168.1.1 is even asked, etc..

If he wants pfsense to ask dd-wrt for dns, then he should setup unbound to forward to that.. Then that should either forward for public stuff or resolve on dd-wrt, etc.

if he just wants pfsense to be able to resolve whatever entries he puts on dd-wrt for specific domains, then he could just seutp domain overrides for those domains to point to dd-wrt as the ns for those domains.