nowadays, i'd simply put them all on the same /24 which you simply announce on different pops tcp/zonetransfer not working reliably is no longer a problem as you simply retreive those directly from the database over a seperate ip, no more old-fashioned bind related crap. so 1 /24 prefix, with one ip for your authorative nameserver, and maybe one for a resolver if needed, and the rest you leave unused.. this you simply put right next to the routers where you pick up your transit for transport to your own facilities (bet you have some rackspace and power left there too ;) making the network itself redundant rather than the nameserver... not to mention ofcourse that you fit these nameservers with solid state hdd's and ramdisks for the changing files and no moving parts so they last forever, and that whatever nameserver software you run is either an init child with respawn.. as these boxes are actually an integrated solid state router+nameserver, they have a normal static ip for the bgp/ospf session/routing and therefore can use this ip to retreive information themselves from the database and other nameservers once more and more parties buy/build routers with sufficient ram and therefore can handle larger routing tables (it's 2010 people, move on ;) you can also make the prefix smaller, let's say a /29.. our own setup is not yet a proper example here btw, so no bashing on that, but this is what our next setup will look like. kinda like ripes k-root, just used for ordinary authorative servers/resolvers pretty much plug and play (with ospf, with bgp it requires some additional configging ;) and nuke resistant, just the way we like it. this whole "you have to put 2 nameservers on two seperate subnets at two different locations" seems a bit.. pre-1993 to me. plus, why only 2, why not... 20 or so, all in different parts of the world and let bgp handle the rest. -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Tue, 17 Aug 2010, Matthew Palmer wrote:
On Mon, Aug 16, 2010 at 06:08:02AM -0700, Owen DeLong wrote:
On Aug 16, 2010, at 6:03 AM, Chris Adams wrote:
Once upon a time, Patrick W. Gilmore <patrick@ianai.net> said:
1) Use different prefixes. A single prefix going down should not kill your entire network. (Nameservers and resolvers being unreachable breaks the whole Internet as far as users are concerned.)
How do you do this in the IPv6 world, where I get a single /32? Will others accept announcements of two /33s to better handle things like this?
The better solution is to trade secondary services with some other provider. Sure, it's a bit of a pain keeping up with the new zones to be added and old zones to be removed back and forth, but, it's a great way to have your authoritative servers truly diverse and independent.
At $JOB[3], where I was responsible for this sort of thing, a small amount of shell scripting behind inetd on the master[1], and slightly more shell scripting behind cron on the secondaries[2], and all our problems were solved for all time.
- Matt
[1] Read /etc/named/zones/* mangled the (standardised) filenames to get a list of the zones, and dumped it on stdout, which went out on a high port that inetd was listening on.
[2] nc to the master on the relevant high port, read the list and write out an automated named.conf fragment. Also use a bit of md5sum to detect when the list changed, so we know when to reload named on the slave.
[3] Subscript, not footnote.