# [EMAIL PROTECTED] / 2003-01-09 12:48:03 -0800:
> To: Roman Neuhauser <[EMAIL PROTECTED]>
please don't cc me.
> Roman Neuhauser wrote:
> > > ! This is called a "split horizon DNS", and you need to run two
> > > ! DNS servers, one interior, and one exterior, both authoritative
> > > ! for your domain, in order for this to work. The problem is that
> > > ! you are forwarding a request that should be local, and you are
> > > ! doing it because your local server does not pass the authority
> > > ! test for your local domain.
> > >
> > > Well, I think I got it now. What I did not know was that any
> > > nameserver installation is expected to always have some kind
> > > of root nameserver accessible (either the real ones from the
> > > internet, or elseways a local shortcut) in order to function
> > > properly.
> >
> > This is wrong in at least two ways.
> >
> > An authoritative content server doesn't need to know root servers,
> > because they're out of it's business.
>
> The authoritative server must also be a forwarding server.
> This is because of both the way the resolver library itself works
You talked about nameservers and split horizon,
I talked about nameservers and split horizon.
Now you talk about Bind. Don't change the playground, please.
I don't know how the Bind library works, but I know that the
authoritative server I use has now idea of roots.
> (single preference), and the fact that on a border router, you
> have only a single IP address on which to bind a DNS service,
> and therefore can offer only a single DNS service to interior
> machines.
Hmm? Are you talking about having both a cache and a content server
on a router? The interior Windows clients of course only query the
cache, so you can have the content server on 127.0.0.1. And, BTW, I
don't see why I couldn't have more than one address on the inside
interface, cache on one, content/authoritative server on another.
> While technically, some UNIX clients permit multiple
> definitaions in this case, practically, you can't take advantage
> of this, because you must deal with interior Windows clients
> machines, where this is not permitted.
I don't know what you're talking about. Could you rephrase it?
> > A non-recursive (forwarding-only) resolver doesn't need to know
> > root servers, just the upstream resolver it forwards all requests
> > to.
>
> Realize that this is not possible, with the current resolver
> library, since all programs will reference the single /etc/resolv.conf.
Now it seems *you* don't know what your talking about.
1.2.3.5 <-- ISP's "name server" (in fact, recursive cache)
^
|
v
1.2.3.4
10.0.0.{1,2} <-- my router, with a forwarding cache on 10.0.0.1
^ and a content server (for, say, domain.local)
| on 10.0.0.2
v
10.0.0.{3..10} <-- fbsd/windows boxes
all my boxes, including the router, have 10.0.0.1 in
/etc/resolv.conf, and the cache on the router is configured to
forward all recursive queries to 1.2.3.5
what's the problem?
> If you reference a completely authoritative interior server, with
> no forwarding, and the resolver stops there, then the exterior
> server is not referenced.
A properly configured authoritative server will:
1. drop recursive queries
2. drop queries for data it's not authoritative for
anything else is asking for trouble
> This is complicated,
I don't think so.
> both as noted above, for Windows clients (it would require a second IP
> address on the interior network, minimally, to resolve),
which is:
1. not true in the sense that you can have the authoritative server
on 127.0.0.1 which is always there
2. trivial to add
> and by the fact that the IP address of the external interface is
> unknown until after link-up,
hm? what does the external IP have to do with this?
> which will generally occur well after the DHCP lease is granted to
> interior machines. This is even urther complicated by the fact
> that the DHCP server is likely to be a Windows Primary Domain
> Controller, and therefore not the border device, itself.
i don't see how that's related.
> Note that even though your resolver is internally authoritative,
this is an oxymoron. a resolver (cache) cannot not be authoritative.
> The only way for this to actually work is to split the authority
> for the example.com domain between two nameservers -- one interior,
> and one exterior. Partial delegation is simply not supported by
> the current DNS model.
I don't know what partial delegation is, but I *do* know that I have
a split horizon here with one nameserver.
> Unfortuanately, a transiently connected DNS server will not receive
> notifications from a primary DNS server, particularly when it is
> offline, but also for any state changes occurring while it is
> offline, unless it attempts a zone transfer (e.g. on link up).
> Zone transfers are not desirable in this case, since the authority
> is split; the closes you can get is a "blind secondary".
>
> To implement a blind secondary requires modification of the DNS
> server secondary declaration mechanism, to result in a serach
> from root by the secondary server, in order to locate the primary
> for the domain being served. For this to work, the syntax of
> the declaration of a secondary must be changes, and a zone transfer
> attempted on linkup.
>
> The syntax of a blind secondary is defined at:
>
> Blind Secondary DNS Extension
> <draft-lambert-dns-bsec-00.txt>
> ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-bsec-00.txt
why do you keep talking about Bind? this was about split horizon?!
primary/secondary is:
1. Bindism
2. administrative concept. *I* can modify the data on either of the
*authoritative* servers and rsyns+ssh the data to the other. It
doesn't matter which way the data goes at all. (It is actually
always done from A to B because the data is preprocessed and I only
want to transfer the compiled form.)
The fact that *you* can't do it because of limitations in software
you use has nothing to do with split horizon per se, or the number
of content servers it requires.
<snip>
--
If you cc me or remove the list(s) completely I'll most likely ignore
your message. see http://www.eyrie.org./~eagle/faqs/questions.html
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
