Thanks, I believe I'd finally figured this out... I was "distracted" by the presence of the trailing dots rather than the absence of anything meaningful (like a domain name) prior to the dot.
SO, the original MX, "faxcore1.mwro.", did nothing (but it did not get in the way or otherwise break things). Adding another one also did nothing pointing to another address also did nothing... MX record now says "faxcore1.mwro.aspca.org. MX 20 faxcore2.mwro.aspca.org." The record "faxcore1.mwro.aspca.org. MX 10 faxcore1.mwro.aspca.org.", Cogent tells me, is redundant and won't be created. Time for more testing; thanks! -- richard From: Ben Scott [mailto:mailvor...@gmail.com] Sent: Tuesday, May 15, 2012 9:23 PM To: NT System Admin Issues Subject: Re: Help w/DNS MX records On Tue, May 15, 2012 at 9:44 AM, Richard McClary <richard.mccl...@aspca.org<mailto:richard.mccl...@aspca.org>> wrote: > The trailing dots on the LHS were there from when records including > Faxcore were imported first from AT&T (which may have put them in > somewhat automatically in their web interface) to Internap, and then > from Internap to Cogent. That seems to translate as, "We have no idea why those records are there." :) > SO, to summarize, before my next test, I should: I don't have enough information to tell you what you "should" do. But I suspect your DNS records aren't doing what you think they are. In standard notation, a fully-qualified domain name (FQDN) ends in a dot. If there is no dot, it's assumed to be a relative domain name. For relative domain names, the origin and/or search path can/will get involved. <www.microsoft.com<http://www.microsoft.com>.> is an FQDN. <microsoft.com<http://microsoft.com>.> is an FQDN. <com.> is an FQDN. <.> is an FQDN. <faxcore1.mwro.aspca.org<http://faxcore1.mwro.aspca.org>.> is an FQDN. <faxcore1.mwro.aspca.org<http://faxcore1.mwro.aspca.org>> is not an FQDN. <faxcore1.mwro> is not an FQDN. <faxcore1.mwro.> is an FQDN. So when you see: faxcore1.mwro A 63.85.204.151 faxcore1.mwro. MX 10 faxcore1.mwro.aspca.org<http://faxcore1.mwro.aspca.org>. ... I suspect the computer sees: faxcore1.mwro.aspca.org<http://aspca.org>. A 63.85.204.151 faxcore1.mwro. MX 10 faxcore1.mwro.aspca.org<http://faxcore1.mwro.aspca.org>. While the name <faxcore1.mwro.> is valid according to the DNS protocol, in the public DNS structure, it's not delegated from the root, so nobody will find it. To wit: > dig +noall +ans ANY faxcore1.mwro.aspca.org<http://faxcore1.mwro.aspca.org>. > @auth1.dns.cogentco.com<http://auth1.dns.cogentco.com>. faxcore1.mwro.aspca.org<http://faxcore1.mwro.aspca.org>. 600 IN A 63.85.204.151 > dig +noall +ans ANY faxcore1.mwro. > @auth1.dns.cogentco.com<http://auth1.dns.cogentco.com>. > I have no idea if this is related to your other issues. But you should prolly get a handle on your DNS even if this is unrelated. Oh, I bet I know what's going on. The RFCs say that in the absence of an MX record, an SMTP implementation should try for an A record, and if it gets one, assume that is the mail exchanger. So when DNS clients try for an MX record for <faxcore1.mwro.aspca.org<http://faxcore1.mwro.aspca.org>.>, they don't get one, but then try for an A record, and succeed. The bogus <faxcore1.mwro.> record never gets involved. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com<mailto:listmana...@lyris.sunbeltsoftware.com> with the body: unsubscribe ntsysadmin The information contained in this e-mail, and any attachments hereto, is from The American Society for the Prevention of Cruelty to Animals® (ASPCA®) and is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying or use of the contents of this e-mail, and any attachments hereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify me by reply email and permanently delete the original and any copy of this e-mail and any printout thereof. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
