Master for domain as set in SOA is not visible to world

lhcash at us.ibm.com lhcash at us.ibm.com
Wed Mar 8 20:09:44 UTC 2000



Sent by:  news at burlma1-snr2.gtei.net

To:   comp-protocols-dns-bind at moderators.uu.net
cc:
Subject:  Re: Master for domain as set in SOA is not visible to world



In article <8525689C.006BF74E.00 at d54mta03.raleigh.ibm.com>,
 <lhcash at us.ibm.com> wrote:
>
>
>Hi, I'm asking about something I'm pretty sure will *work*, but I'm not
>sure how good an idea it is.  I have a domain (call it blah.org).  I want
>to make the master for this domain a system which is the master for some
>internal (not visible to the world) domains.  The only systems visible to
>the world (and the ones which will, therefore, be listed in the NS
records,
>etc.) are slaves.  This system is, of course, behind a firewall and not
>reachable...and I really don't want anyone outside our group to even know
>this system exists, for obvious reasons.  The alternative is either (1) to
>move the master to one of the external systems, thereby increasing
>administrative overhead tremendously (lots of domains, lots of nameservers
>in our setup) and putting the master in our DMZ (where I don't want it),
or
>(2) to make the server listed in the SOA record something other than the
>real master, which means the master will, of course, not see itself as
>authoritative.
>
>I am wondering especially about the second alternative - I am assuming (I
>haven't tried it yet, though) that the external secondaries/slaves will
>still return authoritative answers, as long as they are listed in the NS
>records for the domain - and since these are the only servers queryable by
>the world at large, this should suffice.  Is my reasoning sound, and are
>there any sticky issues I'm missing here?

Being authoritative has nothing to do with whether a server is listed in
the SOA or NS records.  A server is authoritative if the zone is listed in
its named.conf file as type master or slave and it has loaded without
errors.

The only thing that really cares about the master listed in the SOA record
is dynamic update.

What you should do is list the real master in the SOA record, and the
external servers in the NS records.

-- END OF QUOTED TEXT -- (sorry, my email client sucks for quoting)

I understand that - but *even* if the master loads correctly, it will
return answers to queries as "non-authoritative" if it doesn't recognize
itself in either the SOA
or NS records - at least, that is the behavior I have observed  (for
example, if I use an name for a multihomed box which is not the same as
that returned by 'hostname').  I am simply saying I am willing to accept
this behavior to gain the advantage of hiding the
fact that my master is an internal box whose existence I do not want known
to the world.  Your definition of "should do" may fit some situations, but
I am not yet
convinced it fits mine, and I am just asking if there are other negative
consequences of which I should be aware.

Are there?

-Sandy





More information about the bind-users mailing list