2009-03-18 - News - Chris Thompson
The Computing Service provides two general-purpose recursive nameservers for use within the CUDN, at IPv4 addresses 131.111.8.42 and 131.111.12.20 (or IPv6 addresses 2001:630:200:8080::d:0 and 2001:630:200:8120::d:1).
Historically, there were compelling reasons to favour 131.111.8.42 over 131.111.12.20, and therefore to list them in that order in resolver configurations. The machine servicing 131.111.12.20 was severely overloaded and often had much poorer response times.
For the last two years, this has not been the case. The two services run on machines with equal power and for nearly all locations within the CUDN there is no reason to prefer one over the other. Since last September, one of them has been in our main machine room on the New Museums Site, and one at Redstone, providing improved physical redundancy.
However. we observe that the load on 131.111.8.42 is still several times that on 131.111.12.20, presumably as a result of the historical situation. For a while now we have been randomising the order in which the two addresses appear in the "nameservers:" line generated when the "register" or "infofor*" functions are used on the ipreg/single_ops web page, but we suspect that COs rarely act on that when actually setting up resolver configurations.
We would like to encourage you to do a bit of randomising yourselves, or even to deliberately prefer 131.111.12.20 to redress the current imbalance. If you have resolvers which support it, and you are configuring only these two addresses as nameservers, then you could sensibly use "options rotate" to randomise the order they are tried within a single host. (Unfortunately, this doesn't work well if you have a preferred local resolver and want to use the two CS nameservers only as backups.)