[SOLVED] Weird DNS issue with specific domain

gunhed · 07-19-2013, 11:16 AM

I'm having a weird problem trying to resolve a specific domain (ptsi.net) to send email to it, but other domains I look up (and send email to) seem to resolve OK (i.e. yahoo.com, etc.). I thought it might be a DNS propagation issue, but when I checked it using some external sites (http://www.whatsmydns.net/ and http://www.viewdns.info/propagation/), there seems to be no problem.

My server is set up as a caching DNS server, and it resolves names by going to the root servers. It's been in place for several years now and has had no problems.

Here's what I get when attempting to resolve psti.net:

Code:

$ host ptsi.net
ptsi.net has address 65.79.193.93
Host ptsi.net not found: 2(SERVFAIL)

As you see, it does provide me with an IP address, which appears to be correct, but right after, it reports failure. If I attempt to get the MX record for that domain, it fails outright:

Code:

$ host -t mx ptsi.net
Host ptsi.net not found: 2(SERVFAIL)

Despite this, I can ping it:

Code:

$ ping ptsi.net
PING ptsi.net (65.79.193.93) 56(84) bytes of data.
64 bytes from www.ptci.net (65.79.193.93): icmp_seq=1 ttl=49 time=50.8 ms
64 bytes from www.ptci.net (65.79.193.93): icmp_seq=2 ttl=49 time=54.5 ms
64 bytes from www.ptci.net (65.79.193.93): icmp_seq=3 ttl=49 time=57.1 ms

Reverse lookup reports what looks like a web site hostname:

Code:

$ host 65.79.193.93
93.193.79.65.in-addr.arpa domain name pointer www.ptci.net.

and likewise, I can resolve that www hostname just fine:

Code:

$ host www.ptsi.net
www.ptsi.net has address 65.79.193.93

Now, when I edit my /etc/resolv.conf to add an external nameserver, everything seems to work as expected:

resolv.conf:

Code:

nameserver 127.0.0.1
nameserver 12.127.16.67

Code:

$ host ptsi.net
ptsi.net has address 65.79.193.93
ptsi.net mail is handled by 30 aspmx2.googlemail.com.
ptsi.net mail is handled by 30 aspmx3.googlemail.com.
ptsi.net mail is handled by 10 aspmx.l.google.com.
ptsi.net mail is handled by 20 alt1.aspmx.l.google.com.
ptsi.net mail is handled by 20 alt2.aspmx.l.google.com.

Code:

$ host -t mx ptsi.net
ptsi.net mail is handled by 30 aspmx3.googlemail.com.
ptsi.net mail is handled by 10 aspmx.l.google.com.
ptsi.net mail is handled by 20 alt1.aspmx.l.google.com.
ptsi.net mail is handled by 20 alt2.aspmx.l.google.com.
ptsi.net mail is handled by 30 aspmx2.googlemail.com.

Likewise, if I ask an outside DNS server to get the MX record, it seems fine:

Code:

$ host -t mx ptsi.net 68.105.29.16
Using domain server:
Name: 68.105.29.16
Address: 68.105.29.16#53
Aliases: 

ptsi.net mail is handled by 30 aspmx3.googlemail.com.
ptsi.net mail is handled by 10 aspmx.l.google.com.
ptsi.net mail is handled by 20 alt1.aspmx.l.google.com.
ptsi.net mail is handled by 20 alt2.aspmx.l.google.com.
ptsi.net mail is handled by 30 aspmx2.googlemail.com.

So, as you can see, other DNS servers have no problems - why can't mine do the same? I can't rely on an external DNS server in my resolv.conf; my server needs to be able to stand on its own. Any ideas on what could be the issue here? Is it my server or their DNS record that's the problem?

Z038 · 07-19-2013, 12:35 PM

I don't think there is a problem with their DNS. It looks fine from here. I am running my own DNS server (BIND) also, and everything is resolving correctly for me.

What DNS server are you running?

gunhed · 07-19-2013, 12:40 PM

I'm running CentOS 6.2 with bind-9.7.3-8.P3.el6_2.2.x86_64.

Z038 · 07-19-2013, 03:08 PM

I'm running bind 9.9.2 P2. Can you post your named.conf file? Also, is your root.hints file current? You can download a new one with this command: dig @a.root-servers.net . ns >root.hints.new 2> errors

bathory · 07-19-2013, 03:45 PM

