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