"Hidden" Primary DNS
zeremy
Hi,
I'm in the middle of redesigning our dns infrastructure.
I'm familiar with bind 9(read Oreilly book 3 times) but never deploy
at an ISP level*well now I have the chance so help me god*.
I've read about "hidden" primary concept and think it's a good idea
but I need opinions/suggestions from the experts :)
Here's the scoop.
Currently we own 1 Primary DNS server within the ISP and 3 secondary
servers reside in another country which is out of our control.
We managed to get a pair of server for our dns and we came out with
the following simple layout:
The current primary dns server i.p./hostname will become one of the
secondary server and all our dialup and broadband customers will point
at it as their default dns server.
Our new primary dns server will be a "hidden" primary in such a way
that it's not registered at network solutions, the root servers won't
know, it's only for managing dns basically.
Another secondary dns server will be deployed as a backup.
recursive restriction apply to both secondary servers which comes with
512MB of RAM. Bind will be run in a chroot environment on the
secondary servers running Solaris 8/SPARC... which I'm still looking
for an accurate bind/chroot howto for solaris 8*anybody?*
My concern is downtime.
I think it will be minimal.
Just plug in the new servers once I verify everything works and
everything should be normal?
Many thanks for any help :)
Simon Waters
zeremy wrote:
>
> recursive restriction apply to both secondary servers which comes with
> 512MB of RAM. Bind will be run in a chroot environment on the
> secondary servers running Solaris 8/SPARC... which I'm still looking
> for an accurate bind/chroot howto for solaris 8*anybody?*
BIND 9 chroot is trivial, how much information do you need?
Basically run as a non-root user, and run in a directory with
only the files needed to configure BIND, named.conf, zones
directory, var directory for temporary files, and an rndc.conf.
I have a /dev/random (Linux) in the jail, but I don't believe it
is used for anything important, unless you are running DNSSEC.
You don't seem to be seperating recursive and authoritative
servers in your configuration?
zeremy
Simon Waters <Si...@wretched.demon.co.uk> wrote in message news:<akdnod$at2u$1...@isrv4.isc.org>...
The original plan was a split service nameserver configuration as
described in CERT Aug 2002 Article on securing a nameserver.
Primary DNS Server will be an advertising server,
and the secondary dns server will be a resolving name server for our
customers.
However for some security and other reasons,
(like...our Primary DNS Server = modified bind + sql + apache + sql),
we think it's better to leave the primary dns server only for managing
dns,
and let the secondary servers do the naming services.
(i.e. both advertising ns for everyone and resolving ns for specific
networks)
so on the secondary servers, the named.conf would look like:
options{
...
allow-recursion{internal;};
...
};
so correct me if I'm already confused here heheh...,
Our Primary DNS server will be a "hidden" primary as it will not be
listed in our dns registry at network solutions so the root servers
won't advertised our primary dns to the world.
Of course, our secondaries will sync with our "hidden" primary dns
server.
all our secondaries will be listed in our registrar
as for the chroot bind 9 on solaris 8,
we won't be implementing dnssec yet.
I've search around the net but most of them (howto,cookbooks) written
for linux system or bind 8 running solaris 7..
Probably the best reliable source I could find is by rob thomas
http://www.cymru.com/Documents/bindjail-solaris.html
Assuming not much difference between sol8 and sol7,
it should work but I'm not too sure myself.
u n d e r a c h i e v e r
>
>
> However for some security and other reasons, (like...our Primary DNS
> Server = modified bind + sql + apache + sql), we think it's better to
> leave the primary dns server only for managing dns, and let the secondary
> servers do the naming services. (i.e. both advertising ns for everyone
> and resolving ns for specific networks)
if you are designing a system from scratch, and security, split horizons,
useability and database integration are of interest to you, i suggest you
look at the djbdns suite of programs, and some of the database / LDAP
integrations you can use with it.
--
u n d e r a c h i e v e r
Kevin Darcy
u n d e r a c h i e v e r wrote:
> On 27 Aug 2002 06:57:13 -0000, zeremy <zer...@hotmail.com> wrote:
> >
> >
> > However for some security and other reasons, (like...our Primary DNS
> > Server = modified bind + sql + apache + sql), we think it's better to
> > leave the primary dns server only for managing dns, and let the secondary
> > servers do the naming services. (i.e. both advertising ns for everyone
> > and resolving ns for specific networks)
>
> if you are designing a system from scratch, and security, split horizons,
> useability and database integration are of interest to you, i suggest you
> look at the djbdns suite of programs, and some of the database / LDAP
> integrations you can use with it.
Not to mention looking at all of the other tools/utilities/doodads that you
have to download, build, install and configure on your system(s), just to get
the damned thing to work. And hopefully you don't have a sysadmin style that
differs even an iota from DJB's, because then you're basically SOL...
- Kevin
u n d e r a c h i e v e r
>> if you are designing a system from scratch, and security, split horizons,
>> useability and database integration are of interest to you, i suggest you
>> look at the djbdns suite of programs, and some of the database / LDAP
>> integrations you can use with it.
>
> Not to mention looking at all of the other tools/utilities/doodads that you
> have to download, build, install and configure on your system(s), just to get
> the damned thing to work. And hopefully you don't have a sysadmin style that
> differs even an iota from DJB's, because then you're basically SOL...
i refered to a 'suite' of programs, did i not? this is one of the prinicple
benefits of the djb approach: if you don't need zone transfers, dont use
axfrdns; if you don't do caching/recursion, don't use dnscache.
the upshot is modular, functional and very very secure.
--
Jim Reid
>>> the prinicple benefits of the djb approach: if you don't need
>>> zone transfers, dont use axfrdns; if you don't do
>>> caching/recursion, don't use dnscache.
Calling this a benefit is debatable. [One mans' mean it another poison
I suppose.] A bunch of programs like this adds complexity, which is a
security problem itself. A naive adminsitrator needs to figure out
what all these myriad of programs are for, how they're inter-related,
which ones they need and don't need. And then figure out how to get
them to work. Let's not forget the maintenance hassle of keeping track
of which of these programs need to be upgraded or re-installed. And
all that's before we get to all the other weird stuff that needs to
be installed and configured on your computer so you can run djbdns.
BTW, the newsgroup is gatewayed into a mailing list. So it's
anti-social to provide a bogus email address. It doesn't even prevent
spam: the main reason some people follow this irritating practice.
Robert Kropiewnicki
Jim,
I'm not quite sure at what you're getting at here. Shouldn't an admin
know what the programs running on his server are doing regardless of
whether it's one large comprehensive apps or a number of small,
inter-related apps?
You are correct. It is harder to keep track of many different
applications than it is to keep track of one. But, depending on your
needs, the payoff might be worth it. After all, is there anything more
annoying than having to upgrade an app on a production system due to a
bug or exploit in a portion of the app that you don't even need or for
that matter want? I know for sure that it drives me crazy every time I
have to patch a Win2K server due to an exploit related to Outlook
Express or Windows Media Player. The modularity that you appear to
dislike is at the very heart of why I love Unix and Linux....install
only what you need, use the right tool for the right job.
Regards,
Robert Kropiewnicki
Jim Reid
Robert> I'm not quite sure at what you're getting at here.
Robert> Shouldn't an admin know what the programs running on his
Robert> server are doing regardless of whether it's one large
Robert> comprehensive apps or a number of small, inter-related
Robert> apps?
Of course! But life's not like that. How many admins *really* know
what runs on their systems or what that stuff is for? Or keep up to
date with patches. Or take regular backups. Or.... I've lost count of
the number of places where I've seen UNIX systems running all sorts of
foul crap because that was the way the OS came out of the box when it
was installed. "BIND4 must be OK, because that's what was shipped with
HP-UX/Solaris/whatever".
This thread now has little to do with BIND. It should either be moved
elsewhere or take off-line.