2.4.1: local DNS not working
-
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!!
Actually, my local IPv6 addresses are available via public DNS. I use a DNS service to do that. So, having an external DNS is just a back up. I have attached a capture showing the fall back in action. I modified the local DNS address in resolv.conf, to force queries to the Google DNS. Take a look at the transactions for google.ca. You'll first see an attempt to the phony local address. It fails, so the Google DNS is tried next. There are 3 separate examples in the capture for A, AAAA and MX records. In each case, the local lookup fails and then Google is tried. This is exactly the behavior I said would happen and also as described in the resolv.conf man page. Please do not try to confuse the issue by bringing in what Windows does, as I am not using Windows when I can avoid it. Also, who said they had localhost for the outgoing interface?
johnpoz, you know more than I do about pfSense and I assume you also know a lot about networking. However, here I'm seeing what I referred to before, where someone takes what's considered common knowledge and assumes it's gospel, without actually exploring the evidence and facts. In this thread, I earlier demonstrated with dig that the Google DNS was being used, when pfSense failed. I then posted a link to the resolv.conf man page, which describes how things work on Linux. Yet, despite that, you still insisted I was wrong and told me how it works in Windows, even though that is entirely irrelevant to my situation. Now, please go back and look at what I said, what the man page says and what the capture shows and show me if I'm wrong. Based on what I've provided, I am not.
BTW, I demonstrated to myself, years ago, that the DNS list works exactly as I described. That is the first DNS server is tried, then the 2nd, etc.. Please note, this is on Linux, not Windows.
-
Hi to all!
I want to share a little observation about issue with DNS Resolver. I updated my PFSENSE couple of weeks ago without any issues, but today DNS Resolver plays dead for me. After some tests I seen Resolver service is stopped and tried to put it up, with no effect, it just not starting, no errors, nothing. So I tried to switch off DNSSEC for a test, and when I clicked "Save", I've got this:
–----
The following input errors were detected:The generated config file cannot be parsed by unbound. Please correct the following errors:
/var/unbound/test/unbound_server.pem: No such file or directory
[1510244677] unbound-checkconf[89948:0] fatal error: auto-trust-anchor-file: "/var/unbound/test/root.key" does not exist in chrootdir /var/unbound
–---And - what a surpise! - there is no such folder /var/unbound/test/
So, I think we nailed the root of a problem.P.S. Sorry for my bad English
-
^^^^
I have also seen that error message and other issues. 2.4.1 took a working 2.4.0 installation and caused it to fail. Why should that happen? -
I can verify that directory is also non-existent for me. Not sure why or if it is the cause of the breakage, but it is still broken. (1 VM Only is like this)
However, the file also seems to not exist on any of my machines that work just fine.
-
a little update:
after another attempt to start Reslover I've got in log this one:
–--
Nov 10 12:14:31 unbound 31406:0 notice: init module 0: validator
Nov 10 12:14:31 unbound 31406:0 error: failed to read /root.key
Nov 10 12:14:31 unbound 31406:0 error: error reading auto-trust-anchor-file: /var/unbound/root.key
Nov 10 12:14:31 unbound 31406:0 error: validator: error in trustanchors config
Nov 10 12:14:31 unbound 31406:0 error: validator: could not apply configuration settings.
Nov 10 12:14:31 unbound 31406:0 error: module init for module validator failed
Nov 10 12:14:31 unbound 31406:0 fatal error: failed to setup modulesAfter that I checked /var/unbound/root.key and found it zero sized. I tried to rebuild the /var/unbound/root.key but on each startup attempt unbound truncates it again to 0 than fails to start.
-
After that I checked /var/unbound/root.key and found it zero sized. …..
From what I make of it, this file is related to the DNSSEC unbound housekeeping.
The file is auto re-created rather often it seems.unbound is unable to write to this pace ? A problem with the file system ?
Btw: this my file :
; autotrust trust anchor file ;;id: . 1 ;;last_queried: 1510324020 ;;Fri Nov 10 15:27:00 2017 ;;last_success: 1510324020 ;;Fri Nov 10 15:27:00 2017 ;;next_probe_time: 1510363838 ;;Sat Nov 11 02:30:38 2017 ;;query_failed: 0 ;;query_interval: 43200 ;;retry_time: 8640 . 172800 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ;{id = 19036 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1422533205 ;;Thu Jan 29 13:06:45 2015 . 172800 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1502688003 ;;Mon Aug 14 07:20:03 2017Also : DNSSEC is checked in my unbound setup (some of my sites are already DNSSEC comptabile - all of them will be seen as soon as I fully understand how this all works AND how to automatize the maintenance of it (which is rather daunting).
Example : http://dnsviz.net/d/test-domaine.fr/dnssec/edit : or may be this : you checked DNSSEC, but your unbound can not connect to DNS servers to establish DNSSEC traffic (if that even exists - other then basic port 53 UDP and TCP streams)
-
@Gertjan if your looking to automatic signing of your domains, etc.. the article here was quite informative on setup and creation of zonesigner script that you can just cron to update, etc.
https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server–2
-
I too have experienced problems with the DNS Resolver since upgrading to 2.4.1. It was timed just about perfectly with the Comcast outage that happened this week so I wasn't sure if the problem was on my end or not. At the time, I was also attempting to set up LAGG/LACP and had a good amount of problems with that (the reason for upgrading from 2.3) but that's another story.
After reading through the thread and running the dig commands Derelict suggested earlier, I noticed that 192.168.1.1 would resolve google.com but 192.168.10.1 (the VLAN) and 8.8.8.8/8.8.4.4 would not. I edited the desktop pc's resolv.conf file to nameserver 192.168.1.1 and the resolver now works as expected.
Previously, the resolv.conf nameserver entry was pointing to VLAN 10 which this pc is on. (192.168.10.1)
What would have caused the previous configuration to not work anymore?
For reference, I followed this guide on setting up the vpn and firewall: https://nguvu.org/pfsense/pfsense-baseline-setup/
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 @192.168.10.1 www.google.com A
dig @192.168.10.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.
-
"What would have caused the previous configuration to not work anymore?"
Unbound was not listening on that vlan IP.. Your firewall rules do not allow access to the vlan IP on 53..
What are you firewall rules on your vlan 10 interface? Your device still in vlan 10? Can you ping the pfsense vlan 10 IP. Is unbound set to listen on the vlan 10 interface.
Look in the unbound log, when it starts up did it have problem binding to the IP.. Look at the output of netstat -an you run on pfsense does it show listening?
-
Like you mentioned, I think it may be a firewall rule issue. I am slowly getting better at understanding the logic to them but still struggle from time to time.
VL10 Rules
Before posting this reply, I created a rule at the top of VL10:Source: VL10 net Port: * Destination: VL10 address Port: 53(DNS)I have previously been successful using this rule which was created from the tutorial I linked above:
Source: VL10 net Port: * Destination: LOCAL_SUBNETS (an alias with all VLAN Subnets) Port: Allowed_OUT_LAN (an alias with DNS in it)
General DNS Resolver Options
Network Interfaces: VL10 is highlighted
Ping
$ ping -c 5 192.168.10.1 PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data. 64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=0.243 ms 64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.206 ms 64 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=0.222 ms 64 bytes from 192.168.10.1: icmp_seq=4 ttl=64 time=0.189 ms 64 bytes from 192.168.10.1: icmp_seq=5 ttl=64 time=0.211 ms --- 192.168.10.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4049ms rtt min/avg/max/mdev = 0.189/0.214/0.243/0.020 ms
netstat -an
Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 192.168.10.1.53 *.* LISTEN
DNS Resolver logs
I changed the verbosity level to 5, restarted the service and checked the logs setting so it would show 600 logs. I didn't see anything about binding to the IP. I searched for 192.168.10.1 as well.
I ordered 2 SuperMicro SATA SSDs and will be re-installing in a few days but would like to understand where I am going wrong.
Also, thanks for the help. I'm learning a good amount from this thread. Networking is one of my weaknesses
EDIT I found the issue with mine. I had set a NAT rule to forward 5353 to 53 when the DNSResolver "broke" so I could use the DNSForwarder. While troubleshooting, I deleted the firewall rule in the VL10 rules page but forgot to delete the VL10 NAT rule. Deleted the VL10 NAT rule and all is well now.
I feel accomplished and like a dumbass at the same time!
