Date: Thu, 09 Jan 2003 12:48:03 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Roman Neuhauser <neuhauser@bellavista.cz> Cc: Peter Much <pmc@citylink.dinoex.sub.org>, hackers@FreeBSD.ORG Subject: Re: sendmail: how to get the named of FreeBSD4.7 standards compliant? Message-ID: <3E1DE003.73BF3025@mindspring.com> References: <20030101181330.C8233@disp.oper.dinoex.org> <3E134659.78028611@mindspring.com> <20030106173652.A495@disp.oper.dinoex.org> <20030109132202.GG1196@freepuppy.bellavista.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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 (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. 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. > 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. If you reference a completely authoritative interior server, with no forwarding, and the resolver stops there, then the exterior server is not referenced. This is complicated, both as noted above, for Windows clients (it would require a second IP address on the interior network, minimally, to resolve), and by the fact that the IP address of the external interface is unknown until after link-up, 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. Note that even though your resolver is internally authoritative, for the Internet's view of the world, an external resolver for the domain is likly authoritative, instead. Specifically, you will be running hosted primary for www.example.com and for the MX records for example.com. 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. The problem comes down to round-tripping local changes to the DNS, e.g. DHCP leases, etc.. If you can solve the round-tripping problem, you can, in fact, deal with this via the DNSNOT mechanism. 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 It is a trivial change, but can increase the root load. The way to avoid this is to mandate caching, and only transit to the root if the name server is not where it was previously (e.g. as a result of an ISP reconfiguration while the secondary was offline). An expiration time for the cache is not relvent, in that this has to do with claim of authority; if the SOA is stale, then it serves as the timeout. In addition to this, to resolve authority issues, we have to recognize the seperation of control between transiently and non-transiently connected servers. I did not mention this before, since the problem under discussion was how to *avoid* lookups, requiring a link-up operation, for fully qualified DNS names which were not defined locally; making this modification requires careful reconfiguration. Specifically, the external primary is considered to be in a delegated subdomain of the locally authoritative domain; for lookups direct to the name server, the subdomain is implied in the operation. This, too, requires a modification of the DNS server implementation. The simplest way is to replace the proposed DNAME extension with another. Specifically, Example #4 in the following document will cover this case: Proxy Subdomain Delegation <draft-lambert-dns-pns-00.txt> ftp://ftp.whistle.com/pub/terry/drafts/draft-lambert-dns-pns-00.txt In this example, we rename requests in one domain to be requests in another domain, and proxy them; as an example, we can proxy requests for www.ext.example.com (the "external web server for the company example.com") to an external primary that appears to the Internet as "example.com". The proxy operation causes the lookup to occur in the "delegated subdomain ext.example.com", which in fact is a delegated proxy lookup in the authoritative server for ext.example.com to the externally authoritative server example.com. This "www.ext.example.com" interior to the proxy becomes "www.example.com" exterior to the proxy, in the external primary DNS that *also* thinks it is authoritative for "example.com". The issue is that if your border server is not truly primary, and not truly authoritative, then referencing the server that is is arbitrarily difficult without this. -- 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?3E1DE003.73BF3025>