0

I am debugging an issue with Unbound (DNS Resolver software) on CentOS Linux release 7.5.1804 (Core). I have 2 VMs in different environments that are supposedly running the same Unbound software.

[root@vm1 ~]# rpm -qa | grep unbound
unbound-libs-1.6.6-1.el7.x86_64
unbound-1.6.6-1.el7.x86_64

And:

[root@vm2 ~]# rpm -qa | grep unbound
unbound-libs-1.6.6-1.el7.x86_64
unbound-1.6.6-1.el7.x86_64

Both VMs are CentOS 7.5.1804 (I checked /etc/redhat-release) and are running the latest kernel available for CentOS: kernel-3.10.0-862.14.4.el7.x86_64.

Both VMs have enough CPU, RAM, HDD space.

VM1 was instantiated from a minimal ISO CentOS, while for VM2 I don't remember.

Both VMs have ~600 rpm packages installed (if that matters at all). They differ in rpm packages, but all the rpm packages they have are the latest ones available (yum update).

Both VMs have the same unbound*.service files, the same unbound.conf file and the same files and directories in /etc/unbound/.

The problem I have is:

  • systemctl start unbound.service (or restart) on VM1 takes ~1 minute to complete.
  • systemctl start unbound.service (or restart) on VM2 takes 1-2 seconds to complete.

I am not sure what is happening.

What could be the problem with VM1? How do I debug a problem like this?

filbranden
  • 652
  • 5
  • 9
Subzero123
  • 31
  • 1
  • 3
  • Do you see anything relevant in `systemctl status unbound.service` or `journalctl -u unbound.service` after you start that service on both VMs? That's where I'd start looking to troubleshoot this issue... Wanna take a look and maybe edit the question to include that output? What about network/firewall or DNS resolution? Is it possible VM1 is trying to resolve a name at startup (maybe VM1 itself) and failing with a timeout? Perhaps entry in /etc/hosts missing? – filbranden Nov 21 '18 at 06:01
  • @FilipeBrandenburger Nov 21 14:34:20 vm1 unbound-checkconf[62370]: unbound-checkconf: no errors in /var/unbound/unbound.conf Nov 21 14:35:11 vm1 systemd[1]: Started Unbound recursive Domain Name Server. There is no DNS resolution issue or firewall blocking DNS, I am able to ping domains, nslookup them etc. P.S: Cool that I doxxed myself. – Subzero123 Nov 21 '18 at 13:41

2 Answers2

1

For anyone else that runs into this. I had a very similar issue and it turned out to be firewall related. Specifically, when unbound starts up it tries to update the root anchor in /var/lib/unbound/root.key. When I tried to do this manually running unbound-anchor -a "/var/lib/unbound/root.key"the DNS requests to the root servers were being blocked on one of my unbound servers but not the other one. On the blocked server, the unbound-anchor command took over a minute to return and the root.key file was not updated.

DNS resolution seemed fine because /etc/resolv.conf was pointing to a recursive resolver that was working but requests from the unbound IP address were being blocked.

You can try starting unbound using /usr/sbin/unbound -d -vvvv and checking /var/log/messages. If you are having DNS problems you will see multiple attempts to query the root servers and sendto failed errors.

Aner
  • 591
  • 5
  • 3
  • Yes you are correct. It was a network issue. – Subzero123 Aug 28 '19 at 18:46
  • A prerequisite to running unbound is having network access to the root nameservers on UDP 53. I am not exactly sure which root nameservers unbound tries first, I think there is some randomness in there. It is best if Unbound has access to the entire Internet on UDP 53. TCP 53 is also nice to have. Additionally, I don't remember whether Unbound comes with root hints by default. I think it has them built in inside. Regardless, one should also download the file (https://www.internic.net/domain/named.root) and make the configuration point to it. Comments may only be edited for 5 mins sigh.. – Subzero123 Aug 28 '19 at 18:52
0

In my case, the tcp53 port on the firewall was closed.