[bind10-dev] Resolver - address database requirements

Michal 'vorner' Vaner michal.vaner at nic.cz
Sat Oct 2 13:14:49 UTC 2010


Hello

Just few random ideas while reading it, if they are of any use.

On Fri, Oct 01, 2010 at 11:15:34AM +0100, Stephen Morris wrote:
> Adding Names
> -------------
> 1) It must be possible to add a domain name to the database:
> * Adding a new name will cause the database software to issue lookups for the A/AAAA information of the associated nameservers and store that information.
> * As adding a new name will be associated with the need to use the address information, and since the address information may take time to acquire, it should be possible for the caller to specify a callback function that will be called when the address information arrives.
> 
> 2) The names in a given class should be distinct, e.g. example.com class IN is distinct from example.com class CH.
> 
> Looking up Names
> ----------------
> 3) It must be possible to look up a name in the database.  The lookup will return the addresses associated with the name subject to:
> * If only IPv4 addresses have been requested, only the IPv4 addresses associated with a name will be returned.
> * If only IPv6 addresses have been requested, only the IPv4 addresses associated with a name will be returned.
> * If both IPv4 and IPv6 addresses have been requested, both IPv4 and IPv6 addresses will be returned.
> * If an address is marked as unreachable, it will not be returned unless explicitly requested.
> 
> 4) The returned address information should contain round-trip time (RTT) information.
> * The RTT should be an integral number of microseconds.

Adding and looking up a name should maybe be one operation? Because if you look
up and it isn't there, you ask the database to add it there. What the user of
the database really wants is „get me the address somehow“. If the database needs
to query it or has it already or it finds out it is out of date and needs to
refetch it is up to it.

Furthermore, if there's a situation:
• Request 'a' about example.net. The database does not have it. So it is asked
  to add/fetch it.
• Request 'b' about example.net in the time between 'a' got answer „no data in DB“
  and 'a' asked to add it there. So it asks to fetch it again.

I think this should be atomic operation so we do not have these race conditions.
Not that they would be bad, because we will have something like „This is not in
the DB yet, but it is already requested“, so it could be solved here as well.

> 7) If the address information associated with a nameserver reaches its TTL, the information should be fetched again the next time address information is required.
> 
> 15) To limit memory usage, it should be possible to limit the number of names in the database.
> * If a new name is added and takes the count over the limit, another name should be dropped.

These look like expensive operations (with the TTL, we could wait until someone
asks for it or is dropped due to 15), but it seems to lack elegance). Would it
be possible to have them in „not exact“ manner ‒ if there are too many items in
the DB, run a background task that clears the DB of outdated and not much used
items and drop something like 10% of the database?


And I'm still thinking about how clever the database should be. If it selects
the right address and queries the server itself to see the RTT and stuff, or if
it should be really dumb, giving out a Zone object, letting the requester choose
the address and update the RTT and stuff on the object. Maybe a dual-layer (the
dumb is inside and the clever thing around it)?

Have a nice day

-- 
This side up =>

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101002/43855dc0/attachment.bin>


More information about the bind10-dev mailing list