@OP
Looks like a networking problem. Perhaps some flaky router or a firewall dropping big udp packets
You can add

Code:

server 0.0.0.0 {
edns no;
};

in named.conf and see if it solves your problem.

gunhed · 07-19-2013, 03:49 PM

Quote:

Originally Posted by Z038

I'm running bind 9.9.2 P2. Can you post your named.conf file? Also, is your root.hints file current? You can download a new one with this command: dig @a.root-servers.net . ns >root.hints.new 2> errors

OK - I've updated my hints file using dig (didn't know this went out of date; I'm a noob when it comes to DNS) and restarted the service, but I still get the same problem resolving ptsi.net. I've posted my config file below.

named.conf:

Code:

// zone transfers
acl "xfer" { 
   127.0.0.1/32;
   192.168.240.0/24;
   192.168.241.0/24;
}; 

// Place our internal and DMZ subnets in here so that 
// intranet and DMZ clients may send DNS queries.  This 
// also prevents outside hosts from using our name server 
// as a resolver for other domains. 
acl "trusted" { 
   127.0.0.1/32; 
   192.168.240.0/24;
   192.168.241.0/24;
}; 

logging {

   channel "default_syslog" { 
      syslog local5; 
      severity warning; 
      print-time yes;      
      print-severity  yes;
      print-category yes;
   };

   channel "audit_log" { 
      // Send the security related messages to a separate file. 
      file "/var/log/named.log"; 
      severity warning; 
      print-time yes; 
      print-severity  yes;
      print-category yes;
   };

   category default { default_syslog; };
   category general { default_syslog; };
   category config { default_syslog; };
   category security { audit_log; default_syslog; };
   category resolver { audit_log; };
   category xfer-in { audit_log; };
   category xfer-out { audit_log; };
   category notify { audit_log; };
   category client { audit_log; };
   category network { audit_log; };
   category update { audit_log; };
   category queries { audit_log; };
   category lame-servers { audit_log; };
}; 

options {
   listen-on-v6 { none; };
   version "DNS Server";
   directory "/var/named"; 
   pid-file "/var/run/named/named.pid"; 
   statistics-file "/var/named/data/named_stats.txt"; 
   dump-file "/var/named/data/cache_dump.db"; 
   memstatistics-file "/var/named/data/named_mem_stats.txt";
   zone-statistics yes; 
   querylog true;

   //dnssec-enable yes;
   dnssec-enable no;
   dnssec-validation yes;
   dnssec-lookaside auto;

   /* Path to ISC DLV key */
   bindkeys-file "/etc/named.iscdlv.key";

   // If your DNS server is behind a firewall which blocks (E)DNS
   // packets larger than 512 bytes, you need to change your
   // firewall settings before you configure these keys.
   edns-udp-size 512;
   
   // Previous versions of BIND always asked
   // questions using port 53, but BIND 8.1 uses an unprivileged
   // port by default.
//   query-source address * port 53;

   // Prevent DoS attacks by generating bogus zone transfer 
   // requests.  This will result in slower updates to the 
   // slave servers (e.g. they will await the poll interval 
   // before checking for updates). 
   notify no; 

   // Generate more efficient zone transfers.  This will place 
   // multiple DNS records in a DNS message, instead of one per 
   // DNS message. 
   transfer-format many-answers; 

   // Set the maximum zone transfer time to something more 
   // reasonable.  In this case, we state that any zone transfer 
   // that takes longer than 60 minutes is unlikely to ever 
   // complete.  WARNING:  If you have very large zone files, 
   // adjust this to fit your requirements. 
   max-transfer-time-in 60; 

   // We have no dynamic interfaces, so BIND shouldn't need to 
   // poll for interface state {UP|DOWN}. 
   interface-interval 0; 

   allow-transfer { xfer; };

   // Accept queries from our "trusted" ACL.  We will 
   // allow anyone to query our master zones below. 
   // This prevents us from becoming a free DNS server 
   // to the masses. 
   allow-query { trusted; };

};

