Resolver behaviour with rrset

[Jim Reid]

>>>>> "Sebastian" == Sebastian Castro Avila <secastro at nic.cl> writes:

    Sebastian> The resolver remembers the response times of the servers,
    Sebastian> and prefers the one that has the best record.  However,
    Sebastian> the matching is fuzzy, so close times are considered
    Sebastian> equivalent, and it load balances among them (I think
    Sebastian> it's random selection rather than true round robin, but
    Sebastian> in the long run they should both produce equal load).

    Sebastian> What resolvers implements this behaviour? 

BIND certainly does. But all resolving name servers should do this.
However you will need to check any documentation and source code for
other implementations to see what they do. Or talk to the appropriate
developers and software support people.

Note that this is the resolver inside the name server, not the stub
resolver used by an application. A stub resolver would typically only
make one query to the local name server which would be keeping track
of the RTTs to the servers it queries whenever it is resolving.

    Sebastian> How does it work if a server became unreachable?  

That server is considered to have an infinite round trip time. [For
some definition of "infinite".] So the dead server won't get queried
much after it became unreachable, all other things being equal. However
the resolving name server will periodically "forget" the dead server
has an infinite RTT and query it once more. Any response or
non-response is then used to update the server's idea of which name
server is closest for a given domain. This means a name server's
resolver is continually keeping track of the RTTs to the name servers
it queries and adjusting those RTTs in light of what is currently
going on.

    Sebastian> How often the resolver updates the response time for
    Sebastian> the whole list of known servers? 

It depends. 

    Sebastian> Where can I get more information about this "feature"?

Section 7.2 of RFC1035 explains some of the factors that can be taken
into consideration. You can also read the source code to see what BIND
does. To a large extent, this feature is an opaque implementation
detail. Frankly, most people don't (need to) care about this. They
just trust that their name servers generally favour the fastest
responding name server for some zone and will do the Right Thing
whenever any dead servers come back to life or a nearby server goes
away.

Have you a specific reason for asking about this or are you just curious?

ISTR there was a discussion in bind-users or bind-workers some years
ago about RTT maintenance. So it might be worth checking the list
archives.