DNS resolver failed to resolve some addresses
-
@johnpoz No it's not working, with directed dig, got same message
;; communications error to 199.19.57.1#53: timed out ;; communications error to 199.19.57.1#53: timed out ;; communications error to 199.19.57.1#53: timed out
I temporarily set up another unbound on local network and it's works fine (in case there is dns isp filtering on ipv4, but that doesn't seem to be the case.)
On the resolver configuration page I only selected the WAN interface
/var/unbound/unbound.conf# Outgoing interfaces to be used outgoing-interface: 10.153.43.214and to be sure of routing
ping -S 10.153.43.214 199.19.57.1 PING 199.19.57.1 (199.19.57.1) from 10.153.43.214: 56 data bytes 64 bytes from 199.19.57.1: icmp_seq=0 ttl=53 time=243.655 ms 64 bytes from 199.19.57.1: icmp_seq=1 ttl=53 time=243.858 msping from this address is ok, but dig always gives a timeout
-
@martinez I always set my unbound to use loopback as its outgoing.. If you can not talk to ipv4 with unbound bound to your interface?
So your pfsense behind a nat.,. its wan IP is 10.153? Or you bound it to the lan interface for some strange reason??
I bind to the localhost, because it should just use your normal routing that way. But try binding it to all.
If bound to localhost, when system starts or if you have issues with your wan for example unbound can start and bind to the interface even if wan is not yet up, etc.
-
@johnpoz It's good to know for the loopback (I will find out more).
Yes, (unfortunately) I am behind a NAT from the access provider and the address 10.153 bound to my WAN interface.
I set the binding to All and rebooted, then localhost, with both configurations the problem remained unchanged
-
@martinez well what I would do is sniff on your wan interface while you doing a IPv4 query, say your trace.. If you see the query go out, and nothing back then problem is upstream of pfsense.. If you never see the query leave your wan with correct IP then problem is related to something on your side.
-
@johnpoz I just ran the test, and... I only get outgoing DNS traffic in IPv6 (with the ipv6 in alias below)
So I'm wondering if the problem somewhere :
Since I didn't receive IPv6 with DHCP, I used "virtual IP" to assign a public address on the WAN interface. However, I have outgoing DNS traffic with IPv6 defined as an alias, but no outgoing traffic with 10.153.
However, if I use a resolver internal to the LAN, I do get SNAT and outgoing traffic (and the correct responses).
I feel like I'm not doing this correctly ?
-
@martinez turn off your ipv6....
You need to turn off your IPv6 to validate ipv4 is working - if you can not talk to ipv4 dns, much of the internet is not going to work for you.
When you do a dns query to ipv4 address from behind pfsense it works.. But from pfsense it does not? Is it not sending anything at all? Is it sending it with wrong address?
Show a sniff on your wan with IPv6 off and from a client doing an dns query to some IPv4.. Then do the same query from pfsense cmd line. Unbound should be able to query to IPv4 addresses, if clients can talk to IPv4 out on the internet. If not then you have something major messed up.. Did you turn off IPv4 in unbound or something? With an option?
Do you have anything setup in the unbound (resolver) options box?
-
That's exactly it: clients can communicate with IPv4 and make requests to external DNS servers, while unbound can't.
I followed your procedure, with IPv6 disabled, and when I run a request from pfsense (with the DNS resolver pointing to unbound 127.0.0.1), I get nothing at all.
In the unbound configuration, I have no special, no "custom" options.
This is interesting:
- If I check "forward" in the resolver and specify a resolver that belongs to the LAN, the DNS resolution works.
- If I change the address to a resolver located on the Internet (i.e., outgoing through the WAN interface), it doesn't work.
I launched a
traceroutefrom the firewall (in case it behaves differently than with forwarded packets) on one of the external DNS that I tested and no route problems -
@martinez since you are forwarding, did you disable DNSSEC?
-
Yes, I just checked it's disabled. I must have disabled it since the troubleshooting began. I haven't touched it since.
-
As an aside: I have another problem with my configuration: I can't get the OpenVPN client to work with IPv4 (no problem with IPv6). I also tested it with OpenVPN on a LAN host, with no problems.
I think I can rephrase the problem: the firewall's internal services are no able to initiate (I haven't tested the listening) an IPv4 connection from the WAN interface only.
It's annoying me. I was able to work around the issue, and I'll let it sit for a bit... I'm wondering if I should reinstall and restore or completely re-start the configuration.
Any advice or ideas?
-
@martinez did you try a different DNS upstream server, this one is messed up.
If I try to use that DNS (199.19.57.1) from Switzerland, it returns no A record for wikipedia.com, like in @johnpoz second post.
dig wikipedia.org @199.19.57.1 ; <<>> DiG 9.10.6 <<>> wikipedia.org @199.19.57.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43783 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;wikipedia.org. IN A ;; AUTHORITY SECTION: wikipedia.org. 3600 IN NS ns2.wikimedia.org. wikipedia.org. 3600 IN NS ns1.wikimedia.org. wikipedia.org. 3600 IN NS ns0.wikimedia.org. ;; ADDITIONAL SECTION: ns0.wikimedia.org. 3600 IN A 208.80.154.238 ns1.wikimedia.org. 3600 IN A 208.80.153.231 ns2.wikimedia.org. 3600 IN A 198.35.27.27 ;; Query time: 22 msec ;; SERVER: 199.19.57.1#53(199.19.57.1) ;; WHEN: Fri Oct 17 06:15:25 CEST 2025 ;; MSG SIZE rcvd: 154dig +trace doesn't work:
dig +trace wikipedia.org @199.19.57.1 ; <<>> DiG 9.10.6 <<>> +trace wikipedia.org @199.19.57.1 ;; global options: +cmd ;; Received 28 bytes from 199.19.57.1#53(199.19.57.1) in 22 msI'd say this DNS server is filtering and if they do censoring then they may have blocked your IP?
-
@patient0 It worked, I think this server is simply not configured to work as a resolver. If you read the response carefully, you will see that it repliedn that it is a server that is authoritative for the org tld. , so it then tells you the registered servers that are authoritative for the wikipedia domain.
-
@martinez said in DNS resolver failed to resolve some addresses:
server that is authoritative for the org tld
It is indeed one of the ORG authoritative servers:
dig -x 199.19.57.1 ... ;; QUESTION SECTION: ;1.57.19.199.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.57.19.199.in-addr.arpa. 3274 IN PTR d0.org.afilias-nst.org. ... $ dig +trace wikipedia.org @1.1.1.1 ... ;; Received 525 bytes from 1.1.1.1#53(1.1.1.1) in 5 ms org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS b2.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. org. 86400 IN DS 26974 8 2 ... ;; Received 779 bytes from 2001:500:a8::e#53(e.root-servers.net) in 4 ms wikipedia.org. 3600 IN NS ns1.wikimedia.org. wikipedia.org. 3600 IN NS ns2.wikimedia.org. wikipedia.org. 3600 IN NS ns0.wikimedia.org. ... ;; Received 655 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 21 ms wikipedia.org. 180 IN A 185.15.58.224 ;; Received 58 bytes from 198.35.27.27#53(ns2.wikimedia.org) in 15 ms
