Numbering nameservers and resolvers
Sven Olaf Kamphuis
sven at cb3rob.net
Tue Aug 17 12:11:56 UTC 2010
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
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
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.
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 at 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 at 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
>> 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
> At $JOB, where I was responsible for this sort of thing, a small amount
> of shell scripting behind inetd on the master, and slightly more shell
> scripting behind cron on the secondaries, and all our problems were
> solved for all time.
> - Matt
>  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.
>  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.
>  Subscript, not footnote.
More information about the NANOG