Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Podman's --dns + --network is different than docker's --dns + --network #16172

Closed
flouthoc opened this issue Oct 14, 2022 · 15 comments · Fixed by #16297
Closed

Podman's --dns + --network is different than docker's --dns + --network #16172

flouthoc opened this issue Oct 14, 2022 · 15 comments · Fixed by #16297
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@flouthoc
Copy link
Collaborator

flouthoc commented Oct 14, 2022 •
edited
Loading

I think Podman's --dns is behaving differently than how is it supposed to work when comparing with docker when a container is started with --network.

What Podman is doing when --dns is used with --network

Podman's --dns is overrding the nameservers inside container's /etc/resolv.conf

So podman run --network test --dns 8.8.8.8 ... will produce a /etc/resolv.conf inside container with following content.

bash-5.1# cat /etc/resolv.conf 
nameserver 8.8.8.8

Following behavior mismatches with docker.

What docker is doing when --dns is used with --network

Docker is setting the custom dns server instead of host's /etc/resolv.conf when container makes request to docker's DNS resolver. Actual /etc/resolv.conf inside the container is never changed with docker irrespective of --dns flag with --network flag.

See the text here: https://docs.docker.com/config/containers/container-networking/#dns-services
@flouthoc
Copy link
Collaborator Author

@mheon @Luap99 Could you please confirm if I am reading this right.

@flouthoc flouthoc changed the title Podman's --dns is different than docker's --dns Podman's --dns + --network is different than docker's --dns + --network Oct 14, 2022
@mheon
Copy link
Member

mheon commented Oct 14, 2022

What we are doing matches what Docker does for networks that do not have DNS enabled, last I checked.

It is, as you note, not correct for networks with DNS enabled. In those cases, Docker's internal DNS service takes over.

I don't see any harm in keeping the user-added DNS servers in resolv.conf, though. Just need to make sure that Aardvark is first.

@flouthoc
Copy link
Collaborator Author

@mheon Fair enough if container is connected to any network where DNS is enabled then we can keep aardvark's nameserver first, that should be enough to unblock my use-case. I'll open a PR to fix this first. ( cc @baude for info )

@flouthoc flouthoc mentioned this issue Oct 14, 2022
Closed
@flouthoc
Copy link
Collaborator Author

flouthoc commented Oct 14, 2022 •
edited
Loading

@mheon Upon checking again I like docker's way better since I don't see any value of repeating nameservers for case where container is connected to a network where dns_enabled: true in /etc/resolv.conf instead i see a drawback.

  • Resolution via custom DNS server will be already handled by aardvark-dns or dnsname since its always first entry in /etc/resolv.conf additional entry for custom DNS server will just ensure that request fails again since it be will processed only when aardvark-dns or dnsname fails ( where they have already tried against custom DNS server ) overall this process is just decreasing the lookup performance .

Following PR should address this: #16175

@Luap99
Copy link
Member

Luap99 commented Oct 14, 2022

Resolution via custom DNS server will be already handled by aardvark-dns or dnsname since its always first entry in /etc/resolv.conf additional entry for custom DNS server will just ensure that request fails again since it be will processed only when aardvark-dns or dnsname fails ( where they have already tried against custom DNS server ) overall this process is just decreasing the lookup performance .

This is only true when aardvark-dns has support for that. Before we add support for that we should not change this IMO

flouthoc added a commit to flouthoc/podman that referenced this issue Oct 14, 2022
@flouthoc
libpod: propogate custom DNS server to /etc/resolv.conf only when dns…
01915ad 
…_enabled

Podman populates container's `/etc/resolv.conf` with custom DNS servers ( specified via `--dns` or `dns_server` in containers.conf ) even when container is connected to a network where `dns_enabled` is `true`.

Current behavior does not matches with docker, hence following commit ensures that podman only populates custom DNS server when container is not connected to any network where DNS is enabled and for the cases where `dns_enabled` is `true`
the resolution for custom DNS server will happen via ( `aardvark-dns` or `dnsname` ).

Reference: https://docs.docker.com/config/containers/container-networking/#dns-services
Closes: containers#16172

```release-note
container: `--dns` and `dns_server` behavior for containers connected to network matches with docker now
```

Signed-off-by: Aditya R <arajan@redhat.com>
@mheon
Copy link
Member

mheon commented Oct 14, 2022

Also, should we make this a Netavark-only thing? CNI should probably continue to use the old behavior.

@flouthoc
Copy link
Collaborator Author

Also, should we make this a Netavark-only thing? CNI should probably continue to use the old behavior.

Sure SGTM. I'll add a filter for netavark only.

@flouthoc flouthoc mentioned this issue Oct 26, 2022
Merged
@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@rhatdan
Copy link
Member

rhatdan commented Nov 14, 2022

@flouthoc Any movement on this one?

@flouthoc
Copy link
Collaborator Author

I just need to rebase my original PR since new version of netavark and aardvark are already out.

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@rhatdan
Copy link
Member

rhatdan commented Dec 17, 2022

@flouthoc did the rebase ever happen?

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@flouthoc
Copy link
Collaborator Author

Waiting for latest version of nv/av in the CI.

@Luap99
Copy link
Member

Luap99 commented Jan 19, 2023

New images are merged you can rebase

flouthoc added a commit to flouthoc/podman that referenced this issue Jan 22, 2023
@flouthoc
libpod,netavark: correctly populate /etc/resolv.conf with custom dns …
0624107 
…server

After containers/netavark#452 `netavark` is
incharge of deciding `custom_dns_servers` if any so lets honor that and
libpod should not set these manually.

This also ensures docker parity
Podman populates container's `/etc/resolv.conf` with custom DNS servers ( specified via `--dns` or `dns_server` in containers.conf )
even when container is connected to a network where `dns_enabled` is `true`.

Current behavior does not matches with docker, hence following commit ensures that podman only populates custom DNS server when container is not connected to any network where DNS is enabled and for the cases where `dns_enabled` is `true`
the resolution for custom DNS server will happen via ( `aardvark-dns` or `dnsname` ).

Reference: https://docs.docker.com/config/containers/container-networking/#dns-services
Closes: containers#16172

Signed-off-by: Aditya R <arajan@redhat.com>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 3, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Milestone
No milestone
4 participants
@rhatdan @mheon @flouthoc @Luap99