-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Built-in DNS server extremely slow for large responses #4430
Comments
Issues go stale after 90 days of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so. Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. |
/remove-lifecycle stale |
@djs55 any idea where the bottleneck is? I can confirm that this is slow on Docker for Mac, but fast on a native Linux machine. |
Any update on this? 🙂 @thaJeztah @djs55 |
No update yet |
Issues go stale after 90 days of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so. Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. |
/remove-lifecycle stale |
Issues go stale after 90 days of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so. Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. |
/remove-lifecycle stale |
/lifecycle frozen |
I've been suffering this issue for half a year. Even for a normal size dns query, it is extremely slow, 30 seconds!
A ping command takes 15 seconds to resolve the dns name, see the strace result, it shows that the slow sys call happens in
The docker info is:
|
what's the status of this? |
This started happening for us in 2021 when we started migrating to m1 macs docker infoClient:
Version: 24.0.6
Context: desktop-linux
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.11.2-desktop.5
Path: /Users/maxpatiiuk/.docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.22.0-desktop.2
Path: /Users/maxpatiiuk/.docker/cli-plugins/docker-compose
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.0
Path: /Users/maxpatiiuk/.docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.20
Path: /Users/maxpatiiuk/.docker/cli-plugins/docker-extension
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v0.1.0-beta.8
Path: /Users/maxpatiiuk/.docker/cli-plugins/docker-init
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /Users/maxpatiiuk/.docker/cli-plugins/docker-sbom
scan: Docker Scan (Docker Inc.)
Version: v0.26.0
Path: /Users/maxpatiiuk/.docker/cli-plugins/docker-scan
scout: Docker Scout (Docker Inc.)
Version: v1.0.7
Path: /Users/maxpatiiuk/.docker/cli-plugins/docker-scout
Server:
Containers: 9
Running: 8
Paused: 0
Stopped: 1
Images: 32
Server Version: 24.0.6
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 8165feabfdfe38c65b599c4993d227328c231fca
runc version: v1.1.8-0-g82f18fe
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
cgroupns
Kernel Version: 6.4.16-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: aarch64
CPUs: 8
Total Memory: 7.667GiB
Name: docker-desktop
ID: 2653f9f0-5660-4b56-8c59-4e486c26a70b
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false
WARNING: daemon is not using the default seccomp profile more details in this issue: specify/specify7#2574 (comment) |
Expected behavior
When running DNS queries through docker's built-in DNS server, I expect similar performance (response times) compared to using external DNS servers directly.
Context
While the following reproduction case is an artificial example, it is a quite common case to have these huge DNS responses, especially when working with K8s ingress etc. I'm filing this issue because we essentially can't use Docker for Mac at our company because it breaks our DNS resolution (by timing out a lot).
Using an external DNS server directly is not an option for us since we also need DNS resolution for hostnames in the current docker network (for integration tests etc.)
Actual behavior
When executing DNS queries that yield large responses, it takes an extremely long time to return results. The results look correct though. This only happens on Docker for Mac. Running the same queries on linux-native docker does not show the same issue.
Information
Steps to reproduce the behavior
As you can see, this only happens when docker's DNS server is used. When querying the external DNS server directly, performance is not impacted. When run on linux directly (not Docker for Mac), docker's built-in DNS server is also as fast as the external one.
Please let me know if you need more details.
The text was updated successfully, but these errors were encountered: