Remove UDP connection caching in embedded DNS server #1352
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In 1.11 we made a change to source the external queries from the container namespace. This allows the external resolvers to see the source IP of the container that generated the query. That was useful for resolvers that want to use the source of the query in some way to determine what the response should be.
Along with this there was also a change to cache the external UDP connections after its opened the first time. This avoids having to set into the container namespace and will avoid the chances of new OS thread getting created in the container net ns. For the first query we still have to set into container net ns. Also the caching can't be done for TCP because a long running TCP session to a DNS server is not the usual practice can get RST by the server.
UDP connection caching has added lot of complexity to the code and hard to debug issues like docker #22185.
This PR removes the UDP connection caching. The only operation that happens in the container net ns is a UDP Dial which is a local non-blocking operation without any network io. This is not likely to lead to a go routine (and OS thread) creation. Verified this by running a test similar to libnetwork #1113; right after the daemon comes up start 20 containers running a go code triggering a total of 4000 name resolutions.
Signed-off-by: Santhosh Manohar santhosh@docker.com