errors.current: Tousends of "..Received an invalid DNS.

Unanswered Question
Feb 1st, 2008

In our file "errors.current", we have many tousends of such entries:

Fri Feb  1 13:24:49 2008 Warning: Received an invalid DNS Response: rcode=ServFail data="'\\x8e\\x85\\x81\\x82\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x0edrillerssupply\\x03com\\x00\\x00\\x0f\\x00\\x01'" to IP 10.168.3.24 looking up drillerssupply.com


What's about the above IP 10.168.3.24?
(Is this IP sending or receving a mail? Whats the meaning of this IP?)

Nearly all entries occures in combination with only 3 IPs. None of this IP is a mailserver or ironport.

What exactly can I do to minimize or prevent such entries?
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
jaigill Mon, 02/04/2008 - 18:27

This indicates that DNS server 10.168.3.24 returned a 'servfail' when it attempted to lookup domain 'drillerssupply.com' in DNS. SERVFAIL means that the domain does exist and the root name servers have information on this domain, but that the authoritative name servers are not answering queries for this domain.

I got a 'servfail' response when i attempted to lookup this domain from my workstation.

bash-3.00# dig MX drillerssupply.com

; <<>> DiG 9.2.4 <>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7332
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;drillerssupply.com. IN MX

;; Query time: 178 msec
;; SERVER: 172.17.128.3#53(172.17.128.3)
;; WHEN: Mon Feb 4 16:52:10 2008
;; MSG SIZE rcvd: 36



Seeing lots of these messages in the logs indicates that there are lots of emails going to sites that have garbaged DNS replies. It would also mean that the local DNS server is flaky. Based upon this particular example, i would lean on the former.

Pat_ironport Thu, 03/13/2008 - 11:08

I have to come back on this:

In the IronPort Support Knowledge Base, I have found the AnswerID 684 and the section:

4. DNS:

Many customers force the IronPorts to query their internal DNS servers out of habit. In most installations 100% of the DNS records we need are on the Internet, not in the internal DNS. It makes more sense to query the Internet root servers, reducing the forwarding load on the internal DNS.
We are such customers :oops:
The above 3 IP's are all from our internal DNS-Servers. Should we add one ore more external DNS? Should we remove the internal DNS completely or set the Priority first to the external DNS, then to internal DNS?
chhaag Thu, 03/13/2008 - 16:06

In most cases, we have found customers get better performance using the ROOT domain servers alone.

Donald Nash Thu, 03/13/2008 - 18:54

SERVFAIL means that the domain does exist and the root name servers have information on this domain, but that the authoritative name servers are not answering queries for this domain.

This describes a situation known as a "lame delegation." Lame delegations can occur anywhere in the domain tree, not just between the root name servers and their delegates. Lame delegations are probably the most common reason for SERVFAIL, but they're not the only one. The official definition for SERVFAIL is:

The name server was unable to process this query due to a problem with the name server.

The RFC enumerates several other specific errors. So any time a name server has any sort of otherwise unclassified error trying to look up a name, it returns SERVFAIL. It's the DNS equivalent of a generic, "oops, it didn't work."
Pat_ironport Thu, 03/13/2008 - 20:09

Thank you for this explanation.
Is it right, that this specific kind of SERVFAIL (because of the data="'\\x8e\\x85\\x81\\x82\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x0edrillerssupply\\x03com\\x00\\x00\\x0f\\x00\\x01') never ever can be successfull? Or is this syntax the usual way to get the needed information from a DNS-Server?

Donald Nash Thu, 03/13/2008 - 21:04

Or is this syntax the usual way to get the needed information from a DNS-Server?

I don't know exactly what part of the DNS request they're dumping out, so I can't answer your question. I strongly suspect that they're dumping out the entire DNS request (minus the IP and UDP framing), not just the domain being looked up. However, someone from IronPort will need to say for sure. But assuming I'm right, then what you're seeing is normal, not part of the cause of the failure.

Actions

This Discussion