Master to Slave Schedule to Avoid Poison Propegation

[Danny Mayer]

Brad Knowles wrote:
> At 6:29 AM -0700 2005-08-12, Danimal wrote:
> 
> 
>> So for example if the master somehow became compromised we could remove
>> it from the network before it infected the DNS records of the slave.
>>

I think you're confused. An authorative nameserver's data cannot be 
compromised, at least not via cache poisoning since it will never accept 
records for zones for which it is authorative. Therefore it won't 
propogate it to a slave and in any case, since the SOA record won't have 
incremented its serial number the slave won't transfer the zone.

>> So two questions:
>>
>> 1) Is this a common goal?
> 
> 
> 	I've never heard it before, no.
> 
> 
>> 2) What setup would achieve this goal?
> 
> 
> 	Hmm.  Well, I guess you could turn off NOTIFY, and you could set 
> the refresh period to be very long.  However, if the compromise were 
> to happen right before a refresh, you could still have both servers 
> compromised very quickly.
> 
> 	Better might be to have all of the servers run as primaries, and 
> handle the zone transfer via rsync or some other out-of-bound 
> mechanism.  That would give you a chance to check the data before 
> copying it to the so-called secondaries.  But that's assuming that 
> you can actually detect a compromise before the data is copied.
> 
> 

You can always run a hidden master so that it cannot be reached from the 
outside. The slaves then are the registered nameservers but will only 
get updates from the master which is not publicly available.

> 	Of course, if you completely separate your authoritative servers 
> from the caching/recursive servers, then the authoritative servers 
> can't be polluted or poisoned, and the only thing you'd have to worry 
> about there is people breaking into the machines and manually 
> modifying your zone data.
> 
> 	The caching/recursive servers might be able to be 
> polluted/poisoned, but so long as they are caching-only and running 
> modern code (like a BIND-9.3.1 or other recent version of BIND-9), 
> that should pose a lesser risk to your clients.
> 
> 
>> If a setup like this is advisable it would seem there are two options:
>> multiples masters or master/slave with delayed zone transfers.  I have
>> some ideas about what might work but I won't confuse this topic by
>> interjecting incorrect information.
> 
> 
> 	I think you're going to have a tough time managing to do this.
> 

Agreed, but there are far better solutions. See above.

Danny