DNS Lookup Issues

Community Support
1

My config is having two Hestia servers, the primary with web/email/dns/etc and the secondary as a slave dns server.

(to the best of my recollection…) Last night, I made an edit to a dns entry to change the TTL from 1 hour to 5 minutes (I’m anticipating possibly changing this IP frequently). Shortly afterwards, I started getting these emails:

v-change-remote-dns-domain-exp 
Error: api connection to dnspanel.mysite.com failed.

Remote dns host has been suspended.After resolving issue run following commands:

v-unsuspend-remote-dns-host dnspanel.mysite.com
v-sync-dns-cluster dnspanel.mysite.com


--
Hestia Control Panel
controlpanel.mysite.com

and

v-add-remote-dns-domain 
Error: api connection to dnspanel.mysite.com failed.

Remote dns host has been suspended.After resolving issue run following commands:

v-unsuspend-remote-dns-host dnspanel.mysite.com
v-sync-dns-cluster dnspanel.mysite.com


--
Hestia Control Panel
controlpanel.mysite.com

(I’m guessing this is unrelated, but on the off chance it isn’t, I’m including it here) Around the same time, I started having trouble accessing my control panel and found that my IP was getting added to the ban list, so I just removed it from a secondary connection and was able to connect again. This happened a couple more times.

My troubleshooting has since revealed that I can connect to the server from the internet, its services are running (I can access websites on it, get dns responses from it, mail works, etc) and it can connect outgoing connections, but only via IP. Obviously, this would indicate that the name servers aren’t set, so I checked that…

Except they are set. So I ran dig google.com @8.8.8.8 and it timed out. I did the same with tcpdump -n -I en1 host 8.8.8.8 on another terminal and got this back:

root@controlpanel:/home/mredig/.ssh# tcpdump -n -i en1 host 8.8.8.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 262144 bytes
13:36:09.538555 IP my.ip.add.res.60270 > 8.8.8.8.53: 56747+ [1au] A? google.com. (51)
13:36:09.549974 IP 8.8.8.8.53 > my.ip.add.res.60270: 56747 1/0/1 A 216.58.192.206 (55)
13:36:14.356322 IP my.ip.add.res.59877 > 8.8.8.8.53: 3504+ [1au] A? google.com. (51)
13:36:14.357991 IP 8.8.8.8.53 > my.ip.add.res.59877: 3504 1/0/1 A 216.58.192.238 (55)

Here’s the dig output:

root@controlpanel:/etc/netplan# dig google.com @8.8.8.8

; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> google.com @8.8.8.8
;; global options: +cmd
;; connection timed out; no servers could be reached

I’m not very familiar with tcpdump, but it appears to me that they are communicating just fine. Anyone have any ideas?

2

Had the same issue until I replaced the hostname with ip.

3

Replaced it where?

4

v-add-dns-remote-host ip port admin password

5

That seems like a good bandaid, but the underlying issue is that the whole server cannot resolve dns queries. That also means that it will not be able to update itself (that’s a security vulnerability) nor will it be able to manage some sites like Wordpress (which commonly make external requests to download resources).

6

Don’t get why it should be a security issue.

I’m using hestia as dns cluster for my domains, aswell as dns lookup for my own network (allowing my subnets to also lookup non local domains). I can’t find any issues.

It basicly sounds like your slave was suspended due to connection issues, maybe based do a local resolution issue. Start to verify that your dns settings are properly, you still can follow @eris guide to add the slave as ip, but this shouldnt be needed. Resolve your dns issues and unsuspend the dns server (v-unsuspend-remote-dns-host and run a v-sync-dns-cluster).

7

The security issue is that, because the server cannot resolve outgoing dns requests, it cannot run things like apt-get upgrade.

8

That’s what I’ve been trying to do, but like I said, I CAN make outgoing connections, I can even ping dns servers like 8.8.8.8 and 1.1.1.1, but when I run dig, even specifically targeting said dns servers (dig google.com @8.8.8.8), it fails. (I should add that ping google.com also fails, but that makes sense if it cannot otherwise resolve dns)

9

Hestia doesnt change anything that could explain a such deep issue. Basic question, does a nslookup google.com 8.8.8.8 works?

10 
root@controlpanel:/etc/netplan# nslookup google.com 8.8.8.8
;; connection timed out; no servers could be reached

root@controlpanel:/etc/netplan#

Hestia doesnt change anything that could explain a such deep issue.

I kinda suspected that, but since Hestia is the only thing I’ve installed on the server and, to the best of my recollection is the only thing that I modified prior to experiencing this issue, I figured it would be worth checking here. The help so far is appreciated though. :smile:

11

The server seems to drop incomming packets, can you stop the firewall and retry a dns resolve?
v-stop-firewall (or somenething similar)

1 Like
12

That’s a good suggestion. I’ll look into it and report back.

13

is your server happen to have multiple network interfaces?

14

Nope! Just the one.

15

is 8.8.8.8 the only ns-server configured for that server? add a 2nd/3rd - non google maybe?

16

Doing that made it work!

I’m confused tho, because I cannot find a counterpart to v-stop-firewall (like start-firewall or anything), but it also appears to be actually applying my firewall settings instead of being “stopped”. (I toggled ICMP in the web GUI between block and allow while pinging from my laptop and the pings started and stopped accordingly). The documentation for stopping also states that

The function stops iptables

Does Hestia not use iptables behind the scenes?

17

Just so this doesn’t go unaddressed, I have 3 name servers on this server: 1.1.1.1, 1.0.0.1, and one provided by dhcp that I’d prefer to ignore, but it hasn’t cause any issues so far so I’ve been lazy. /shrug

18

v-update-firewall will re-populate the iptables rules

Yes, Hestia uses iptables

19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.