Submitted by virtualmin108 on Thu, 01/19/2012 - 02:33
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
Submitted by virtualmin108 on Thu, 01/19/2012 - 07:26 Comment #1
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?
Submitted by virtualmin108 on Thu, 01/19/2012 - 07:27 Comment #2
Submitted by andreychek on Thu, 01/19/2012 - 09:04 Comment #3
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.
Submitted by virtualmin108 on Thu, 01/19/2012 - 11:48 Comment #4
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.
Submitted by andreychek on Thu, 01/19/2012 - 12:00 Comment #5
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?
Submitted by virtualmin108 on Thu, 01/19/2012 - 12:28 Comment #6
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
Submitted by andreychek on Thu, 01/19/2012 - 22:15 Comment #7
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
Submitted by virtualmin108 on Thu, 01/19/2012 - 23:40 Comment #8
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 :::*
Submitted by andreychek on Thu, 01/19/2012 - 23:55 Comment #9
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?
Submitted by virtualmin108 on Fri, 01/20/2012 - 03:20 Comment #10
> 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:*
Submitted by andreychek on Fri, 01/20/2012 - 08:19 Comment #11
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!
Submitted by andreychek on Fri, 01/20/2012 - 11:04 Comment #12
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.
Submitted by virtualmin108 on Fri, 01/20/2012 - 16:02 Comment #13
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