Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to track down an issue we're having sending mail to a particular domain. We noticed that we're not getting consistent results from nslookup/dig when querying their MX records, and I'm not sure if we're chasing a non-existent DNS problem or if it could be an issue.

When the result is not cached, I get the following result from dig mx:

;                IN      MX

;; ANSWER SECTION: 300     IN      MX      10 300     IN      MX      20

;; ADDITIONAL SECTION:     24426   IN      A     24429   IN      A     24426   IN      A     24429   IN      A     24426   IN      A

If I run the command again I don't get the additional section:

;                IN      MX

;; ANSWER SECTION: 200     IN      MX      10 200     IN      MX      20

There's concern that the lack of additional records is why our Domino server fails to connect.

I would assume that Domino would simply query the records for, as RFC 1035 states that "the additional records section contains RRs which relate to the query, but are not strictly answers for the question." Is this the case?

share|improve this question
It's normal enough behavior considering that those are what the CNAMEs of and resolve to. Afterwards, your server caches that, so it doesn't have to make the secondary requests. – NickW Mar 7 '14 at 17:35
Yea, that's a red herring, expected behavior. Focus on your mail logs, they should hold the answer. – dmourati Mar 7 '14 at 17:43
up vote 4 down vote accepted

Yes, the RRs are actually the A records that and are CNAME'd to. is a CNAME for which has multiple A records, which are all listed.

The same with 2 substituted for smtp2

As dmourati stated, the real reason your mail is going nowhere will be in your logs. DNS is working as expected.

share|improve this answer

Those A records are out-of-context for the query you are doing. Because of that they are not placed in the cache, which is why on your second request they are not included. This would otherwise be a textbook cache-poisoning DNS attack. I could sneak in A records in that first response and do bad things to you if your DNS server cached that.

As also pointed out, the names and are currently CNAMEs for AT&T servers so this is a blantant SMTP misconfiguration. CNAMEs are not allowed in MX references because it breaks the store-and-forward MX priority chain and often causes mail routing loops.

share|improve this answer
Ah, so maybe DNS is an issue here. Could you perhaps link me to something that explains the SMTP misconfiguration? – Tanner Faulkner Mar 11 '14 at 16:33
RFC1912 Section 2.4 (page 7). It doesn't give a clear example of how it creates mail loops, but it's pretty simple... if an intermediate MTA gets a piece of mail and restarts deliver, it doesn't find itself in the list of MX records so doesn't realize that it may be delivering mail "further" away (to an MX with a lower preference). This can cause mail to ping-pong between two MTAs and eventually bounce. With canonical names in MX records, the first MTA will see itself in the list and know to hold on to the mail and retry later. – milli Mar 14 '14 at 14:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.