2.4.1: local DNS not working
-
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:4cdf
216: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:4cdf
216: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:4cdf
216:17ff:fea7:xyz google.com A; <<>> DiG 9.9.9-P1 <<>> @2607:fea8:4cdf
216:17ff:fea7:xyz google.com A
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached$ dig @2607:fea8:4cdf
216:17ff:fea7:xyz google.com AAAA; <<>> DiG 9.9.9-P1 <<>> @2607:fea8:4cdf
216: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:4cdf
216:17ff:fea7:xyz google.com A
=> connection timed out; no servers could be reached$ dig @2607:fea8:4cdf
216: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 thisplacedDebian 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:4cdf
216: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:4cdf
216: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
-
