dns topology and zone transfer over wan links

Warren Kumari warren at kumari.net
Thu Oct 16 01:25:14 UTC 2014


On Wednesday, October 15, 2014, Darcy Kevin (FCA) <kevin.darcy at fcagroup.com>
wrote:

>  I’m sorry to disappoint you, but I actually think, based on the info
> you’ve shared thusfar, you’re probably on the wrong side of this argument.
>
>
>
> Zone transfer has been incremental, by default, for some time now, so I
> wouldn’t worry too much about the network traffic (unless you’re making a *
> *ton** of changes to the zone on a regular basis, or the WAN links
> between your datacenters are truly pathetic).
>
>
>
>
Yah. Unless you are publishing huge amounts of non-DNS stuff (like all the
lyrics to all the songs by all the Aerosmith tribute bands) your DNS
transfers should be tiny -- even if you don't do IXFR...



> Chances are, whatever tool (which you didn’t specify) that you’re using to
> maintain those “multiple masters” in parallel, including all of the signing
> (I assume you’re referring to DNSSEC), generates about as much, or perhaps
> even **more** traffic, than would be required to replicate the changes
> from DC1 to DC2. This is especially true if you daisy-chain one of the DC2
> boxes from the other. If you do that, of course, you’d want to put into
> place an appropriate NOTIFY configuration, so that changes propagate in a
> timely fashion. That way, you’d only need one round of cross-datacenter
> replication, not two, to get the data from DC1 to DC2 and visible on all 4
> nameservers. In other words, if DC1a is the master, it replicates to DC1b
> and DC2a. DC2a then replicates in daisy-chain fashion to DC2b, but since
> NOTIFY is set up, all of this takes place quickly.
>
>
>
> As for security, you can TSIG-sign all zone transfers to provide
> authenticity. Or, do you think you need to actually **encrypt** the data
> being replicated between datacenters? If that’s the case, then you’re
> looking at some other method of replication besides zone transfer, e.g.
> rsync-over-ssh to update the zone files, with perhaps an rndc to reload the
> zone(s) remotely whenever it/they change(s).
>
>
>
 Or a VPN, or ssh tunnel, or similar...

>
>
> Or, you could just buy a purpose-built DNS product (e.g. Infoblox) that
> does secure zone-data replication automatically through tunnels (no, I
> don’t get a referral bonus for mentioning them J
>
>
>
> - Kevin
>
>
>
> *From:* bind-users-bounces at lists.isc.org
> <javascript:_e(%7B%7D,'cvml','bind-users-bounces at lists.isc.org');>
> [mailto:bind-users-bounces at lists.isc.org
> <javascript:_e(%7B%7D,'cvml','bind-users-bounces at lists.isc.org');>] *On
> Behalf Of *Rob Kovic
> *Sent:* Wednesday, October 15, 2014 5:41 PM
> *To:* bind-users at lists.isc.org
> <javascript:_e(%7B%7D,'cvml','bind-users at lists.isc.org');>
> *Subject:* dns topology and zone transfer over wan links
>
>
>
> Hi folks,
>
>
>
> I administrating two Data Centers in separate geographic locations.
>
>
>
> The current DNS Bind set up I have is 1 master and 1 slave per DC on DMZ.
>
> Slaves are publicly accessible.
>
>
>
> The 2 masters in DC1 and DC2 do not communicate and there is no cross DC
> DNS communication in regards to public zones, e.g. all changes on masters
> must be identical and dual.
>
>
>
> I believe the same is a good redundant model, saving on network traffic
> and providing other benefits.
>
>
>
> A colleague of mine is keen on changing this set up to having 1 master in
> DC 1, one slave in DC1 and 2 slaves in DC2. His idea is to sign zones on
> the master/slaves and transfer them over WAN links to DC2 slaves. He does
> not accept the concept of having a VPN between the 2 DMZs either.
>
>
>
> Can you suggest a good security article covering the topic and risks
> associated with the same?
>
>
>
> Thanks,
>
> RK
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20141015/82bf60c2/attachment-0001.html>


More information about the bind-users mailing list