   |
||
   |
||
|
|
|
 |
|
|
|
|
At 12:08 PM +0200 2005-09-08, martinez_ja5@tsm.es wrote: I am not sure if I understood the diferences on server types,
but I 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 Secondary != non-authoritative. If a server is secondary for a zone, then it is fully authoritative for that zone. Of course, the same 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
This isn't the way primaries work. Primaries don't share out data
to other primaries, they instead share out data to secondaries.
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 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 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 Does this architecture look fine or is just a nerd mess? Aren't
there 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.
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. -- "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania SAGE member since 1995. See <http://www.sage.org/ for more info.
|
 |
Odd problems trying to make use of libbind as a replacement resolver SEO One-Way Web Links: 5 Strategies Getting The Kinks Out Of Links Yahoo Boasts Size of Its Search Engine Index Promoting Your Business Website - The never-ending work to get traffic |
 |
|
DNS
delegation based on both location and organization
Latest
articles |
|
|
|
Ze Network © 2007 Free Space Australia Inc. All rights reserved. |
