summaryrefslogtreecommitdiff
path: root/src/thread/pthread_cond_broadcast.c
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2014-06-07 04:09:21 -0400
committerRich Felker <dalias@aerifal.cx>2014-06-07 04:09:21 -0400
commit246e752d9e7c472735444815163f0a22e5bc4161 (patch)
tree98f25f819b88a2200e63613d1b5bd5d7665c0cda /src/thread/pthread_cond_broadcast.c
parentf616294914e7c289791d856dca636bbccad5fef7 (diff)
downloadmusl-246e752d9e7c472735444815163f0a22e5bc4161.tar.gz
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.
Diffstat (limited to 'src/thread/pthread_cond_broadcast.c')
0 files changed, 0 insertions, 0 deletions