avoid spurious lookup failures from badly-behaved nameservers
authorRich Felker <dalias@aerifal.cx>
Sat, 7 Jun 2014 08:09:21 +0000 (04:09 -0400)
committerRich Felker <dalias@aerifal.cx>
Sat, 7 Jun 2014 08:09:21 +0000 (04:09 -0400)
commit246e752d9e7c472735444815163f0a22e5bc4161
tree98f25f819b88a2200e63613d1b5bd5d7665c0cda
parentf616294914e7c289791d856dca636bbccad5fef7
avoid spurious lookup failures from badly-behaved nameservers

the results of a dns query, whether it's performed as part of one of
the standard name-resolving functions or directly by res_send, should
be a function of the query, not of the particular nameserver that
responds to it. thus, all responses which indicate a failure or
refusal by the nameserver, as opposed to a positive or negative result
for the query, should be ignored.

the strategy used is to re-issue the query immediately (but with a
limit on the number of retries, in case the server is really broken)
when a response code of 2 (server failure, typically transient) is
seen, and otherwise take no action on bad responses (which generally
indicate a misconfigured nameserver or one which the client does not
have permission to use), allowing the normal retry interval to apply
and of course accepting responses from other nameservers queried in
parallel.

empirically this matches the traditional resolver behavior for
nameservers that respond with a code of 2 in the case where there is
just a single nameserver configured. the behavior diverges when
multiple nameservers are available, since musl is querying them in
parallel. in this case we are mildly more aggressive at retrying.
src/network/res_msend.c