Date: Fri, 10 Jan 2003 11:32:22 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Roman Neuhauser <neuhauser@bellavista.cz> Cc: hackers@FreeBSD.ORG Subject: Re: sendmail: how to get the named of FreeBSD4.7 standards compliant? Message-ID: <3E1F1FC6.D5D33801@mindspring.com> References: <20030101181330.C8233@disp.oper.dinoex.org> <3E134659.78028611@mindspring.com> <20030106173652.A495@disp.oper.dinoex.org> <20030109132202.GG1196@freepuppy.bellavista.cz> <3E1DE003.73BF3025@mindspring.com> <20030110105903.GL1196@freepuppy.bellavista.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Roman Neuhauser wrote:
> 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.
You weren't really talking about split horizon, I think; a
"horizon" in this case is any place you can't see over without
a referral happening.
> I don't know how the Bind library works, but I know that the
> authoritative server I use has now idea of roots.
So, do you manually put "yahoo.com" SOA records in your DNS?
How do you answer requests for "yahoo.com".
> > (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.
Because your Windows clients could contact only one of them.
> > 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?
See above.
> > > 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?
Where was *your* second nameserver again? I see a nameserver on
10.0.0.{1,2}; where is your nameserver on 1.2.3.4?
The problem is that you don't have a resolv.conf for your Windows
box, you only ohave the ability to specify a single DNS server in
your DHCP configuration, and if your DHCP server is a Windows box
(which it must be, if you expect to use certain Windows networking
features), then the DNS server it refers to will be the DHCP server;
that means you can't refer to both.
The second problem is that 1.2.3.4 is a dialup address assigned by
the ISP; this makes it impossible to run the DNS server there,
unless the link is up, since it's the other end of a PPP conection.
> > 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
And then, how does an internal client get the external IP "yahoo.com",
if the requests are being dropped?!?
The idea here is to not bring up the link for local traffic,
including DNS traffic, but to bring the link up for non-local
traffic. The point of the local DNS server being caching is
*only* to avoid the 30 second timeout from the first lookup,
which happens when it's the DNS traffic that causes the link
to come up.
> > This is complicated,
>
> I don't think so.
That's because you haven't studied the problem for 4 years, like
me, Archie Cobbs, and Julian Eisher, and then deployed a FreeBSD
based commercial product to thousands of customers, like we did.
> > 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
Then it's a proxy for the interior and exterior DNS servers running
on your border device. It's also specially written, rather than
using off-the-shelf software, since it can't be a standard bind.
> 2. trivial to add
I guess, if you have the source code to Windows TCP on hand. Last
time I checked, this was millions of $ to license.
> > 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?
It's where the other side of your horizon lives; it's where the
external DNS server lives.
I thought you read the document I posted? This is described in
detail in the first diagram in that document.
> > 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.
You can't give a DHCP lease pointing to a DNS server on the
exterior interface, when you don't yet know the IP address of
the exterior interface. How can you configure an unknown IP
address?!?
> > Note that even though your resolver is internally authoritative,
>
> this is an oxymoron. a resolver (cache) cannot not be authoritative.
Interior port DNS server configured into the resolv.conf on the
border router, and used by applications there.
> > 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?
Because it's the industry standard DNS server?
> this was about split horizon?!
Actually, this was only about a Best Current Practices document
for a split horizon on a dial-on-demand transiently connected
border router.
> primary/secondary is:
>
> 1. Bindism
OK, I now see that you are engaged on a religious crusade against
"bind".
If you want to partcipate in this thread, please refrain from
proselytizing us about DJBDNS. Thanks.
> 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.)
Your ISP will not permit this; your ISP will *maybe* permit DNSSEC
and DNSUPDAT, however. Speaking from personal experience as "your
ISP" (IBM Web Connection NOC, Rochester, NY).
> 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.
Yes, yes, we know, it's acceptable to ignore "must implement" RFCs,
if you disagree with them, too, isn't it? You, DJB, and Microsoft
know better than all the rest of us on the IETF DNSEXT working group,
don't you?
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E1F1FC6.D5D33801>