Proposed [sub 2] new operational mode for primary master

[Kevin Darcy]

The change you propose is underspecified and almost certainly more than "a line
or two of code".

What exactly do you mean by "unresolved request"? If a response would normally be
answered as "no records of requested type", does that constitute
"unresolved"? It's not NXDOMAIN, after all. What if the query is known to be
beneath a zone cut? Do we pass it on up to our "other authoritative nameserver",
or do we recurse to the delegated nameservers as per normal (assuming recursion
desired/available and that there is no intersection between the server sets)? The
"other authoritative nameserver" may not even have that same zone cut, in fact it
may have a totally different zone structure for that domain. Do we cache the
responses from the "other authoritative nameserver"? If not, then this could be a
performance disaster. If so, then what credibility does the data have? Higher or
lower than our own authoritative data? This is important in the case of a direct
conflict (you may be thinking: there will never be a conflict, because only
*unresolved* queries get forwarded, but perhaps you are forgetting about CNAMEs
which might only exist in the "other authoritative nameserver", but point to a
name we know about or think we know about). How do you handle wildcards?
TYPE=ANY queries?

If you're the master in such an arrangement and receive a Dynamic Update request,
do you honor it? After all, you're the master. But wait, there's another master
potentially, isn't there? One "out there". Maybe *it* should be processing the
request instead. How do you know? Is this something the administrator has to
configure somehow? If it's a delete request, do you delete your entry
*and* forward the delete request to the other server? What if it returns that a
prereq failed? Did the Dynamic Update work or not? There's no way to tell the
client that a Dynamic Update "partially worked" without changing the Dynamic
Update protocol.

What if you implement DNSSEC? Do you share a zone key? Have separate zone keys?

I really think the "authoritative means authoritative" paradigm, as simplistic as
it is, is the most reasonable approach, when you take into account all of these
other complications. It's really not that hard to run a split DNS.
"Semi-authoritative" just opens up all sorts of wormcans.


- Kevin

wallewek at kmsi.net wrote:

> An interesting response.  Comments/questing in-line below...
>
> Joseph S D Yao <jsdy at cospo.osis.gov> wrote:
>
> >On Wed, Nov 01, 2000 at 07:40:14AM +0000, wallewek at kmsi.net wrote:
> >...
> >> It's an extremely simple change: for private networks only, forward _all_
> >> unresolved requests to the Internet proper, not just requests regarding
> >> hosts outside the local domain.  I.e., do not treat the local domain any
> >> differently from any other.  I haven't looked at the source code for the
> >> Linux DNS server (yet), but I'd be surprised if it involves more that a
> >> line or two of code.  Admittedly, a trickier question would be how to
> >> express that option in a zone file without causing compatibility issues.
> >
> >This would work for small homogenous private networks under some
> >circumstances (see below).  ISTM that for larger ones, this would be a
> >disaster.  Specifically, I not only have my primary domain and its
> >subdomains inside the private network, but I also have entities inside
> >my private network that insist on having their own domain names, in
> >many cases even under different TLDs.  Each internal domain forwards,
> >not to the Internet, but to an internal "broker".  What each domain
> >wants visible internally, they define internally.  What each domain
> >wants visible externally, they define externally.
>
> 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?
>
> >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.
>
> 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?
>
> 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. Even the usual caching would be an
> optimization, not a functional necessity.  The two servers could be run by
> people who don't even talk to each other, let alone coordinate
> configurations.
>
> 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.
>
> [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 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?
> And if such configuration/behavior significantly reduces the overhead of
> administering your network and increases its robustness, it strikes be as
> well worthwhile.
>
> >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.
>
> 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.
>
> >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.
>
> 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 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.
>
> >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.
>
> The "conflicts" thing bothered me a little at first, because my initial
> impulse was that they shouldn't occur in a well-managed domain.  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.
>
> >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.
>
> >  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.
>
> >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.
>
> Joe, you raise some good points.  Do these responses answer them, or do you
> still see unresolved issues?
>
> /kenw
> Ken Wallewein
> Calgary, Alberta
> kenw at kmsi.net