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: s...@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 <patr...@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.
