Proposed [sub 2] new operational mode for primary master

Joseph S D Yao jsdy at cospo.osis.gov
Fri Nov 3 17:14:08 UTC 2000


It was not obvious from your first message that you had also sent it to
the mailing list/newsgroup.

----- Forwarded message from Joseph S D Yao <jsdy at cospo.osis.gov> -----

Date: Fri, 3 Nov 2000 11:52:29 -0500
From: Joseph S D Yao <jsdy at cospo.osis.gov>
To: wallewek at kmsi.net
Cc: Joseph S D Yao <jsdy at cospo.osis.gov>
Subject: Re: Proposed [sub 2] new operational mode for primary master
X-Mailer: Mutt 1.0i
In-Reply-To: <sld30tg3ktkes5j7e1bndqmaoj3faa7sic at 4ax.com>; from wallewek at kmsi.net on Thu, Nov 02, 2000 at 01:41:12PM -0700

On Thu, Nov 02, 2000 at 01:41:12PM -0700, wallewek at kmsi.net wrote:
> An interesting response.  Comments/questing in-line below...
...
> Are you saying you have internal DNS servers that are externally
> accessible?  Or that you have external DNS servers that do zone transfers
> inside-to-outside?

Neither.  Internal name servers forward to other internal name servers.
This contradicts your proposal, that all unresolved requests including
those in the same domain be automatically forwarded to an external
server.  I do realize that you may have meant something different than
what you said, but I was responding to what was written.  If it were an
RFC, implementors would do the same.

> >Same for the primary
> >domain.  It's parent to a lot of the internal domains, and contains so
> >few names that it isn't necessary to worry to hard about duplication.
> >(Actually, I think there is no duplication - what names are the same
> >inside and out have different addresses.)
> 
> Sorry, I must be missing your point here, somehow.  I've gone over our
> description, and I don't see where there is a problem.  If you could
> perhaps explain that, I would appreciate it.

Apologies: this was an OBTW, and should have been marked as such.  I
don't WANT any of the external names visible internally.  But in the
base domain, there aren't a lot.

> All I am suggesting is that, if a query for a given name isn't resolved by
> an internal DNS server, that query be passed to the external DNS tree,
> where it would either succeed or fail.  How would cause a problem for the
> complex structure you describe?

See above.

> What I am proposing is, in essence, that there be no requirement for the
> direct exchange of information, either manually or automatically, between
> the internal and external DNS servers. ...

I don't understand this, in relation to your proposal.  My understanding
of what you had written was this: if a name is found not to be resolved
on a name server, and that name server detects somehow that it is
internal to a private internet, then it must seek the name server for
the same domain on the public Internet and pass the query on to it.  I
find this concept has numerous problems.  But it does require exchange
of information between the two name servers!  The fact that this is
mediated either by an IP filtering router or a firewall proxy is
irrelevant.

[ADDITION: "seeking the name server" might be done by normal lookup, or
 by special infused knowledge in the config file.]

>				     ... Even the usual caching would be an
> optimization, not a functional necessity.  ...

As it already is.

>					...  The two servers could be run by
> people who don't even talk to each other, let alone coordinate
> configurations.

The security implications of this are dismaying.  This is the same
identical domain we're talking about, right?  So there is no way for
the person allegedly controlling the internal name server to verify the
external name server and actually control what his name server delivers
as "authoritative"?  No, thanks!!!

