Using multiple DNS servers options - implementation note missing

[OndrejPacay]

File: engine/userguide/networking/default_network/configure-dns.md

Hi I have found (the hard way), that when you specify multiple --dns options on the command line (or in daemon.json) then name resolution works by default this way:

• fire DNS request to all nameservers provided
• use the first response ... even if it responds by not found ... in other words, there is no fixed 'hierarchy' when using those nameservers and the result can be random for hosts that are not resolved by all nameservers listed.

This behaviour is probably sometimes beneficial, but should be better documented since:

• does not work the same as in linux/unix ... there the other nameservers are queried only if the 1st is unreachable
• creates intermittent problems when combining an intranet-only nameserver with a public one. For example when resolving an intranet hostname in such setup it can happen that 8.8.8.8 responds first that the hostname is not found and the resolution fails. ....in contrast it will resolve ok, when the intranet nameserver responds first.

Regards, Ondrej

[nigelpoulton]

Wondering if this should be filed as a potential bug against Engine @thaJeztah ??

I'd at least want someone to confirm this is intended behavior before documenting it.

[docker-robott]

There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment.
If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

[docker-robott]

There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment.
If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

/lifecycle locked

[thaJeztah]

Looks like I missed this one in my notifications. Let me reopen; perhaps @akerouanton and @dvdksn could have a look at this. From the top of my head, I think some aspects may influence DNS lookup behaviour;

• When running the static binaries, Go uses its own implementation for the network stack (which differs from dynamically linked binaries)
• MUSL vs GCC
• Whether or not a nssswitch.conf is present (also see net: prefer /etc/hosts over DNS when no /etc/nsswitch.conf is present golang/go#35305)
• other aspect?

Perhaps some mention of this (with relevant links so that we don't have to do a deep-dive into everything) could be useful (maybe for a troubleshooting section 🤔)