Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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 us.yusen-logistics.com mx:

;; QUESTION SECTION:
;us.yusen-logistics.com.                IN      MX

;; ANSWER SECTION:
us.yusen-logistics.com. 300     IN      MX      10 smtp1.us.yusen-logistics.com.

us.yusen-logistics.com. 300     IN      MX      20 smtp2.us.yusen-logistics.com.


;; ADDITIONAL SECTION:
grid2i.seg.att.com.     24426   IN      A       209.65.176.73
grid1i.seg.att.com.     24429   IN      A       209.65.160.81
grid2i.seg.att.com.     24426   IN      A       209.65.176.81
grid1i.seg.att.com.     24429   IN      A       209.65.160.73
grid2i.seg.att.com.     24426   IN      A       209.65.160.89

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

;; QUESTION SECTION:
;us.yusen-logistics.com.                IN      MX

;; ANSWER SECTION:
us.yusen-logistics.com. 200     IN      MX      10 smtp1.us.yusen-logistics.com.

us.yusen-logistics.com. 200     IN      MX      20 smtp2.us.yusen-logistics.com.

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 smtp1.us.yusen-logistics.com, 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 smtp1.us.yusen-logistics.com. and smtp2.us.yusen-logistics.com. resolve to. Afterwards, your server caches that, so it doesn't have to make the secondary requests. –  NickW Mar 7 at 17:35
3  
Yea, that's a red herring, expected behavior. Focus on your mail logs, they should hold the answer. –  dmourati Mar 7 at 17:43

2 Answers 2

up vote 4 down vote accepted

Yes, the RRs are actually the A records that smtp1.us.yusen-logistics.com and smtp1.us.yusen-logistics.com are CNAME'd to.

smtp1.us.yusen-logistics.com is a CNAME for grid1i.seg.att.com. 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 www.google.com A records in that first response and do bad things to you if your DNS server cached that.

As also pointed out, the names smtp1.us.yusen-logistics.com and smtp2.us.yusen-logistics.com 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 Mar 11 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 at 14:37

Your Answer

 
discard

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.