view "internal" {
   // Our internal (trusted) view. We permit the internal networks 
   // to freely access this view. We perform recursion for our 
   // internal hosts, and retrieve data from the cache for them.

   match-clients { trusted; }; 
   recursion yes; 

   zone "." in {
      type hint;
      file "named.ca";
   };

   // our jplush private network zone
   zone "jplush.local" IN {
      type master;
      file "jplush.local.zone";
      allow-update { none; };
   };

   // our jplush public network zone
   zone "jplush.com" IN {
      type master;
      file "jplush.com.zone";
      allow-update { none; };
   };

   // reverse lookup for the jplush private network
   zone "241.168.192.in-addr.arpa" IN {
      type master;
      file "241.168.192.in-addr.arpa";
      allow-update { none; };
   };


   // reverse lookup for the jplush internet proxy network
   zone "240.168.192.in-addr.arpa" IN {
      type master;
      file "240.168.192.in-addr.arpa";
      allow-update { none; };
   };

   include "/etc/named.rfc1912.zones";
   include "/etc/rndc.key";
   
};

gunhed · 07-19-2013, 04:05 PM

Quote:

Originally Posted by bathory

@OP
Looks like a networking problem. Perhaps some flaky router or a firewall dropping big udp packets
You can add

Code:

server 0.0.0.0 {
edns no;
};

in named.conf and see if it solves your problem.

Every other domain I check can resolve just fine, so I don't think it's a networking issue. I'm only having trouble with the one domain (as far as I know).

bathory · 07-19-2013, 04:24 PM

Quote:

Originally Posted by gunhed

Every other domain I check can resolve just fine, so I don't think it's a networking issue. I'm only having trouble with the one domain (as far as I know).

Why don't you try it, to see if that's the case. The problem is more likely with the big udp packets (bigger than 5112 bytes) that are dropped somehow.
Anyway, if you feel uncomfortable editing named.conf you can use:

Code:

dig mx ptsi.net +noedns +bufsize=0

and see if you get an answer by disabling edns

gunhed · 07-19-2013, 04:44 PM

Quote:

Originally Posted by bathory

Why don't you try it, to see if that's the case. The problem is more likely with the big udp packets (bigger than 5112 bytes) that are dropped somehow.
Anyway, if you feel uncomfortable editing named.conf you can use:

Code:

dig mx ptsi.net +noedns +bufsize=0

and see if you get an answer by disabling edns

I tried the configuration change you suggested, but it seemed to make no difference. Thank you for suggesting the potential solution.

bathory · 07-20-2013, 02:58 AM

Quote:

Originally Posted by gunhed

I tried the configuration change you suggested, but it seemed to make no difference. Thank you for suggesting the potential solution.

Sorry to hear that. I was quite sure that that was the case, as the domain is resolved at a first place, but you can't get the extra data.
Anyway try the following and see what you get:

Code:

dig mx ptsi.net +tcp

gunhed · 07-20-2013, 11:31 AM

Still no joy. Here's what I got:

Code:

$ dig mx ptsi.net +tcp

; <<>> DiG 9.7.3-P3-RedHat-9.7.3-8.P3.el6_2.2 <<>> mx ptsi.net +tcp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45471
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ptsi.net.                      IN      MX

;; Query time: 104 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jul 20 11:15:53 2013
;; MSG SIZE  rcvd: 26

bathory · 07-21-2013, 03:12 AM

Does your dns server has any relation with the domain in question?
Anyway since I'm out of ideas, you can investigate further if you want, using tcpdump. There is also a good tutorial about tracking SERVFAIL errors, that could be of help.

Regards

gunhed · 07-22-2013, 08:28 AM

My server has no relationship whatsoever with the domain giving me problems. I've been following the troubleshooting guide posted above (thank you), and found some weird behavior. When I turn off recursion to look up the offending site, I get nothing back:

Code:

$ host -r ptsi.net
$

And when I additionally turn on verbosity, I get a lot of this, but I don't know how to interpret it:

Code:

$ host -r -v ptsi.net
Trying "ptsi.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29872
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;ptsi.net.                      IN      A

;; AUTHORITY SECTION:
net.                    147279  IN      NS      d.gtld-servers.net.
net.                    147279  IN      NS      h.gtld-servers.net.
net.                    147279  IN      NS      l.gtld-servers.net.
net.                    147279  IN      NS      b.gtld-servers.net.
net.                    147279  IN      NS      e.gtld-servers.net.
net.                    147279  IN      NS      a.gtld-servers.net.
net.                    147279  IN      NS      j.gtld-servers.net.
net.                    147279  IN      NS      f.gtld-servers.net.
net.                    147279  IN      NS      m.gtld-servers.net.
net.                    147279  IN      NS      c.gtld-servers.net.
net.                    147279  IN      NS      k.gtld-servers.net.
net.                    147279  IN      NS      i.gtld-servers.net.
net.                    147279  IN      NS      g.gtld-servers.net.

