DNS not resolved

some of our websites do not any longer resolve DNS requests. nauers.ch for example. Whereas gim3.ch hosted on the same server, works fine. All the domains, where we modified the DNS entry affected by this trouble. We have restored a backup of nauers.ch from a day where that problem not appeared. This DNS behaviour remains. Something within Virtualmin must have messed up is our conclusion, but we do not know where to find it.

-Tobias-

Status: 
Active

Comments

also apt-get update comes up with all unresolved host names, like security.debian.org the NIC hardware is ok and the /etc/host and etc/hostname files seems to be allright to. also the /etc/resolv.conf file have all working name server

where to find this problem?

There's two things I'd suggest.

I see in your forum post here that you have multiple DNS servers acting as nameservers:

https://virtualmin.com/node/20853

(sorry, I would have responded there yesterday but somehow managed to miss the notification of your reply)

So to fix the issue with your primary server -- I'd suggest going into Webmin -> Servers -> BIND DNS Server -> Addresses and Topology, what are the IP addresses listed in the "Addresses" field? You'd want to make sure all of your system's IP addresses are listed there (each separated by a space).

Second -- if your server is intermittantly not resolving DNS queries, that does imply some kind of DNS problem with the nameservers listed in /etc/resolv.conf.

My suggestion would be to comment out all the nameservers except for the entry containing "nameserver 127.0.0.1", as that's the only one you really need.

we adjusted accordingly, at least the server itself finds again the way out with apt-get update but guess the problem with some of the domains remains, where other domains on the same server work find and do not have this problem,

http://www.dnssy.com/report.php?q=nauers.ch

says at the very end: None of your nameservers returned an SOA record for your domain. This is very bad. Skipping SOA tests.

we do not understand why the records of this domain can not any longer be read correctly, where else on the same server other domains, can be correctly given DNS entry's.

Well, before you try to solve problems such as SOA records -- I'd recommend working out why some of your nameservers aren't responding.

When using a site such as intodns.com to check your DNS settings, it's unable to reach 3 of your nameservers:

  • 208.79.241.3

  • 88.198.54.176

  • 208.79.240.3

So long as even one nameserver listed for your domain doesn't respond, you could have serious problems in trying to access your domain.

What we'd need to figure out then is where are those 3 IP addresses, and why isn't BIND responding on them?

Are those 3 IP's on your primary server? If not, are they all setup and controlled by you?

the main DNS is 88.198.54.176 the other two are secondary DNS, hosted by rollernet.us they all controlled by us. Since we added these rollernet DNS seconday server, our main DNS server 88.198.54.176 does not respond to these domains with DNS request, we have added the rollernet.us entry's

even if we take out the rollernet.us entry's, still these domains do not respond to DNS requests. we could restore a older BIND configuration, but we are afraid that the domains still responding to DNS may also be messed up and maybe stop responding.

any information we gladly to provide on this issue

On your primary server -- the issue is likely either that BIND isn't listening on the IP 88.198.54.176, or the BIND port is being blocked by a firewall.

What is the output of these two commands:

iptables -L -n
netstat -an | grep :53
iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination        
fail2ban-postfix  tcp  --  0.0.0.0/0      0.0.0.0/0    multiport dports 25,465

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        

Chain fail2ban-postfix (1 references)
target     prot opt source               destination        
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

could it be that port 53 UDP does not listen, that could be the cause for it.

netstat -an | grep :53
tcp        0      0 88.198.54.176:53        0.0.0.0:*               LISTEN    
tcp6       0      0 :::53                   :::*                    LISTEN    
udp        0      0 88.198.54.176:58267     213.133.98.98:53        ESTABLISHED
udp        0      0 88.198.54.176:44725     213.133.98.98:53        ESTABLISHED
udp        0      0 88.198.54.176:53        0.0.0.0:*                         
udp6       0      0 :::53                   :::*   

That actually all looks good -- UDP connections don't show the text "LISTEN" next to it.

Are you sure that there's nothing in front of your server blocking connections to UDP port 53?

Also, what output do you get if you run this command on your server:

dig a nauers.ch @88.198.54.176

Lastly, can you verify that in "Edit Virtual Server" for the domain "nauers.ch", that the "BIND DNS Domain" feature is enabled?

> dig a nauers.ch @88.198.54.176

; <<>> DiG 9.7.3 <<>> a nauers.ch @88.198.54.176
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64773
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;nauers.ch. IN A

;; Query time: 0 msec
;; SERVER: 88.198.54.176#53(88.198.54.176)
;; WHEN: Fri Jan 20 10:12:13 2012
;; MSG SIZE  rcvd: 27

YES... "BIND DNS Domain" feature is enabled, and we have reset the firewall to Blocking all except ports for virtual hosting on interface eth0:

> iptables -L -n
Chain INPUT (policy DROP)
target     prot opt source               destination        
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x10/0x10
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp spt:53 dpts:1024:65535
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 0
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 3
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 4
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 11
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 12
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:113
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 8
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:53
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:53
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp multiport dports 25,587
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpts:20:21
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp multiport dports 110,995
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp multiport dports 143,220,993
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpts:10000:10010
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:20000

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        

netstat looks like this:

> netstat -an | grep :53
tcp        0      0 88.198.54.176:53        0.0.0.0:*               LISTEN    
udp        0      0 88.198.54.176:53        0.0.0.0:*                     

It seems that the problem is that, for both nauers.ch and gim3.ch, your primary DNS server isn't responding to DNS queries for either of those domains.

It appears as if BIND is there and listening, it's almost as if it doesn't know anything about those domains. Which might mean there's a config file problem of some sort.

I'm somewhat stuck as to what exactly the problem might be though, or where to tell you to look, outside of posting all your BIND related config files.

What might be simpler than that would be if I could log in over SSH and take a look.

Would that be possible?

If so, could you either email your root login details to eric@virtualmin.com, or enable Remote Support using the Virtualmin Support module? Thanks!

I looked at your system, and noticed a few issues with the DNS setup.

First, there's multiple nameservers listed in /etc/resolv.conf -- and on at least on occasion, I had a problem with querying them.

I'd recommend only using the "nameserver 127.0.0.1" line, and I commented the other ones out.

Second, in /etc/bind/named.conf.options, there was a blank "allow-query" line, which essentially blocked all requests for DNS lookups. I commented that line out.

Lastly, the "listen-on" line only specified your public IP, it didn't list "127.0.0.1" (localhost). That would prevent local DNS lookups from working. I added that entry for localhost.

After making those changes -- I'm able to perform DNS lookups from your server, and your primary server is now able to resolve nauers.ch and gim3.ch.

Great job Andre many thanks so far everything works again. Must have played to much around with DNS, should be more careful on a live system.

regards Tobias