Creating Single Domain from split DNS

Kevin Darcy kcd at daimlerchrysler.com
Wed Oct 3 22:38:21 UTC 2001


laura.l.herndon at accenture.com wrote:

> We are planning to go from a split DNS architecture to a single domain
> model.  Our first step is to create a new subdomain that will eventually
> hold only internal (10.x.x.x) addresses.  To allow for readdressing, we are
> going to run both domains from the same file internally, but I have some
> questions as to how to best accomplish that.
>
> Current setup:
> accenture.com zone accessible from the internet only (on
> AMRNS1501.accenture.com)
> accenture.com zone accessible internally only with both private and public
> addresses.
>
> Interim setup (on current internal NS):
> accenture.com and internal.accenture.com accessible internally only with
> both private and public addresses, using the same db file.
>
> Final setup (on new internal NS):
> accenture.com with public only addresses (same file as external zone)
> internal.accenture.com with private only addresses.
>
> For the db file that will serve both accenture.com and
> internal.accenture.com, I know that I can use non-fully qualified domain
> names and they will be appended with the zone name (or origin, if there is
> one).  This will work perfectly for A and CNAME records, but how do we
> handle MX & NS records?
>
> I've pasted a sample of our internal zone file with the NS & MX records
> below (I've put in a few of the A records.  There are over 8000 lines, so I
> didn't put it all in here...).  I'd like to know if I can get away with
> using the same file, or if I need to use separate files for the zones with
> modified NS & MX records and use include for the A & CNAME records.  (our
> NOC makes our DNS entries, so I want to make sure it's as dummy proof as I
> can get it...)  This project has fried my brain, so please be kind and use
> small words =)
>
> Also, I know our external zone is a mess.  That's next on the list...
>
> Thanks,
> Laura
>
> $TTL 14400
> $ORIGIN accenture.com.
> @       SOA     amrns1001.accenture.com.  hostmaster.accenture.com. (
>
>                         2001090401 ;serial
>                         3600    ;refresh
>                         900     ;retry
>                         3600000 ;expire
>                         14400 ) ;minim
> ;

Uh oh. This zonefile won't load as "internal.accenture.com" because you have
an explicit $ORIGIN here, so the "@" SOA record will be interpreted as being
owned by "accenture.com". Since an "accenture.com" SOA record doesn't belong
in the "internal.accenture.com" zone, named will fail to load this zone,
complaining about "out of zone data".

Why don't you just eliminate the $ORIGIN entirely? That way the default origin
will be "accenture.com" when loaded as "accenture.com" and
"internal.accenture.com" when loaded as "internal.accenture.com".

> ;
> accenture.com.  NS      amrns1001.accenture.com.
> accenture.com.  NS      apans1001.accenture.com.
> accenture.com.  NS      emens1001.accenture.com.
> accenture.com. NS   dalns1012.accenture.com.
> accenture.com. NS   dalns1013.accenture.com.
> ;

Because you have fully-qualified the owner names here, these NS records are
also "out of zone data" for internal.accenture.com and would cause the zone
load to fail. This is true regardless of whether you have an $ORIGIN in the
file or not, since fully-qualified names effectively override $ORIGIN.

Why don't you just eliminate the $ORIGIN, use relative names, e.g.
"alltel" for names that you want to be relative to the zone name, e.g.
"alltel" + "internal.accenture.com" = "alltel.internal.accenture.com", and use
fully-qualified names for everything else?

- Kevin



More information about the bind-users mailing list