Numbering nameservers and resolvers

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 
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 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
>>> 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.
>