2.4.1: local DNS not working
-
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
-
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?
-
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
-
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.
-
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.
-
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.0Bottom 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.
-
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.
-
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.
-
- 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.
-
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 -
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.
-
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>
-
OK don't listen to years of experience.
-
Try to dig from command line in pfsense. If it works, its not the same Issue I'm having.
-
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.
-
Show the output please. I have NO IDEA what "dig shows 127.0.0.1" means. Shows where? There is no context.
-
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 -
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Sun Nov 05 15:19:58 EST 2017
;; MSG SIZE rcvd: 55snipped
;; 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: 55How are your addresses IPv6 and Global ?
-
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.
-
/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: 55If that was taken on pfSense then the local resolver is working fine. You asked localhost for an answer and got one.
-
I have valid global unicast addresses on IPv6.
Me too… and to say, dual stack IPv6 & (IPv4 NAT) on LAN's.
A host on LAN reports as the DNS server the IPv4 pfSense-LAN address.
You have a special home config I now believe ;) Single stack, IPv6 ?
-
Nonsense… Resolver works just fine in 2.4.. If it broke then the boards would be under ddos attack with people complaining..
Well, without logs there isn't much point in arguing. But I will say based on the very general sense its not nonsense. I have seen resolver break two other times (once in 2.3.x and once in 2.4.0). Both were shown to me after a level 1 tech tried upgrading or something. Both times I saw security errors in the logs and disabled DNSSEC support and the problem was fixed.
I've never reported the issue because it was a quick hack fix, but the point is without diagnosing, anything is possible.
-
DNSSEC being broken is not necessarily the fault of the resolver. Particularly if the resolver is in forwarding mode.
Anyone who claims "it's broken" needs to be able to show what isn't working in some way that people on a forum can see.
"It's broken" when it is working for tens of thousands of sites is nonsense. Or at least points to a local configuration error at that site which, again, would require some evidence presented for evaluation.
-
If that was taken on pfSense then the local resolver is working fine. You asked localhost for an answer and got one.
I noticed that too. But it does not work for a computer behind pfSense. I included dig examples in an earlier message, that showed pfSense works with forwarder, but not resolver, for that computer.
-
@hda:
I have valid global unicast addresses on IPv6.
Me too… and to say, dual stack IPv6 & (IPv4 NAT) on LAN's.
A host on LAN reports as the DNS server the IPv4 pfSense-LAN address.
You have a special home config I now believe ;) Single stack, IPv6 ?
I always get an IPv6 address as shown in dig. My network is dual stack, with everything capable of IPv6 getting both IPv4 & IPv6 addresses. My main computer uses static configuration for DNS, with IPv6 addresses for pfSense and Google DNS servers. Devices that connect via DHCP get the IPv4 address for pfSense DNS for the 1st DNS server and 8.8.8.8 & 4.4.4.4 for 2nd & 3rd.
-
Dude.
Enable the resolver.
Go to the client that doesn't work.
What are the configured name servers on that client? Probably in /etc/resolv.conf. There is a lot of disparity in how this is done now. In ubuntu it's all generated by resolvconf, YDMV.
Query each of them individually as in:
dig @192.168.1.1 www.google.com A
dig @192.168.1.1 www.google.com AAAA
dig @8.8.8.8 www.google.com A
dig @8.8.8.8 www.google.com AAAA
dig @8.8.4.4 www.google.com A
dig @8.8.4.4 www.google.com AAAASee if you can see where the problem is.
-
Here's the relevant lines from /etc/resolv.conf
nameserver 2607:fea8:4cdf216:17ff:fea7:xyz
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844The first is my firewall, with address changed to protect the guilty and the other 2 are Google.
With resolver enabled.
To pfSense DNS
$ dig @2607:fea8:4cdf216:17ff:fea7:xyz google.com A
; <<>> DiG 9.9.9-P1 <<>> @2607:fea8:4cdf216:17ff:fea7:xyz google.com A
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached$ dig @2607:fea8:4cdf216:17ff:fea7:xyz google.com AAAA
; <<>> DiG 9.9.9-P1 <<>> @2607:fea8:4cdf216:17ff:fea7:xyz google.com AAAA
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reachedTo Google DNS
$ dig @2001:4860:4860::8888 google.com A; <<>> DiG 9.9.9-P1 <<>> @2001:4860:4860::8888 google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65367
;; 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 22:19:49 EST 2017
;; MSG SIZE rcvd: 55$ dig @2001:4860:4860::8888 google.com AAAA
; <<>> DiG 9.9.9-P1 <<>> @2001:4860:4860::8888 google.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 990
;; 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 AAAA;; ANSWER SECTION:
google.com. 299 IN AAAA 2607:f8b0:400b:808::200e;; Query time: 84 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Sun Nov 05 22:20:34 EST 2017
;; MSG SIZE rcvd: 67As you can see in the above, pfSense fails and Google works. When I switch pfSense to forwarder, it works fine.
BTW, I run openSUSE Leap 42.3.
-
Are you passing IPv6 DNS into that interface?
Are you listening for DNS on that interface? Meaning does the resolver have that interface or All interfaces selected?
What is the output of this command run on the firewall?
netstat -an | grep LISTEN | grep 53
Does the DNS Resolver log show anything interesting?
When I switch pfSense to forwarder, it works fine.
And the forwarder is probably configured to forward to IPv4 name servers. So there might be a problem with IPv6 traffic from the firewall itself or maybe something else. Really hard to say with the information that has been provided. It is generally pretty difficult when someone has it set in their head that pfSense is the broken component and not a misconfiguration of the same..
-
…..
To pfSense DNS$ dig @2607:fea8:4cdf216:17ff:fea7:xyz google.com A
=> connection timed out; no servers could be reached$ dig @2607:fea8:4cdf216:17ff:fea7:xyz google.com AAAA
=> connection timed out; no servers could be reachedRepeat - and force to use IPv4 and IPv6 :
dig -4 @2607:fea8:4cdf216:17ff:fea7:xyz google.com A
and
dig -6 @2607:fea8:4cdf216:17ff:fea7:xyz google.com A -
Anyway, my setup does work as expected ;)
With a simple Resolver DNSSEC config:
Network Interfaces:
LAN
OPT1
OPT2
LocalhostOutgoing Network Interfaces:
Localhost[2.4.2-DEVELOPMENT][root@apu2b2.thisplaced]/root: netstat -an | grep LISTEN | grep 53 tcp4 0 0 127.0.0.1.953 *.* LISTEN tcp6 0 0 ::1.53 *.* LISTEN tcp4 0 0 127.0.0.1.53 *.* LISTEN tcp6 0 0 2001:beaf:babe:3:.53 *.* LISTEN tcp4 0 0 192.168.22.1.53 *.* LISTEN tcp4 0 0 10.8.4.1.53 *.* LISTEN tcp6 0 0 2001:beaf:babe:1:.53 *.* LISTEN tcp4 0 0 192.168.1.1.53 *.* LISTEN [2.4.2-DEVELOPMENT][root@apu2b2.thisplaced]/root: cat /etc/resolv.conf nameserver 127.0.0.1 search thisplaced
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sun Nov 5 23:57:37 2017 from 192.168.1.115 pi@Pi-df-RED:~ $ cat /etc/resolv.conf # Generated by resolvconf domain thisplaced nameserver 192.168.22.1 nameserver 2001:beaf:babe:3::1 nameserver 2001:beaf:babe:1::1 pi@Pi-df-RED:~ $ dig @2001:beaf:babe:3::1 google.com ; <<>> DiG 9.9.5-9+deb8u13-Raspbian <<>> @2001:beaf:babe:3::1 google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30509 ;; 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.17.46 ;; Query time: 34 msec ;; SERVER: 2001:beaf:babe:3::1#53(2001:beaf:babe:3::1) ;; WHEN: Mon Nov 06 13:26:35 UTC 2017 ;; MSG SIZE rcvd: 55 pi@Pi-df-RED:~ $
-
Repeat - and force to use IPv4 and IPv6 :
dig -4 @2607:fea8:4cdf216:17ff:fea7:xyz google.com A
and
dig -6 @2607:fea8:4cdf216:17ff:fea7:xyz google.com A$ dig -4 @2607:fea8:4cdf216:17ff:fea7:xyz google.com A
dig: couldn't get address for '2607:fea8:4cdf:ef00:216:17ff:fea7:f2d3': address family not supportedAs expected, forcing an IPv4 query to an IPv6 address won't work.
$ dig -6 @2607:fea8:4cdf216:17ff:fea7:xyz google.com A
; <<>> DiG 9.9.9-P1 <<>> -6 @2607:fea8:4cdf:ef00:216:17ff:fea7:f2d3 google.com A
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reachedSame result as before.
Are you passing IPv6 DNS into that interface?
Are you listening for DNS on that interface? Meaning does the resolver have that interface or All interfaces selected?
My desktop computer is configured only with IPv6 DNS addresses, so yes IPv6 is enabled. Also, as mentioned earlier, forwarder works fine, so that would rule out any address issues. I did not make any changes from 2.4.0, where resolver worked to 2.4.1, where it fails.
root: netstat -an | grep LISTEN | grep 53
tcp4 0 0 127.0.0.1.953 . LISTEN
tcp6 0 0 ::1.53 . LISTEN
tcp4 0 0 127.0.0.1.53 . LISTENIt's listening only on the loopback. Prior to the update, I had resolver network interfaces configured to all local networks and outgoing interface to WAN. However, after the update, that failed, giving errors as described in the other thread.
However, I think I just found the problem. When I was trying to resolve the problem initially, someone mentioned to select All & All for the interfaces. That didn't work and the config wouldn't let me save just the local networks. I'd get the error "This system is configured to use the DNS Resolver as its DNS server, so Localhost or All must be selected in Network Interfaces". I had been running with WAN for the outgoing interface and localhost for network, as that was one of the 2 allowed in the configuration. I had previously tried ALL and it failed, but appears to be working now. Why is it now necessary to choose ALL, when previously it worked with selected interfaces?
-
-
It is listening only on loopback.
Then you need to port forward DNS requests to the loopback interface or make it listen on the interfaces you are trying to use as name servers by selecting those interfaces in the resolver configuration.
Like I said MANY TIMES! Select "All" for the interfaces in the resolver config and you'll get this:
tcp4 0 0 *.53 . LISTEN
*tcp6 0 0 .53 . LISTENWho knows what weird configuration you had that was working and now isn't.
This is all I see for unbound from 2.4.0 to 2.4.1.
https://redmine.pfsense.org/issues/7884
https://redmine.pfsense.org/issues/7814
-
-
Sigh.
-
My main computer uses static configuration for DNS, with IPv6 addresses for pfSense and Google DNS servers. Devices that connect via DHCP get the IPv4 address for pfSense DNS for the 1st DNS server and 8.8.8.8 & 4.4.4.4 for 2nd & 3rd.
This is so freaking BORKED!
Derelict is right on the money when he says that is broken..
When you state " first DNS to try and Google as the 2nd, should the first fail."
Doesn't work that way!! Your logic is that client always asks pfsense… What does pfsense return for what you queried? NX, Refused, Error? Timeout.. What? So then you believe client asks google for whatever it is you asked. Now the next thing it wants to lookup up you believe it goes back to ask your 1st listed dns?
Sorry but it does NOT work that way!! You have no control over which dns is going to get asked what from a client.. Especially with windows... When you point a client to more than 1 nameserver.. These multiple name server need to be able to return the same info... You do not point a ns that resolve local, and then also point to a ns that can not resolve your local.. If for some reason your client asks google for a local record.. its going to send back NX... Once a dns client gets NX why would it go ask a different NS.. It was told that record doesn't exist.. Not that ns timed out.. Or sorry go ask someone else I don't know.. It got told that record does not exist - period.. So why should ask some other NS hoping the answer is different..
dig @8.8.8.8 pfsense.local.lan
; <<>> DiG 9.11.2 <<>> @8.8.8.8 pfsense.local.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52361
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1My client will not ask another NS in its list after getting that.. There is no point to it.. So pointing clients to different ns that can not resolve the same info is asking for problems plain and simple..
From MS
https://technet.microsoft.com/en-us/library/cc961411.aspx
"If at any point the DNS Client service receives a negative response from a server, it removes every server on that adapter from consideration during this search. For example, if in step 2, the first server on Alternate Adapter A gave a negative response, the DNS Client service would not send the query to any other server on the list for Alternate Adapter A." -
My main computer uses static configuration for DNS, with IPv6 addresses for pfSense and Google DNS servers. Devices that connect via DHCP get the IPv4 address for pfSense DNS for the 1st DNS server and 8.8.8.8 & 4.4.4.4 for 2nd & 3rd.
This is so freaking BORKED!
Derelict is right on the money when he says that is broken..
When you state " first DNS to try and Google as the 2nd, should the first fail."
Doesn't work that way!! Your logic is that client always asks pfsense… What does pfsense return for what you queried? NX, Refused, Error? Timeout.. What? So then you believe client asks google for whatever it is you asked. Now the next thing it wants to lookup up you believe it goes back to ask your 1st listed dns?
Sorry but it does NOT work that way!! You have no control over which dns is going to get asked what from a client.. Especially with windows... When you point a client to more than 1 nameserver.. These multiple name server need to be able to return the same info... You do not point a ns that resolve local, and then also point to a ns that can not resolve your local.. If for some reason your client asks google for a local record.. its going to send back NX... Once a dns client gets NX why would it go ask a different NS.. It was told that record doesn't exist.. Not that ns timed out.. Or sorry go ask someone else I don't know.. It got told that record does not exist - period.. So why should ask some other NS hoping the answer is different..
dig @8.8.8.8 pfsense.local.lan
; <<>> DiG 9.11.2 <<>> @8.8.8.8 pfsense.local.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52361
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1My client will not ask another NS in its list after getting that.. There is no point to it.. So pointing clients to different ns that can not resolve the same info is asking for problems plain and simple..
From MS
https://technet.microsoft.com/en-us/library/cc961411.aspx
"If at any point the DNS Client service receives a negative response from a server, it removes every server on that adapter from consideration during this search. For example, if in step 2, the first server on Alternate Adapter A gave a negative response, the DNS Client service would not send the query to any other server on the list for Alternate Adapter A."Who said anything about running Windows? I try to avoid using it. My computers run mainly Linux and I provided a link to a Linux man page about resolv.conf that showed it worked exactly as I said. Also, what's borked about a device that uses DHCP to get it's IPv4 config also using IPv4 DNS addresses? Last I checked IPv4 DHCP can't provide IPv6 addresses and I don't run DHCPv6. So, what exactly is "borked"?
-
Pointing to local NS and public NS that can not resolve your local is BORKED - plain and simple.. This has been this way since the start of DNS..
Please show me your sniff of your dns queries coming from your machine showing it asking another NS after you got a NX from some public NS..
Unless the 1st server ask returns SERVFAIL or Timesouts - why should the clients dns move to the second NS in the list.. NX stops all queries.. Since it got an answer that the record in question does not exist, why bother asking anything else.
And even using say dnsmasq as local dns client that sends to all NS in parallel, it uses the first one to answer.. And doesn't look at any other responses, etc..
So how exactly is your linux box setup.. And what did it query and what did it get in response… Saying that you have pfsense, google for your NS 1, 2, 3 doesn't tell us what the problem is or isn't.
Do a simple query from the client.. Does it resolve or not.. If you query pfsense unbound on whatever address its listening on.. What is the response... This is a simple dig or nslookup or host command. Please post the output on why you think dns is not working... Saying its broke is just nonsense..
You don't tell you mech the car is broke.. You tell him or show him what is not working.. Unless you show us what is not working.. I resolve in this order staying in the dns theme - unless I can duplicate the error its PEBKAC.. Unless you can show me what its going on or not happening, PEBKAC..
Once I get back PEBKAC, I don't bother looking for other answers until actually get shown some info to work with..
How exactly do you expect unbound to work with
Outgoing Network Interfaces:
LocalhostCome on dude - really!!
-
I concur. My DNS resolver broke after updating to 2.4.1
Have been using the same setup and have run every update since 2.2 and never had any problem.
I'm using a VPN client and am forcing the DNS resolver to query the root requests through the VPN tunnel rather than WAN, otherwise my middle eastern ISP will hijack the requests (verified with DNS leaktest). It has worked like a charm until 30 minutes ago after updating to 2.4.1.
When I manually add a DNS server (8.8.8.8 for example) on the clients it works but using the pfsense DNS resolver, then it times out.
All solved. Turned out to be a freak issue with my VPN provider rather than pfSense -
Please enumerate, completely and thoroughly, the steps you have taken in the DNS resolver, The OpenVPN client connection, and policy routing to effect such a configuration.
Saying "resolver broke" doesn't give anyone anything to go on.