2.4.1: local DNS not working

repomanz

Hi everyone.

i'm sure i have something misconfigured somewhere.

under general settings, i have the local DNS server set (10.180.x.x)
in dnsresolver, i have static mappings for a couple linux servers. I also have dhcp and static ips being registered in dnsresolver. dnssec is checked
in dhcp server, the dns value is blank (should default to #1 right)
in dhcp server i have a few static leases defined

However, my clients don't appear to be routing their DNS requests to the 10.180.x.x address above. I've renewed their leases, flushed dns, bounced etc. I also noticed that unbound restarts every few minutes (is that normal?)

Hoping i have something misconfigured here. Thoughts?

Jon

johnpoz

Out of the box pfsense runs unbound in resolver mode… That means it talks to root servers, and walks down the tree to find the authoritative server for whatever domain your looking up.

dhcp dns if left blank will point to pfsense for dns.. Look on the dhcp client with say ipconfig /all on a windows client and it will show you what its using for dns. This is going to point to pfsense as it normally should. If you want your clients to use some local dns 10.180.. Then set that specifically in your dhcp server settings so it will hand that to the clients.

What is your local dns doing then - is it forwarding to pfsense, forwarding outside - resolving?

repomanz

Hey John - thanks for the quick response. Thanks for the additional information about unbound / resolver and the behavior. Right before you responded i think i figured out the problem.

I checked DNS forwarding mode in the resolver and now i'm seeing my local dns server get hit. Outside of my local dns server being poisoned after an exploit, do you see any other issues with that configuration in context of dns security or other pfsense specific issues?

Jon

JKnott

Hoping i have something misconfigured here. Thoughts?

I was running resolver, but it failed when I updated to 2.4.1. I have to use forwarder now.

johnpoz

Nonsense… Resolver works just fine in 2.4.. If it broke then the boards would be under ddos attack with people complaining..

Putting it into forwarder mode is NOT the correct solution.. So now your clients are asking pfsense, just to ask your local dns to go and do what exactly, then resolve? Have you clients ask your local dns directly - then have it forward to pfsense to resolve.

JKnott

Nonsense…

No, not nonsense. Resolver has flat out failed since I updated to 2.4.1. I had been running resolver almost as long as pfSense or over 1.5 years. When I first go to a site, there is a several second delay, but not on the next attempt. On this computer, the first DNS is my pfSense firewall and the 2nd is Google. When I run forwarder, dig shows that pfSense is used for DNS. When I run resolver, it uses Google, as the pfSense DNS does not work at all. I documented this in my thread about this problem.
https://forum.pfsense.org/index.php?topic=139070.0

Bottom line, with every version of pfSense I've used prior to 2.4.1, resolver worked. After updating to 2.4.1, it fails. Claiming "nonsense" does not change that fact.

If you have any suggestions, I'd like to hear them.

kejianshi

Still broken for me also on 1 VM. Not a big deal for me since its just a crash test dummy VM.

I think there is something in the network environment there screwing it up. Dig fails outright.

repomanz

@johnpoz:

Nonsense… Resolver works just fine in 2.4.. If it broke then the boards would be under ddos attack with people complaining..

Putting it into forwarder mode is NOT the correct solution.. So now your clients are asking pfsense, just to ask your local dns to go and do what exactly, then resolve? Have you clients ask your local dns directly - then have it forward to pfsense to resolve.

John - need some clarification:

If under general settings, I have 1 DNS entry (my dns server). If i don't check the forwarder option under resolver then my internal clients do not hit my DNS (only pfsense out to google i suppose). It's only when I enable to forward option in the resolver that it works correctly.

So - this sounds similar to the other person talking above about pfsense using google and ignoring dns settings.

Derelict

under general settings, i have the local DNS server set (10.180.x.x)

in dnsresolver, i have static mappings for a couple linux servers. I also have dhcp and static ips being registered in dnsresolver. dnssec is checked
3) in dhcp server, the dns value is blank (should default to #1 right)

in dhcp server i have a few static leases defined

No. It defaults to the interface address the DHCP Server is running on.

Leave blank to use the system default DNS servers: this interface's IP if DNS Forwarder or Resolver is enabled, otherwise the servers configured on the System / General Setup page.

Look at the client that was configured using DHCP. What are its configured name servers? What happens when it tries to use them to resolve names? Then look at why that might be. Using tools like dig/drill to solve this instead of the silly windows tools helps a lot.

JKnott

So - this sounds similar to the other person talking above about pfsense using google and ignoring dns settings.

No, it's not pfSense using Google DNS. It's my computer, which has pfSense configured as the first DNS to try and Google as the 2nd, should the first fail. PfSense resolver fails, so the computer falls through to use Google. This accounts for the delay when I first go to a web site. Dig proves it. When resolver is configured, it uses Google, when forwarder, pfSense.

Here's what happens on my computer. The first time is with resolver enabled and the 2nd, with resolver. The firewall address has been changed to protect the guilty. ;)

$ dig google.com

; <<>> DiG 9.9.9-P1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46476
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 299 IN A 172.217.0.238

;; Query time: 48 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Sun Nov 05 15:19:58 EST 2017
;; MSG SIZE rcvd: 55

$ dig google.com

; <<>> DiG 9.9.9-P1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9659
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 199 IN A 172.217.2.174

;; Query time: 13 msec
;; SERVER: 2607:fea8:4cdf216:17ff:fea7:xyz#53(2607:fea8:4cdf216:17ff:fea7:xyz)
;; WHEN: Sun Nov 05 15:21:33 EST 2017
;; MSG SIZE rcvd: 55

Derelict

No, it's not pfSense using Google DNS. It's my computer, which has pfSense configured as the first DNS to try and Google as the 2nd, should the first fail.

Common mistake.

ALL configured client name servers MUST return the same answers to the same questions. This is ESPECIALLY true if you want to use local overrides.

There is NO guarantee which configured name server will be used first by the client.

JKnott

@Derelict:

No, it's not pfSense using Google DNS. It's my computer, which has pfSense configured as the first DNS to try and Google as the 2nd, should the first fail.

Common mistake.

ALL configured client name servers MUST return the same answers to the same questions. This is ESPECIALLY true if you want to use local overrides.

There is NO guarantee which configured name server will be used first by the client.

Not according to the Linux man pages:

nameserver Name server IP address
Internet address of a name server that the resolver should
query, either an IPv4 address (in dot notation), or an IPv6
address in colon (and possibly dot) notation as per RFC 2373.
Up to MAXNS (currently 3, see <resolv.h>) name servers may be
listed, one per keyword. If there are multiple servers, the
resolver library queries them in the order listed. If no
nameserver entries are present, the default is to use the name
server on the local machine. (The algorithm used is to try a
name server, and if the query times out, try the next, until
out of name servers, then repeat trying all the name servers
until a maximum number of retries are made.)

http://man7.org/linux/man-pages/man5/resolv.conf.5.html

So, since pfSense is listed first in /etc/resolv.conf, followed by Google, then pfSense will be tried first and if it fails, then Google.</resolv.h>

Derelict

OK don't listen to years of experience.

kejianshi

Try to dig from command line in pfsense. If it works, its not the same Issue I'm having.

JKnott

@kejianshi:

Try to dig from command line in pfsense. If it works, its not the same Issue I'm having.

Dig shows 127.0.0.1 with either forwarder or resolver.

Derelict

Show the output please. I have NO IDEA what "dig shows 127.0.0.1" means. Shows where? There is no context.

JKnott

@Derelict:

Show the output please. I have NO IDEA what "dig shows 127.0.0.1" means. Shows where? There is no context.

/root: dig google.com

; <<>> DiG 9.11.2 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63302
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 300 IN A 172.217.0.238

;; Query time: 310 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Nov 05 18:31:26 EST 2017
;; MSG SIZE rcvd: 55

hda

;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Sun Nov 05 15:19:58 EST 2017
;; MSG SIZE rcvd: 55

snipped

;; SERVER: 2607:fea8:4cdf216:17ff:fea7:xyz#53(2607:fea8:4cdf216:17ff:fea7:xyz)
;; WHEN: Sun Nov 05 15:21:33 EST 2017
;; MSG SIZE rcvd: 55

How are your addresses IPv6 and Global ?

JKnott

How are your addresses IPv6 and Global ?

???

I have valid global unicast addresses on IPv6. That's never been the issue. The problem is when pfSense is configured to use resolver for DNS, it fails, but works with forwarder. Nothing else changed when I updated from 2.4.0.

Derelict

/root: dig google.com

; <<>> DiG 9.11.2 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63302
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 300 IN A 172.217.0.238

;; Query time: 310 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Nov 05 18:31:26 EST 2017
;; MSG SIZE rcvd: 55

If that was taken on pfSense then the local resolver is working fine. You asked localhost for an answer and got one.