Proposed new operational mode for primary master

Bob Vance bobvance at alumni.caltech.edu
Sat Nov 4 13:43:53 UTC 2000


ISTM that it wouldn't be that hard to implement (but, then, I'm not
maintaining the code, am I ;>) a zone attribute:

    "NXDOMAIN_forwarders{...};"
or  "split_forwarders{...};"

that could be applied to a master or slave zone .

The request would only be forwarded if:

  1) we are authoritative for it.
  2) we would return an NXDOMAIN

I wouldn't arbitrarily forward *all* NXDOMAINs, because of possible
forwarding to delegated sub-domain servers -- if they return an
NXDOMAIN, then we certainly don't want to subsequently forward to the
external server.

I suppose it also could just be a Boolean

    "forward_NXDOMAIN;"

That would forward to the existing list of forwarders, since, in this
scenario the forwarder list would just be the external DNS server.
This would be a lot easier to implement.

I could see that this "split_forward" would be useful in the particular
case that Ken wants -- same domain name inside and outside.

Now, I haven't given any thought to mail or reverse-domain issues.


>Using a separate domain name for the inside segment, despite here being
>no logically compelling reason for doing so, conveys no value and
>unnecessarily complicates the naming structure.

I disagree.  I think that it makes perfect sense to have the internal
name be a sub-domain of the external name.
That's what we did for years -- sbm.com and atl.sbm.com -- with no
problems.  This makes it a lot easier to avoid naming conflicts that
would arise in the split_forward scenario.  E.g., you wouldn't be able
to use www.dom.com internally, since it is most likely the external
web server.  Of course, you could argue that your intranet servers
*should* have different names, like say, www-i, I guess.


-------------------------------------------------
Tks        | <mailto:Bob_Vance at sbm.com>
BV         | <mailto:bobvance at alumni.caltech.edu>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430           11455 Lakefield Dr.
Fax 770-623-3429           Duluth, GA 30097-1511
=================================================





-----Original Message-----
From: news at news1.rdc1.ab.home.com [mailto:news at news1.rdc1.ab.home.com]On
Behalf Of wallewek at kmsi.net
Sent: Thursday, November 02, 2000 5:51 PM
To: comp-protocols-dns-bind at moderators.isc.org
Subject: Re: Proposed new operational mode for primary master



"Kenneth Porter" <shiva at well.com> wrote:

>On Wed, 01 Nov 2000 07:40:14 GMT, wallewek at kmsi.net wrote:
>
>>One _could_ suggest that it isn't legitimate for the internal network
to
>>use the same domain name as the external one.  That may be defensible
from
>>the perspective of making things easy for existing DNS software, but
from
>>the perspective of logical name space, sharing the common domain name
seems
>>perfectly legitimate.  If the DNS machinery handled it well, there
would no
>>logical problems that I can see.
>
>A better solution is to use a separate private domain for your internal
>LAN, say mybigcompany.internal (is there a standard TLD for private
>domains?) and use a CNAME within your internal domain to reference
>hosts (such as www) in the public domain. Your internal users enter
>"www.mybigcompany.internal" and your DNS resolves this to a CNAME to
>"www.mybigcompany.com".
>
>Do you have some strong reason to use your public domain on your
>private LAN?
>
>Ken
>mailto:shiva at well.com
>http://www.sewingwitch.com/ken/
>http://www.harrybrowne2000.org/

Using a separate domain name for the inside segment, despite here being
no
logically compelling reason for doing so, conveys no value and
unnecessarily complicates the naming structure.  It's a pointless kludge
with no justification other than to keep the existing DNS infrastructure
happy.

The "strong reason" you ask for is simply that: simplicity.  We can
almost
always live with any arbitrary needless complexity, but every time we
stoop
to doing so, we are violating the rules that allow computers and
networks
to progress.

/kenw

Ken Wallewein
Calgary, Alberta
kenw at kmsi.net






More information about the bind-users mailing list