summaryrefslogtreecommitdiff
path: root/src/resolve/resolved-dns-stream.h
diff options
context:
space:
mode:
authorTom Gundersen <teg@jklm.no>2015-07-06 08:15:25 +0200
committerTom Gundersen <teg@jklm.no>2015-11-27 01:35:33 +0100
commitbe808ea083fa07271116b4519c3c27fd20c5f077 (patch)
treeda9ed99807850c11ee7c6414c3041aa117586679 /src/resolve/resolved-dns-stream.h
parent90c739259fc35feb773b953d61f75790cacf6b15 (diff)
resolved: fallback to TCP if UDP fails
This is inspired by the logic in BIND [0], follow-up patches will implement the reset of that scheme. If we get a server error back, or if after several attempts we don't get a reply at all, we switch from UDP to TCP for the given server for the current and all subsequent requests. However, if we ever successfully received a reply over UDP, we never fall back to TCP, and once a grace-period has passed, we try to upgrade again to using UDP. The grace-period starts off at five minutes after the current feature level was verified and then grows exponentially to six hours. This is to mitigate problems due to temporary lack of network connectivity, but at the same time avoid flooding the network with retries when the feature attempted feature level genuinely does not work. Note that UDP is likely much more commonly supported than TCP, but depending on the path between the client and the server, we may have more luck with TCP in case something is wrong. We really do prefer UDP though, as that is much more lightweight, that is why TCP is only the last resort. [0]: <https://kb.isc.org/article/AA-01219/0/Refinements-to-EDNS-fallback-behavior-can-cause-different-outcomes-in-Recursive-Servers.html>
Diffstat (limited to 'src/resolve/resolved-dns-stream.h')
0 files changed, 0 insertions, 0 deletions