Nameservers - mismatched NS records / nameservers not responding

Hi there,

When running a test with intodns.com I am seeing errors with the nameservers. The errors that i see are:

-- Mismatched NS records WARNING: One or more of your nameservers did not return any of your NS records.
-- DNS servers responded    ERROR: One or more of your nameservers did not respond: The ones that did not respond are: 98.142.218.110
-- Missing nameservers reported by your nameservers You should already know that your NS records at your nameservers are missing, so here it is again: 
ns1.dealbent.net. 
ns2.dealbent.net. 

( The full report can be seen here: http://www.intodns.com/dealbent.net )

So, i am a little confused on why these errors would be reported.. I have A records set up and the host ip's have been set at the registrar for weeks now. Am i missing something obvious here? Thanks!

scott

Status: 
Active

Comments

My analysis: The IP address "98.142.218.110" is not responding to DNS requests.

First a hint. That IP is configured for both ns1 and ns2 at your domain. That is - while possible for some TLDs - bad practice, since it defeats the purpose of nameserver redundancy. For example, for .de domains you must have at least two nameservers which must reside in different /24 networks.

The IP address is not replying to PING or TRACEROUTE either. Is the IP correct?

If yes, make sure that BIND is running on the machine and listening on UDP port 53 on the external IP. You can find that out like this:

root@australis:~# netstat -upln | grep 53
udp        0      0 176.9.191.26:53         0.0.0.0:*                           1075/named
udp        0      0 127.0.0.1:53            0.0.0.0:*                           1075/named
root@australis:~# ps aux | grep named
bind      1075  0.0  1.4 259224 21956 ?        Ssl  Nov01   3:20 /usr/sbin/named -u bind -4

Thanks for the reply - I am aware of the ns1 / 2 being on the same IP - i plan to have a second server soon to be the second, last time i attempted this (with virtualmin) i ran into issues and never got back to it. However, that ip as well as the other private ip's all seem to be listening. Any other ideas? Thank you!

[root@host ~]# netstat -upln | grep 53
udp        0      0 98.142.218.52:53            0.0.0.0:*                                            7326/named
udp        0      0 98.142.218.60:53            0.0.0.0:*                                            7326/named
udp        0      0 98.142.218.21:53            0.0.0.0:*                                            7326/named
udp        0      0 98.142.218.51:53            0.0.0.0:*                                            7326/named
udp        0      0 98.142.218.62:53            0.0.0.0:*                                            7326/named
udp        0      0 98.142.218.22:53            0.0.0.0:*                                            7326/named
udp        0      0 98.142.218.24:53            0.0.0.0:*                                            7326/named
udp        0      0 98.142.218.65:53            0.0.0.0:*                                            7326/named
udp        0      0 98.142.218.61:53            0.0.0.0:*                                            7326/named
udp        0      0 98.142.218.50:53            0.0.0.0:*                                            7326/named
udp        0      0 98.142.218.23:53            0.0.0.0:*                                            7326/named
udp        0      0 98.142.218.110:53           0.0.0.0:*                                            7326/named
udp        0      0 127.0.0.1:53                0.0.0.0:*                                            7326/named
udp        0      0 :::53                       :::*                                                 7326/named
[root@host ~]# ps aux | grep named
root      6493  0.0  0.0 103236   880 pts/0    S+   11:26   0:00 grep named
named     7326  0.0  0.5 751772 86000 ?        Ssl  01:21   0:08 /usr/sbin/named              -u named
[root@host ~]#

Update - this may in-fact be a bug. I started looking around and in /etc/named.conf the records are showing the OLD servers primary IP address, not the new servers IP. I am going to edit this ip on all lines and see if that corrects it, but i think there is something else i am missing? Thanks

Yep, BIND seems to be listening A-okay.

Since also ping and traceroute don't reach the IPs, it is possible that some firewall is blocking access. Do you know of any firewall operated by your hoster?

Otherwise, you can query the status of a locally installed firewall in most Linux distributions using iptables -L -n. You might want to post its output here if you have trouble interpreting it. :)

