Hi Folks,
I am needing to renumber some core infrastructure - namely, my nameservers and my resolvers - and I was wondering if the collective wisdom still says heck yes keep this stuff all on seperate subnets away from eachother? Anyone got advice either way? Should I try to give sequential numbers to my resolvers for the benefit of consultants ... like .11, .22 and .33 for my server ips?
Mike-
Composed on a virtual keyboard, please forgive typos.
Resolvers being easily memorable is nice, since they get keyed in by IP.
Authority servers are referred to by name, so IP matters less.
Definitely keep an authority server in another prefix if you can, and resolvers in different prefixes is also nice -- but that's more a question of redundancy, not numbering.
Other than that, go dense. Addresses are starting to get scarce.
Aria Stewart
Microsoft used to have all their DNS servers on one /24. Nine years later,
you can still use Google on just 'microsoft dns server failure subnet' and
find this on the second page of over a million hits:
http://www.wired.com/techbiz/media/news/2001/01/41423
(OK, so our local resolvers are in one /24, but it's a bridged VLAN across our
entire campus, the servers are physically in buildings several miles apart, and
if you can't reach at least one of them, it probably means our campus core
network is hosed enough that you're not going to do anything with a DNS
response anyhow... Our authoritative servers are split across 2 different AS's
in 2 different states.)
Whatever gave you the idea that collective wisdom could *possibly* have
moved away from "spread it out as far as you can to avoid single points of
failure"?
If you have a dedicated subnet for /32s (e.g., router loopback interfaces), i'd pick from there.
if you eventually require geo-redundancy or want to load balance your queries, it's much neater injecting them into your igp rather than having a few /32's injected from an otherwise nice clean /24.
I am also a fan of keeping your recursive and authoritative ip addresses separate. Not only is this much more modular, it can be more secure; see http://cr.yp.to/djbdns/separation.html
for authoritatuve servers, i try to have one on a very different
backbone on a distant continent. i make deals with friends. there have
been just too many failures where servers were in the same facility, or
behind the same routing, or on a single backbone. see rfc 2182.
for customer- and infrastructure-facing caches, i try for as different
routing domains and peering/x-stream exits as i can while keeping them
easily reachable by their clients.
randy
For resolvers, I guess it would make sense to advertise them as /32s as
dynamic prefixes coming from some SLB device...
You can have multiple VIPs, each representing a different POP/network
domain...
Arie
Take a IPv4 /24, /28, whatever size you might think you need and an IPv6
/64 and make it your 'service prefix', then anycast this inside your
network and do the standard 'bgp daemon on the box, monitor the local
service' trick and kill the announcement when the service does not work,
presto.
As for the actually numbers, just keep them simple. Using port-numbers
(53 = DNS, 25 = SMTP etc etc etc) where possible is easy for at least
the more technical folks, of course IPv4 only goes up to 255, IPv6 does
not have that issue.
Greets,
Jeroen
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.
Owen
In IPv6 you should be able to advertise up to /48 with no problem...
Arie
Oooooooooobviously I was not thinking clearly, since I was only considering v4. =)
But you do what you can. Some people have only a single v4 prefixes as well. If you can't use more than one prefix, then don't.
Other good suggestions were things like ensuring the default exit point for each NS was a different vector. If you have only one exit point, that is not possible. But it does not mean the suggestion is bad.
Hi Folks,
I am needing to renumber some core infrastructure - namely, my
nameservers and my resolvers - and I was wondering if the collective
wisdom still says heck yes keep this stuff all on seperate subnets
away from eachother?
Authoritative name servers should be on different networks, preferably in entirely different facilities. You've already had good suggestions about swapping secondary service, etc.
Resolving name servers should be separate from authoritative ones, but there is no reason that they can't be on the same subnet(s).
It's still a good idea to have more than one resolver on each local network, but there is also no reason they can't be on the same subnet as well. For larger and/or highly performance sensitive installations anycasting the resolvers (so that you only need 1 IP in resolv.conf) is becoming more popular.
Anyone got advice either way? Should I try to give sequential numbers
to my resolvers for the benefit of consultants ... like .11, .22 and
.33 for my server ips?
This sounds more like a local preference issue. Presumably the people who don't type into config files for a living will have their hosts configured with DHCP, and those who do will know how to copy and paste. 
hth,
Doug
PS, if you need more formal help, see the URL below.
Everyone I know that is clued in this arena goes out and (even as a $sfi_network) BUYS transit/colo/somethingelse from another network (or does it via trade/barter/part of peering agreements, you get the idea).
There are also people you can outsource this stuff to as well to make sure it's done right. Honestly, I'm surprised both at how many and how few people do this. Those that have the network capability pay someone else to do DNS at times, and those who should pay to have a reliable service hack it on some poor network infrastructure.
Some people even provide an API or web interface to manage secondary dns servers to help out those in need.
Try clicking here: http://www.google.com/search?q=free+secondary+dns
- Jared
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.
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.
Sven,
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.
There's an important component that is missing from the above. It's one thing to have a single nameserver hosted in such a manner, but through operational integration and history there are still a lot of domain names that are not fault tolerant.
I remember "in recent years" a ccTLD that ended up without functioning services as a result of poor nameserver site selection.
Ideally you would have a system with two geographically diverse nameservers for a domain, under seperate (routing) administrative control.
One of my former employers backhauled all their legacy nameservers to a single site, eg: e[0-2].ns.voyager.net.
While they were originally on diverse subnets and geographical locations, this appears to have changed.
Selecting a site outside of your control is valuable. When I was hostmaster@cic.net, we "traded" with mr.net. These days, if I were in the same role, I would want to have three instead of two. Asia, Europe and US someplace. If US only, east, west and central.
If you look at ntt.net, our "off-net" resolver is 69.36.249.36
This means if there is a ntt meltdown, there's a good chance you can still resolve related names off-net.
- Jared
nowadays, i'd simply put them all on the same /24 which you simply
announce on different popstcp/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.
tcp/zonetransfer can also be configured to run off of a different IP
address, for example, the native IP of the box.
This works just fine.
In BIND, you're looking for
transfer-source ${qaddr} port ${qport};
IIRC.
... JG
Once upon a time, Sven Olaf Kamphuis <sven@cb3rob.net> said:
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.
TCP is not just for zone transfers (especially in the age of DNSSEC and
still-broken firewalls).
Yeah.
there's a lot of bad networking voodoo out there.
I was on the NY State Thruway in recent weeks, and noticed a few things:
1) Don't query their website for an AAAA record, nor attempt to report it to the state. They say "we don't support IPv6" - not understanding sending back a SERVFAIL is bad
2) Don't expect 1.1.1.1 to work, they use that as a HTTPS portal, so you not only get broken IP, but a broken certificate login page
3) Comcast will sometimes reply from a "different" IP than you sent the query if the dns query fails in such a manner.
- Jared