Architecture opinions

[Kevin Darcy]

There's no option in BIND (nor, am I aware, in any other DNS resolver 
implementation) to use TCP-only for queries, and the TCP-failover 
mechanism built into DNS usually only kicks in after a response to a UDP 
query comes back with truncation indication. So essentially you couldn't 
have any of your nameservers in a given tier communicate to any 
nameservers in any other tier or in the corporate environment. Each tier 
would basically be its own isolated DNS infrastructure, with each 
relevant zone needing to be defined as "master" on one of the 
nameservers in that tier, and then you'd have to have some sort of 
custom mechanism for maintaining the information in each "master" server 
(you could perhaps use Dynamic Update for this, from a central "console" 
in the corporate environment, forced to use TCP connections out to the 
various "master" servers in each of the tiers). *Within* each tier, 
however, I assume there are no firewall restrictions, so you could set 
up one or more slaves for load-sharing and redundancy. You could even 
set up delegation and/or caching servers within a tier, if you wanted, 
since in DNS terms, each tier would be like a miniature version of an 
enterprise or the Internet.

Or, instead of setting all of that up, you could throw in the towel and 
just rsync a central /etc/hosts file to all of the DNS clients in all of 
the tiers. It would be a shame to abandon DNS like that, but your 
super-restrictive environment there negates most of the benefits of the 
DNS protocol...

                                                                         
                                       - Kevin

Steven Hajducko wrote:
> Hi,
> I've been given the task of completely redesigning our DNS for all of
> our environments and I'd like some opinions or advice on how to do this.
> First, a little background.
>
> Each environment we have is split into 3 tiers ( typical web-app-db ).
> Each tier is firewalled off from each other.  Each tier is also
> firewalled off from our corporate environment.  We have 5 of these
> environments.  Our security team does not allow UDP packets to traverse
> firewalls.  We're also only allowed to perform single direction tcp
> initiation, meaning that I can initiate connections from the corporate
> network into one of the tiers of an enviroment, but that tier is not
> allowed to initiate a connection the other way.
>
> Also, each tier is only allowed to initiate a connection one way to the
> next tier within it's own environment. ( web to app, app to db. )
>
> The main goals of the project are:
>
> 1) One centrally located server to manage all records for all
> environments.
> 2) Cut down as much as possible on how many DNS servers are needed.
>
> There are some further complications, but I don't want to make this
> impossible yet. :)
>
> I'm not too concerned with the centrally managed server.  If needed, we
> can write our own application/database to generate zone files from the
> database.  I'm more worried about how to cut down on the amount of DNS
> servers in each tier.  At the first look, it seems as if we would need 2
> per tier ( for HA purposes ), one to be the master for that tier's zones
> and a slave server for purposes of redundancy.  Because of some other 1
> off tiers and environments, this ends up being about 66 DNS servers.
> Not exactly a system admin's dream to manage.
>
> At this point, I'm somewhat at a loss on how to accomplish this.  I was
> thinking of creating some type of persistent tunnel through the
> firewalls to jump back through to the db tier and using views to figure
> out which zones to serve which requests, but I'm not sure if that'd work
> too well.  That or I'm just going back to host files. ;P
>
> Anyway, any advice or perhaps a finger pointing at something to look at
> as a possible solution would be extremely welcomed. :)
>
> Thanks.
>
> sh
>
>
>
>
>
>
>