I'm attaching the output of a traceroute below, maybe the last hop can tell you if the route stops right before your server, or along the way in your hoster's network.

                                                  Packets               Pings
 Host                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. pandora.tianet.de                            0.0%    13    0.2   0.2   0.1   0.3   0.0
 2. static.161.114.9.176.clients.your-server.de  0.0%    13    0.9   2.0   0.9   5.0   1.4
 3. hos-tr4-juniper2.rz15.hetzner.de             0.0%    13    1.5   0.5   0.3   1.5   0.3
 4. hos-bb1.juniper1.ffm.hetzner.de              0.0%    13    5.0   5.0   4.9   5.1   0.1
 5. r1fra1.core.init7.net                        0.0%    13    5.2   8.0   5.0  14.9   4.0
 6. xe-1-2-0.mpr1.fra4.de.above.net              0.0%    13    6.8  10.7   6.1  35.2  10.2
 7. xe-0-1-0.mpr2.cdg12.fr.above.net             0.0%    13   15.3  19.3  14.7  69.3  15.0
 8. ge-0-2-0.mpr1.lhr2.uk.above.net              0.0%    13   19.7  21.8  19.3  37.3   5.0
 9. xe-5-2-0.cr1.dca2.us.above.net               0.0%    13   92.6  93.4  92.2 104.3   3.3
10. xe-1-1-0.mpr4.atl6.us.above.net              0.0%    13  155.5 109.9 104.8 155.5  14.0
11. xe-0-0-0.mpr3.atl6.us.above.net              0.0%    13  105.2 107.5 104.9 136.6   8.7
12. 64.124.202.214.t00623-01.above.net           0.0%    13  108.7 110.2 108.7 124.6   4.3
13. ge1-2.6509-aa.34.coloat.com                  0.0%    13  110.3 110.1 109.8 110.6   0.2
14. ???

Where exactly in your named.conf did you find the wrong IP address? Since BIND seems to be listening okay on the IP that your domain registrar reports, and also pings don't reach that IP, there's probably something else wrong.

Is "98.142.218.110" the correct IP?

Hmmm.. No firewall other than my own which isn't blocking anything i am aware of... the tracert appears to stop right before my FW. I will double-check but there are no blocking rules except for IP's outside the USA.

The named.conf file had these for each: (the .110 ip was the old, i changed them all)

zone "fitmedwellness.com" {
        type master;
        file "/var/named/fitmedwellness.com.hosts";
        allow-transfer {
                127.0.0.1;
                localnets;
                98.142.218.110;
                };

"98.142.218.110" is the correct IP. I can ping the ip from my pc in starbucks now too...

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
 
C:\Users\Scott Kappler>ping 98.142.218.110
 
Pinging 98.142.218.110 with 32 bytes of data:
Reply from 98.142.218.110: bytes=32 time=13ms TTL=53
Reply from 98.142.218.110: bytes=32 time=12ms TTL=53
Reply from 98.142.218.110: bytes=32 time=17ms TTL=53
Reply from 98.142.218.110: bytes=32 time=11ms TTL=53
 
Ping statistics for 98.142.218.110:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 11ms, Maximum = 17ms, Average = 13ms

This is strange... I am at a loss.. Thanks a lot...

The contents of your named.conf, here the allow-transfer directive, has no influence on the issue you're seeing at the moment.

I will double-check but there are no blocking rules except for IP's outside the USA.

Well, I am outside the USA (as are my root servers). ;) You might want to check if you're blocking e.g. my server's IP 176.9.191.26 or my home one 87.79.76.199, both of which cannot ping your IP.

Yes you were blocked..

Nov 20 12:34:37 WAN 87.79.76.199 98.142.218.110 ICMP Nov 20 12:32:49 WAN 87.79.76.199 98.142.218.110 ICMP