> If the structure you describe above _requires_ such exchange and
> coordination (I don't see that, but I could have missed it), then I agree,
> it could be a problem.  I'd appreciate your thoughts in that.  

It requires that it not exist.  Your proposal requires it, as I
understood it.

> [Note that that it would preferable, but not necessary, for queries for
> external addresses to be passed to external DNS servers via cached entries
> received from the Internet TLD servers, to reduce as much as possible the
> requirement for coordination of details like IP addresses between the
> administrators of the two areas.]

I don't understand how this adds or deletes anything from the original
proposal.

> >I have another problem, that would affect both homogenously and
> >heterogenously domained networks.  This is the "scan for a name"
> >effect.  If I find an internal name server that is authoritative for a
> >domain, even if I get an NXDOMAIN, I don't want it to then go scan for
> >ANOTHER domain name server to get ITS opinion.  
> 
> If that query would then succeed, why not?

Big "if".

> And if such configuration/behavior significantly reduces the overhead of
> administering your network and increases its robustness, it strikes be as
> well worthwhile.

I obviously don't see it as doing this.  ;-)

> >Even if it does happen
> >to be out on the public Internet instead of on my private internet.
> >That would add yet another delay while it goes out and searches for a
> >name server that will give it some kind of response "out there".
> 
> If you're already concerned about the length of time normal lookups take, I
> supposed that would be a problem, because this could potentially double the
> time required to lookup external addresses, if they aren't already in the
> local cache.

Precisely.

> It seems to me that, worst case, the proposed change would have about the
> same effect as if a given workstation had two DNS servers listed in its
> server list: one for internal-only queries, and one for external-only
> queries.  If the internal-only one is listed first, the external-only one
> would queried only if the internal-only one doesn't return a success.

Except that one might hope they have totally different contents ...
which makes listing them in this way of dubious value.

> >And what if all the servers in a given domain do this?  Does it go
> >scanning for another name server forever?  
> 
> Only internal authoritative servers would behave any differently from the
> way they do now.  
> 
> Currently, when an authoritative server fails a lookup, it checks to see if
> the domain is one in which it is authoritative, and if so, stops there and
> returns an error.  I'm proposing to remove that check, so that _for
> internal servers only_, it treats such queries the same regardless of
> whether it is authoritative.  I'm not proposing any changes in zome
> transfers, etc.

No, that is incorrect.  It doesn't do an internal lookup which can fail
unless it is authoritative.  There is no post-check on authority.  You
are proposing a very serious change in behaviour.

> This wouldn't result in any loops, because the next step after a faild
> lookup takes the query outside the internal network, where things proceed
> entirely normally and cannot be referred back to the internal server.
> 
> By the way, I'm writing all this assuming the context "internal == hidden".
> If your internal DNS servers are accessible from the Internet, none of this
> applies.

I had been trying to figure out how a server decided it was "internal".
The loop scenario depended on the configuration file containing a bit
that said that it was.  If the external servers declared themselves
internal, then this would be possible.  If not, obviously not.  Other
comments depended on auto-determination.  I apologize for not making
this internal inconsistency clear.

> > I don't see where this would
> >have a real end.  Granted, if a server knows that it is on the public
> >Internet, by your proposal, it wouldn't do this.  But that is yet
> >another problem - how does it determine this reliably?
> 
> That's a key question.  So far as I can see, it would have to be a new
> configuration option in the SOA record.  I haven't spent any time on
> exactly what form that would take yet; I want to be satisfied the concept
> is valid.  And I fully grant it's outside my area of expertise.

Absolutely not in the SOA record.  Why not in the named.conf file?

> >OTOH, this kind of feature is requested enough that it might be worth
> >considering some kind of OPTION to allow this.  Perhaps an option to
> >make a zone "mildly authoritative"?  ;-}  It would need some work to
> >avoid the above problems.  I prefer auth-or-not, myself.
> >
> >Perhaps better - an option to have the master server for the internal
> >name server do a zone transfer from one of the external peer servers,
> >save it in an optional file (like a slave server), discard all names
> >that have conflicts, and make the rest part of the internal zone.  I
> 
> I was hoping to avoid zone transfers, because I want to keep the inside and
> outside SOAs fully independent.  I don't think they should even have
> configured-in references to each other.

They are the SAME DOMAIN.  They had jolly well better co-ordinate.  Or
they will suffer some kind of spoofing attack.

> The "conflicts" thing bothered me a little at first, because my initial
> impulse was that they shouldn't occur in a well-managed domain.  ...

And you're the one proposing that they not work with each other!  Who
gets the names ns, web, www, mail?  Who gets kirk, spock, ryker, troy?
Or frodo, bilbo, gandalf, depending on what kind of fen they are?

>								.  But with
> the proposed change, they wouldn't really matter all that much.  First
> successful query response (i.e., internal) wins.  No problem.  You could
> legitimately have two hosts with exactly with same name, one internal and
> one external.  Internal queries would always resolve to the internal host.
> External queries would resolve to the external host. Fits with the whole
> concept, to me.

And when I want to go to [internal] www.example.com, and then
[external] www.example.com?

> >don't like that, because I would still like to have the option to have
> >some names undefined on the inside.
> 
> Your're saying you want to be able to hide some external names from inside
> hosts?  Hmmm...  Well, you could hide them by creating deliberate "ghost"
> entries in the internal DNS, which would prevent queries from ever
> resolving to the outside hosts.

Quite true.  So I have to frantically keep monitoring what my rival on
the external name server is doing, and block everything he does that I
don't like, hmmm?

> >  Maybe have a filter to either
> >allow "only this" or "all but this"?  It's much more complex to do, BUT
> >it allows authoritative servers to retain their authority and dignity.
> >It would also require that changes to the external server somehow
> >notify the internal server ... no, since it's not a slave, that
> >wouldn't work. It would have to be a manual reload, I think.
> 
> I agree, I don't like that one either.  And I don't know, but I don't see
> it as necessary.
> 
> >Especially since, for some systems, DNS will NOT go in through the
> >firewall.
> 
> Exactly the kind of environment I have in mind.
> 
> >How's that?
> 
> I'm afraid I still don't see why you seem to think that there needs to be
> any kind of zone transfer in from the outside.  Granted, it would make
> resolution for un-cached outside addresses quicker but, generally speaking,
> there would usually be relative few outside addresses in the same domain as
> the inside addresses.  And if they were accessed often, they'd be cached
> anyway.

Granted relatively few.  So the hardship in making them part of the
internal zone file is, exactly ... ???

I still think that the "separate domain" way of doing this is by far
the easiest.

-- 
Joe Yao				jsdy at cospo.osis.gov - Joseph S. D. Yao
COSPO/OSIS Computer Support					EMT-B
-----------------------------------------------------------------------
This message is not an official statement of COSPO policies.

----- End forwarded message -----

-- 
Joe Yao				jsdy at cospo.osis.gov - Joseph S. D. Yao
COSPO/OSIS Computer Support					EMT-B
-----------------------------------------------------------------------
This message is not an official statement of COSPO policies.



More information about the bind-users mailing list