[BlueOnyx:00223] Re: How do YOU do dns...

[Stephanie Sullivan]

> -----Original Message-----
> From: blueonyx-bounces at blueonyx.it [mailto:blueonyx-
> bounces at blueonyx.it] On Behalf Of Larry Smith
> Sent: Wednesday, January 14, 2009 7:16 PM
> To: blueonyx at blueonyx.it
> Subject: [BlueOnyx:00220] Re: How do YOU do dns...
> 
> On Wed January 14 2009 17:57, Stephanie Sullivan wrote:
> > With BQ/BO servers there is DNS management integrated into the gui
> on a
> > per-site basis (besides the server admin network services
> management). This
> > gives rise to the possibility of many ways of managing DNS records.
> >
> > In my environment the strategy I use harkens back to the days when
> I was
> > happily running RaQ3's and 4's. I have DNS services on (currently
> BQ)
> > servers that have no sites and are dedicate to DNS. I turn off most
> other
> > services and firewall them up the yin-yang. I have DNS servers: a
> primary
> > and secondary server. When I provision a site I manually enter the
> DNS
> > information into the primary server and the secondary record on the
> > secondary server. Very plain-jane.
> >
> > With BO/BQ the site can auto provision (saving provisioning time)
> on the
> > same host and enable site admins to manage domain records. This has
> some
> > obvious uses and is a nice thing to allow, mostly. As Michael
> points out
> > CMU has not backed up the DNS records on individual hosts which
> puts this
> > information at risk.
> >
> > My concern is with backup and moving sites. If a site has its
> primary DNS
> > server on the same server, then migrating or restoring to a server
> at a
> > changed IP address becomes a nightmare as the primary DNS server's
> IP has
> > change from what is in their domain registration. Oops.
> >
> > I would like a way to enable secure access to a separate DNS server
> where
> > the gui can send updates to be applied. Maybe over ssh or using
> ssl? Let
> > sites manage their DNS records without tying their DNS server to
> their
> > server's IP address.
> >
> > Maybe I'm missing something obvious here, or just being a little
> thick in
> > the head about this. I would appreciate hearing how others on the
> list have
> > setup their DNS environments and manage them. Particularly how a
> strategy
> > handles backup/restore/migration of sites from one server to
> another.
> >
> 
> Hmmm, I guess I am even more "paranoid" that you then.  I do not run
> DNS on any Cobalt, BQ or BO server at present.  For one, I  started
> in the
> "old" unix days even before the Qube and RAQ days and never quite
> "trusted"
> their DNS.  For two, in Bellsouth (now ATT) turf, they always did
> their
> reverse dns with five octets (yes, five:  73.64.71.93.208.in-
> addr.arpa -
> made-up IP but you get the point) and no "standard" server would do
> that (and
> I host a fair amount of DNS and reverse for Bell/ATT customers)...  I
> run
> eight to ten "dedicated" DNS servers that have private net
> connections
> between themselves and "trust" configuration that allows them to
> backup
> and update and such between themselves so even if one is down I can
> restore it, start its dns and it will know to update from an "active"
> server
> and keep on trucking...
> 
> But to the point, I believe that current BIND supports both "update"
> and
> transfer restrictions.  It should be easy enough to have a server
> running
> all your primary DNS, only allow transfers from "trusted" hosts; and
> only
> allow updates for various individual "zones" from their respective
> servers.
> 
> So if your DNS is at 1.2.3.4 and 2.3.4.5 hosts "foo.com" it would be
> authorized to do DNS updates to the server for the foo.com zone.  If
> 1.3.5.4
> hosts bar.com, then it would also be authorized to do updates for
> that zone,
> but not for the foo.com zone, etc etc.  Not sure how difficult this
> would be
> to make graphical (GUI based) but it is really easy to do by hand
> with
> the zone files...
> 
> --
> Larry Smith
> lesmith at ecsis.net

Larry, I may not have been very clear - I run separate servers for DNS - no
sites or users on them except the admins. I'm a little on the paranoid side
too. I use zone transfer restrictions and update controls to limit access to
zones and updates to my DNS servers only. I also firewall off most other
services and turn off everything I don't need...

I know the BO/BQ servers have gui components in place to manage DNS records
hosted on the same server. I'm not comfortable with that for a number of
reasons, but for the purpose of my suggestion was the potential added
hassles in recovering sites from a CMU  backup with a different IP when
their primary dns in their domain record would also have to be changed.

The idea of running a private net (either vlan or physically separate -
after all, don't most servers these days have 2 lan ports??? :-) is very
attractive.

It seems to me the idea behind the DNS/vsite gui integration is the primary
DNS for vsites would be in that server's DNS with secondary servers on other
servers. 

Thanks for sharing your approach.

	-Stephanie