I am wondering if there is an issue with the accuracy of intodns.com now -

I tried a test from here: http://www.webdnstools.com/dnstools/chk-domain and do not get the same errors...

General Name Server Tests
Test    Detail  Result
Name Servers Exist  Received answer from ns2.dealbent.net
The name servers for this domain are:
  ns2.dealbent.net
  ns1.dealbent.net  Pass
Name Server Count   You have 2 name servers.    Pass
Name Server Glue    Server also returned 'glue' records:
  98.142.218.110 [US] (ns1.dealbent.net)
  98.142.218.110 [US] (ns2.dealbent.net)    Pass
Name Server Location    All name servers resolve to the same IP address. This means that all of your name servers point to the same server. If this server was to fail, your domain would not be accessible. You should have a minimum of two name servers. Warn
Name Server Authority   Checking name server authority: 
All name servers answered authoritatively.  Pass
SOA Record  Checking SOA serial number on authoritative name servers: 
  ns2.dealbent.net has serial number 1352503743 
  ns1.dealbent.net has serial number 1352503743 
All authoritative name servers return the same serial numbers.  Pass
Use Name Server Using name server "ns1.dealbent.net" for remainder of tests. To re-run the following tests with a different name server, click on the name server in the list below:
  ns2.dealbent.net 
  ns1.dealbent.net  Info
Specific Name Server Tests (using ns1.dealbent.net)
Test    Detail  Result
SOA Record  Checking SOA on name server: 
  Serial: 1352503743
  Refresh: 10800 seconds
  Retry: 3600 seconds
  Expire: 604800 seconds
  Minimum (default) TTL: 38400 seconds
  Primary name server: ns1.dealbent.net
  Contact: root@ns1.dealbent.net    Info
SOA Serial Number   The SOA serial number appears not to conform to RFC1912, which recommends that the serial number should be in YYYYMMDDnn format. Some systems use the Unix timestamp for the serial number. Warn
DNS Contact Checking DNS contact email address is valid. 
root@ns1.dealbent.net seems to be valid.    Pass
DNS Master Name Your SOA record lists ns1.dealbent.net as the Primary nameserver. This server is listed as a valid nameserver at the parent servers, which is correct.  Pass
Check Missing NS Records 1  All nameservers listed on the parent servers are listed on this nameserver, which is correct.   Pass
Check Missing NS Records 2  All nameservers listed on this nameserver are also listed on the parent servers, which is correct.  Pass
Glue Record Consistency No inconsistencies were found between the glue records on the parent servers and the glue records on this nameserver.   Pass
A Record    The 1 A record for dealbent.net:
  98.142.218.110 [US]   Pass
www A Record    The 1 A record for www.dealbent.net:
  98.142.218.110 [US]   Info
MX Record   MX Records:
  5 mail.dealbent.net. [98.142.218.110] Info
SPF Record  An SPF record was found. Providing the data contained in this record is correct, this will help prevent your mail getting flagged as spam.
SPF Record:
  (TXT) "v=spf1 a mx a:dealbent.net ip4:98.142.218.110 include:spf.mailjet.com -all"  Pass
Check Mail Server Greeting  The mail server greeting is 'host.wellcorprx.com ESMTP Postfix '.   Pass
Check Postmaster Mailbox    The mail server for dealbent.net does NOT accept mail for mailbox 'postmaster@dealbent.net'. Mail server returned 'no such user'.   Fail
Check Abuse Mailbox The mail server for dealbent.net accepts mail for mailbox 'abuse@dealbent.net'. Pass

What do you think?

Well if your firewall blocked me, it's very likely it's also blocking IntoDNS during its test, considering it reported your nameserver as unreachable. :) I personally found IntoDNS to be quite reliable.

So before doing any further steps, you should probably remove any source IP block rules from your firewall and try IntoDNS again.

Thanks - feel like a chicken chasing my own tail.. :) Sorry for the trouble... I will let you know if it persists after..