Received 247 bytes from 127.0.0.1#53 in 0 ms
Trying "ptsi.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5472
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;ptsi.net.                      IN      AAAA

;; AUTHORITY SECTION:
net.                    147279  IN      NS      b.gtld-servers.net.
net.                    147279  IN      NS      l.gtld-servers.net.
net.                    147279  IN      NS      e.gtld-servers.net.
net.                    147279  IN      NS      m.gtld-servers.net.
net.                    147279  IN      NS      h.gtld-servers.net.
net.                    147279  IN      NS      a.gtld-servers.net.
net.                    147279  IN      NS      d.gtld-servers.net.
net.                    147279  IN      NS      j.gtld-servers.net.
net.                    147279  IN      NS      k.gtld-servers.net.
net.                    147279  IN      NS      g.gtld-servers.net.
net.                    147279  IN      NS      f.gtld-servers.net.
net.                    147279  IN      NS      i.gtld-servers.net.
net.                    147279  IN      NS      c.gtld-servers.net.

Received 247 bytes from 127.0.0.1#53 in 0 ms
Trying "ptsi.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52680
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;ptsi.net.                      IN      MX

;; AUTHORITY SECTION:
net.                    147279  IN      NS      m.gtld-servers.net.
net.                    147279  IN      NS      l.gtld-servers.net.
net.                    147279  IN      NS      g.gtld-servers.net.
net.                    147279  IN      NS      f.gtld-servers.net.
net.                    147279  IN      NS      c.gtld-servers.net.
net.                    147279  IN      NS      i.gtld-servers.net.
net.                    147279  IN      NS      k.gtld-servers.net.
net.                    147279  IN      NS      h.gtld-servers.net.
net.                    147279  IN      NS      a.gtld-servers.net.
net.                    147279  IN      NS      e.gtld-servers.net.
net.                    147279  IN      NS      d.gtld-servers.net.
net.                    147279  IN      NS      j.gtld-servers.net.
net.                    147279  IN      NS      b.gtld-servers.net.

Received 247 bytes from 127.0.0.1#53 in 0 ms

UPDATE:
I turned on some additional logging and tried to resolve the domain. Looks like the significant line has to do with 'no valid RRSIG':

Code:

22-Jul-2013 09:34:57.116 queries: info: client 127.0.0.1#37008: view internal: query: ptsi.net IN A + (127.0.0.1)
22-Jul-2013 09:34:58.001 queries: info: client 127.0.0.1#36019: view internal: query: ptsi.net IN AAAA + (127.0.0.1)
22-Jul-2013 09:34:58.054 queries: info: client 127.0.0.1#55020: view internal: query: ptsi.net IN MX + (127.0.0.1)
22-Jul-2013 09:34:58.107 lame-servers: info: error (no valid RRSIG) resolving 'ptsi.net/MX/IN': 65.79.193.9#53
22-Jul-2013 09:34:58.159 lame-servers: info: error (no valid RRSIG) resolving 'ptsi.net/MX/IN': 65.79.197.98#53
22-Jul-2013 09:34:58.159 queries: info: client 127.0.0.1#52737: view internal: query: ptsi.net IN MX + (127.0.0.1)
22-Jul-2013 09:34:58.212 lame-servers: info: error (no valid RRSIG) resolving 'ptsi.net/MX/IN': 65.79.197.98#53
22-Jul-2013 09:34:58.264 lame-servers: info: error (no valid RRSIG) resolving 'ptsi.net/MX/IN': 65.79.193.9#53

gunhed · 07-22-2013, 09:49 AM

Looks like I figured out the problem. After seeing the RRSIG error, I did a search, and found a good link:
http://spectlog.com/content/BIND_nam...S%29_resolving

Which prompted me to edit my /etc/named.conf from this:

Code:

   dnssec-enable no;
   dnssec-validation yes;

To this:

Code:

   dnssec-enable no;
   dnssec-validation no;

And now, I can resolve the offending (no offence) host:

Code:

$ host -t mx ptsi.net
ptsi.net mail is handled by 30 aspmx2.googlemail.com.
ptsi.net mail is handled by 30 aspmx3.googlemail.com.
ptsi.net mail is handled by 10 aspmx.l.google.com.
ptsi.net mail is handled by 20 alt1.aspmx.l.google.com.
ptsi.net mail is handled by 20 alt2.aspmx.l.google.com.