Thanks. Comments in-line...
-----Original Message----- From: Ben Scott [mailto:[email protected]] Sent: Wednesday, May 16, 2012 11:01 PM I really, strongly, highly, and in all other ways recommend that you specify things using FQDNs (with trailing dots) everywhere in your DNS zone files. Relative domain names in zone files tend to surprise people who don't have a real strong awareness of what's going on in the zone. Example (counter to the above): faxcore1.mrwo.aspca.org. MX 10 faxcore1.mwro.aspca.org. faxcore1.mrwo.aspca.org. A 63.85.204.151 I suspect those useless <faxcore1.mrwo.> domain names came about because of confusion around the absolute/relative distinction, so this isn't just me being preachy. Better practices would have likely saved us both a lot of trouble already. Yup! You personally, with replies not only to me but to others as well, have improved many of my practices. That much I got. I'm still unclear on all those other MX records you alluded to (<faxcore1.aspca.local.> and friends). Maybe they don't matter. Maybe they do. I can't really say without more information. They began to matter as soon as we added that second "faxcore" record. Okay, so, basically, you've got two domain names with corresponding IP addresses: faxcore1.mwro.aspca.org. A 63.85.204.151 faxcore2.mwro.aspca.org. A 38.96.187.231 One of those IP addresses is your Illinois Internet connection. The other is your NYC Internet connection. Both IP addresses forward to the same private IP address inside your firewalls. Your private WAN will handle routing of NYC to Illinois, independent of the Internet. Do I have this right? If so, I think your basic plan is sound. Thanks! The only reason I was able to get the Cogent system to accept an MX record for faxcore1 was, I had a typo in the line. Once I corrected the spelling, then the system would not take it. (The technician at Cogent could not make the system take it, either. Whatever DNS system they are running will not accept "redundancies". My solution (as we were unable to get fax mail to come back to Illinois directly) was to create another A record with the same IP address of faxcore1 - faxcore3.mwro.aspca.org. A 63.85.204.151 Then the MX record - faxcore1.mwro.aspca.org. MX 10 faxcore3.mwro.aspca.org. After the TTL period passed, the fax mail again began coming to Illinois. > Only the MX 20 record is showing up in nslookup queries. Don't use NSLOOKUP; use DIG. The discrepancies you describe may have been due to DNS caching, or simply because Cogent's back-end systems/processes hadn't finished the request update yet. Or maybe Cogent just screwed up. :) You do still have some minor eirdness in your public-facing DNS. Here's what I'm seeing now: faxcore1.mwro.aspca.org. A 63.85.204.151 faxcore1.mwro.aspca.org. MX 20 faxcore2.mwro.aspca.org. faxcore1.mwro.aspca.org. MX 10 faxcore3.mwro.aspca.org. faxcore2.mwro.aspca.org. A 38.96.187.231 faxcore3.mwro.aspca.org. A 63.85.204.151 While that will do what you want (I think), having three separate A records like that is pointless complication. It's likely to be rather confusing when you have to revisit it three years from now or whatever. Try this on for size: faxcore.mwro.aspca.org. MX 10 faxcore-illinois.mwro.aspca.org. faxcore.mwro.aspca.org. MX 20 faxcore-nyc.mwro.aspca.org. faxcore-illinois.mwro.aspca.org. A 63.85.204.151 faxcore-nyc.mwro.aspca.org. A 38.96.187.231 faxcore1.mwro.aspca.org. CNAME faxcore.mwro.aspca.org. faxcore2.mwro.aspca.org. CNAME faxcore.mwro.aspca.org. faxcore3.mwro.aspca.org. CNAME faxcore.mwro.aspca.org. The above declares a domain <faxcore.mwro.aspca.org.>, with two mail exchangers, and no other records -- making it clear that the domain's purpose is solely to handle mail. The two mail exchangers have names reflecting where they are, which should also help make clear why the priorities are set the way they are. Finally, the legacy 1/2/3 names are CNAME'ed so things keep working the way they have, but with the implication that those names are not the best way to look at it. Whenever possible, I try to make things self-documenting. Great suggestion! -- 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 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 [email protected] with the body: unsubscribe ntsysadmin
