On Tue, May 15, 2012 at 9:44 AM, Richard McClary <[email protected]> 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.> is an FQDN. <microsoft.com.> is an FQDN. <com.> is an FQDN. <.> is an FQDN. <faxcore1.mwro.aspca.org.> is an FQDN. <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. ... I suspect the computer sees: faxcore1.mwro.aspca.org. A 63.85.204.151 faxcore1.mwro. MX 10 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. @auth1.dns.cogentco.com.* faxcore1.mwro.aspca.org. 600 IN A 63.85.204.151 > *dig +noall +ans ANY faxcore1.mwro. @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.>, 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 [email protected] with the body: unsubscribe ntsysadmin
