[bind10-dev] Resolver Address Database - Requirements and Design

[Stephen Morris]

On 6 Oct 2010, at 15:56, Shane Kerr wrote:

> Does it make sense to add a requirement to allow the database to be
> serialized in some way? This will allow us to store it to disk between
> boots, and migrate it between machines.
> 
> This has certain design implications, depending on how it is done.
> 
> I suppose this may be feature bloat though, and perhaps added to a
> wishlist.

I had wondered about that, but had two questions:

a) How long will it take for the resolver to build up a full address database?  If only a short time, is there much to be gained by loading an old one from disk?

b) How long would the system be down for?  The addresses "age" - after a couple of days (a typical A/AAAA record TTL) the addresses will need to be re-fetched anyway.  (Although the TTL is much shorter for the larger sites:  www.google.com points to the CNAME www.l.google.com which has a A record with a TTL of 300s.  www.facebook.com has a TTL of 120s.  And even the BBC is fairly short at 900s.)

In some circumstances though I can see users wanting to do it.  I think that adding it to a feature backlog is the best approach.

> 
>> and a draft design at
>> http://bind10.isc.org/wiki/NameserverAddressStoreDesign.
> 
> I noticed the statement that we use a random RTT initially. I think that
> makes sense,

This is already in BIND 9; from the BIND 9.6 "New Features" section:

Randomize server selection on queries
As a security improvement to make forgery a little more difficult, BIND 9.6 now attempts to make the order of the server selection for queries less predictable. Previously, BIND would prefer to query the server with the lowest round trip time (RTT). Now servers that haven't been tried yet have their RTT set to a random value between 0 ms and 7 ms. And the RTT values of servers which have been tried are now randomly changed up to 128 ms.


> but perhaps we should go ahead and specify that we use a
> pseudo-random RTT.
> 
> Pseudo-random is preferred to true random because we don't have to find
> a source of entropy, and we can use a high-speed generator. Also, it
> allows us to explicitly state that we have thought about security
> implications and do not think there are any. (There are not any, right?)

That's a fair point. I'll update the design to note that.

Stephen