From owner-freebsd-hackers Fri Jan 10 2:59:12 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E53537B401 for ; Fri, 10 Jan 2003 02:59:08 -0800 (PST) Received: from mail.bellavista.cz (mail.bellavista.cz [62.168.44.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FAD743F5B for ; Fri, 10 Jan 2003 02:59:05 -0800 (PST) (envelope-from neuhauser@bellavista.cz) Received: from freepuppy.bellavista.cz (freepuppy.bellavista.cz [10.0.0.10]) by mail.bellavista.cz (Postfix) with ESMTP id 4F8D429E for ; Fri, 10 Jan 2003 11:59:03 +0100 (CET) Received: by freepuppy.bellavista.cz (Postfix, from userid 1001) id 41D3A2FDCFC; Fri, 10 Jan 2003 11:59:03 +0100 (CET) Date: Fri, 10 Jan 2003 11:59:03 +0100 From: Roman Neuhauser To: hackers@FreeBSD.ORG Subject: Re: sendmail: how to get the named of FreeBSD4.7 standards compliant? Message-ID: <20030110105903.GL1196@freepuppy.bellavista.cz> Mail-Followup-To: hackers@FreeBSD.ORG 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1DE003.73BF3025@mindspring.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG # tlambert2@mindspring.com / 2003-01-09 12:48:03 -0800: > To: Roman Neuhauser 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 > > 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. -- 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message