DNS delegation based on both location and organization

[Kevin Darcy]

A lot of good advice below, but one thing Brad didn't mention was 
NOTIFY. One can control how quickly changes propagate to stealth slaves 
via "also-notify", and if one really wishes to, one can 
minimize/optimize change-propagation even to published slaves via BIND 
9's "notify explicit" modifier...

- Kevin

Brad Knowles wrote:

>At 12:08 PM +0200 2005-09-08, martinez_ja5 at tsm.es wrote:
>
>  
>
>> I am not sure if I understood the diferences on server types, but I think
>> I want all DNS servers to have full DNS records for the quickest response
>> (plenty of RAM available).
>>    
>>
>
>	A full-mesh network is one way to make sure that you have maximum 
>availability and speed of resolution, but it is not necessarily 
>always the best solution.
>
>  
>
>>                             From that I understand DNS servers at Madrid
>> office should be both primary servers of all Madrid local zones
>> (madrid.finance.corp.com, madrid.sales.corp.com, ...) and all other
>> servers (those in Barcelona, Valencia, etc) should be secondary
>> (non-authoritative) for Madrid zones.
>>    
>>
>
>	Secondary != non-authoritative.
>
>	If a server is secondary for a zone, then it is fully 
>authoritative for that zone.
>
>  
>
>>                                        Of course, the same architecture
>> would be applied for all other cities, two local primary servers and
>> 4x2 secondary remote secondary servers.
>>    
>>
>
>	Generally speaking, you usually want only one primary server for 
>a zone, and a set of secondaries.  All changes to the zone are made 
>only on the primary, and then when you reload the zone on the 
>primary, that information will automatically be distributed to the 
>secondaries.
>
>	If you need two nameservers for each city, make one of them 
>primary and the other secondary.  Keep in mind that you can have as 
>many secondaries as you want for a zone, but you don't necessarily 
>have to list them all as official authoritative servers within the 
>zone content itself.  The extras would be "stealth" secondaries -- 
>they get a copy of the data, they answer authoritatively for anyone 
>who asks them, but since they're not advertised they should get 
>relatively few queries for that zone.
>
>  
>
>> To centralize management also I thought I would add another server
>> primary for all zones, hidden and behind a firewall to be a master
>> of everything, safe repository of data and source of all changes to
>> sync into all other servers. (This would be VitalQIP+oracle management).
>>    
>>
>
>	This isn't the way primaries work.  Primaries don't share out 
>data to other primaries, they instead share out data to secondaries. 
>You could do your own out-of-band communication method to share data 
>between primaries, but that would be outside the scope of DNS and 
>BIND.
>
>	You can have a stealth primary and have all other servers be 
>secondary to that primary, and all advertised servers within the zone 
>are actually secondaries and not primary.  Since either primary or 
>secondary would answer authoritatively, the clients don't care.
>
>	If you want to make all your changes in a centralized location, 
>that's fine.  But you're getting confused on the terminology between 
>primary and secondary.
>
>  
>
>> It looks like a little overkill but:
>> - I do not want to use cache servers because cache misses get too
>>      long to get resolved.
>>    
>>
>
>	I don't think that this would really be too much of an issue, but 
>I'm willing to take this as a given.
>
>  
>
>> - I need centralized Oracle based management.
>>    
>>
>
>	No problem.  The primary can be whatever you want, and use 
>whatever back-end technology you want.  The secondaries don't care, 
>since they'll get their data via zone transfers and then store that 
>content locally in the format of their choice.  You just have to make 
>sure that the primaries support zone transfers, and you're fine.
>
>  
>
>> - I need local resolution and redundancy (I even need load balancers
>>      for the quickest response time and highest availability)
>>    
>>
>
>	Load-balancing switches are definitely a good idea for HA, but 
>they generally don't contribute much of anything on the performance 
>side of the equation unless you're doing tens to hundreds of 
>thousands of DNS queries per second.  I built what was the world's 
>largest caching nameserver farm at AOL, and that whole cluster of 
>machines was capable of handling at least 32,000 DNS queries per 
>second (our testing tools weren't able to push the system hard enough 
>to find out what the real top-end was), but now you can get 
>reasonably low-cost individual boxes that can provide performance 
>approaching or even exceeding those levels.
>
>  
>
>> - Second and third domain levels would be hardly adjustable to my needs
>>      for simpler DNS
>>
>> Does this architecture look fine or is just a nerd mess? Aren't there too
>> many primary servers? Would make any difference if I set them all to
>> secondary but the centralized one?
>>    
>>
>
>	Having all of them be secondaries to the single central primary 
>would definitely be the way to make the system easier to manage, but 
>you will have to keep in mind that you will have to push out 
>/etc/named.conf changes to each of those machines if you add or 
>delete any zones that they should be secondaries for.  Zone content 
>changes will be no problem -- that will be handled automatically.
>
>	Of course, this does give you a Single Point of Failure (SPOF), 
>which will hurt your overall system availability percentage, due to 
>the single central management system.  However, since this is a 
>stealth primary, and it wouldn't be advertised anywhere within any of 
>the zones it serves, this would only prevent updates to the zone 
>contents -- the existing zone contents would continue to be served by 
>the secondaries.
>
>
>	The bigger issue for you is going to be determining which 
>machines at each site need to be advertised as authoritative for the 
>zones, and which ones can be stealth secondaries.  That choice is 
>entirely up to you.
>
>	But keep in mind that you don't want to list too many 
>authoritative servers (typically no more than four or five), because 
>you don't want to cause the responses you hand out to exceed the 
>512-byte limitation of typical DNS responses via the UDP protocol. 
>Trust me, you do *not* want to know what kind of weirdness tends to 
>manifest itself when you start causing truncation, which results in 
>DNS queries having to be re-tried with TCP, etc....
>
>  
>