From owner-freebsd-hackers Fri Jan 10 11:48: 5 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 728E737B405 for ; Fri, 10 Jan 2003 11:47:59 -0800 (PST) Received: from flavatown.mail.pas.earthlink.net (flavatown.mail.pas.earthlink.net [207.217.120.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1537443F1E for ; Fri, 10 Jan 2003 11:47:58 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from stork (stork.mail.pas.earthlink.net [207.217.120.188]) by flavatown.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0AJYHV05679 for ; Fri, 10 Jan 2003 11:34:17 -0800 (PST) Received: from pool0200.cvx22-bradley.dialup.earthlink.net ([209.179.198.200] helo=mindspring.com) by stork with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18X4uY-0007KA-00; Fri, 10 Jan 2003 11:33:47 -0800 Message-ID: <3E1F1FC6.D5D33801@mindspring.com> Date: Fri, 10 Jan 2003 11:32:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Neuhauser Cc: hackers@FreeBSD.ORG Subject: Re: sendmail: how to get the named of FreeBSD4.7 standards compliant? 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a48a891576e985e14d73949c0e4799d3b0a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c 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 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 > > > > 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