Date: Wed, 21 Feb 96 16:04 MET From: me@tartufo.muc.ditec.de (Michael Elbel) To: coredump@nervosa.com Cc: hackers@freebsd.org Subject: Re: An ISP's Wishlist... Message-ID: <m0tpG6D-000Pa6C@tartufo.muc.ditec.de> References: <199602192116.WAA20624@keltia.freenix.fr> <Pine.BSF.3.91.960219184854.1181D-100000@nervosa.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In lists.freebsd.hackers you write: >On Mon, 19 Feb 1996, Ollivier Robert wrote: >> It seems that Narvi said: >> > > I've done this, it wasn't too difficult. I'm now running three >> > > nameds on our firewall bastion, one to serve the inside network >> > > with everything on the outside hidden and a wildcard MX-record >Why not just run 2 named servers on 2 seperate machines ( 2 total ). The >bastion host would run named, and any name queries to the protected >network would be forwarded to an internal host running the second named >server, which of course, by default (firewalled), only trusts the >bastion host. This way you only run 2 named servers, and protect the >secrecy of the internal hosts. Of course, the only problem I can think >of is the possibility of the bastion named caching the lookups and >outsiders being able to see internal hostnames via the cache. You also want to be able to have *some* information about the company you're protecting visible to the outside. Consider our real scenario here: There's ditec.de and you can see, e.g. www.ditec.de ftp.ditec.de and mail.ditec.de from the outside, they're all hosts in our screened subnet. This information has to be shown to the outside world, otherwise no communication with our company from the outside would be possible. Thus, you need one server to serve the outside part of ditec.de. Now we need another server who serves the inside part of ditec.de, containing all the machines inside our firewall. There goes your second server. The bastion is special in that it needs to know about *both* the inside part of ditec.de for authentication of connections and mail delivery, as well as the rest of the world, so it knows about the machines the proxies and other agents want to connect *to*. You cannot use the external server or you wouldn't know about the internal part of ditec.de. Nor can you use the internal server, because it knows zilch about the rest of the world (it actually is its own root name server). Your only solution is to install a third name server that knows both the inside *and* the outside. I've installed it as a secondary of ditec.de, using the external server as forwarder. Incidentially you *don't* want neither external nor internal hosts to be able to query it, so binding to the local interface for that thing is a good idea. Additionaly we *do* have internal ftp and www servers, ftp.ditec.de and www.ditec.de which are on the internal network, giving you name redundancy from the view of the bastion that can connect to both, but that's another story :) Actually, the story is even more complicated, since DITEC has two separate internet connections and spreads over some 20 subdomains internally, but I hope you get the idea how this scenario might affect even smaller companies than ours. Btw., Everything I'm talking about here (name servers, ftp servers, www servers, news servers, of course runs exclusively FreeBSD :) Michael -- Michael Elbel, DITEC, Muenchen, Germany - me@muc.ditec.de Fermentation fault (coors dumped)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0tpG6D-000Pa6C>