[dns-operations] On server selection algorithms in dns resolvers

[Edward Lewis]

On 11/23/15, 15:21, "dns-operations on behalf of Mark Andrews"
<dns-operations-bounces at dns-oarc.net on behalf of marka at isc.org> wrote:

>This is entirely implementation specific.

Yep.  And implementations have changed the way the "brand" does it from
version to version.

FWIW, when I last wrote something like this (okay, in the 90's) I reduced
it to a (struct mathematics *) set of IP addresses.  I.e., I tossed the NS
records and just looked at the addresses, so if more than one NS pointed
to an IP address, it was just there once.

To digress:

I did this having seen one delegation have this ("example" used because
I've forgotten the name):

some.example. NS ns1.some.example.
some.example. NS ns2.some.example.

some.example. NS ns3.some.example.

ns1.some.example. A 192.0.2.1
ns1.some.example. A 192.0.2.2

ns1.some.example. A 192.0.2.3

ns2.some.example. A 192.0.2.1
ns2.some.example. A 192.0.2.2
ns2.some.example. A 192.0.2.3
ns3.some.example. A 192.0.2.1
ns3.some.example. A 192.0.2.2
ns3.some.example. A 192.0.2.3




I was mostly puzzled why they bothered to use 3 (and not 2) as the number
of NS and A records.  This is why it stuck in my head.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20151124/325e0f45/attachment.bin>