On Wed, May 16, 2012 at 10:38 AM, Richard McClary
<[email protected]> wrote:
[quotes reordered for editorial convenience]
> Sorry about using the term “MIP”, but someone else realized I was using
> Juniper and answered those questions.

  I was guessing from context anyway, but as we all know, guessing is
usually not a good IT strategy.  I wanted to be sure.  :)

> faxcore1.mrwo.aspca.org. MX 10 faxcore1.mwro.aspca.org.
> faxcore1.mwro            A   63.85.204.151

  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.

> Again the background – faxcore1 is an email-to-fax gateway.  It needs to
> receive email addressed to it but be separate from the incoming mail from
> the rest of ASPCA.ORG.

  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.

> Faxcore2 is the same machine as faxcore1 (once it makes it into our wide
> area network), The purpose of all this is to provide a route for incoming
> fax mail through New York when the Illinois internet connection is broken.

  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.

> 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.

-- 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

Reply via email to