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.

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

Add host.containers.internal entry in aardvark-dns #345

Open
hrenard opened this issue Jun 21, 2023 · 4 comments
Open

Add host.containers.internal entry in aardvark-dns #345

hrenard opened this issue Jun 21, 2023 · 4 comments

Comments

@hrenard
Copy link

hrenard commented Jun 21, 2023

Feature request description

Hi,

I think that adding the host.containers.internal entry in aardvark-dns would be more consistent and quite handy in some cases.

Suggest potential solution

No response

Have you considered any alternatives?

No response

Additional context

When using podman as backend for a k8s kind cluster, host.containers.internal is not resolvable because k8s's internal coredns forwards requests directly to aardvark-dns and /etc/hosts is not propagated to pods.

@Luap99 Luap99 transferred this issue from containers/podman Jun 21, 2023
@Luap99
Copy link
Member

Luap99 commented Jun 21, 2023

Moved to aardvark-dns repo


In principle that would be possible. However I am not sure if doing this would not break users, at the very least we would need to respect the containers.conf host_containers_internal_ip entry.

Also in the podman machine scenario right now we do not add the entry in /etc/hosts and let it fall back to the internal gvproxy dns server which would return you the actual proper host ip and not the VM ip. If we have aardvark-dns in between replying then this would no longer work.

@miwagner1
Copy link

I am currently running into an issue with Nginx where it does not resolve host.containers.internal because it does not read /etc/hosts for lookups. Having host.containers.internal entry in aardvark-dns would make it just work without extra workarounds.

@akostadinov
Copy link

yeah, there are cases where /etc/hosts is ignored. Will be much easier to have host.containers.internal resolvable through DNS. The entry inside /etc/hosts can stay, no problem with the redundancy IMO.

@djasa
Copy link

djasa commented Sep 17, 2024

I'm playing around this right now. A workaround is pretty easy: just add a host line to /run/containers/networks/aardvark-dns/{network_name} (and maybe make sure to delete the file after last container exits to prevent stale first line? I didn't get that far yet...)

However this comes with a side effect: in addtion to making host resolvable by containers, it also makes the containers' short names and {cont}.dns.podman names resolvable by the host, which is currently by default prevented by this aardvark-dns code. Long names are OK but the short names seem to me like a pretty big change of default behaviour.

If there are some bigger changes planned in this area, changes in this direction would seem good to me:

  • enable this host-from-containers resolution for all (or by default if there are users depending on the current behaviour?)
  • enable containers-from-host for long names only and for containers that are reachable from the host
  • revive "search domains" and use network name as the search domain for the given container

The last bullet would, if I read correctly this discussion/comment, make the behaviour the same as docker's and based on many questions/issues about container name resolution, as many people expect...

(Just for the context: my use case is to run the IPA container and make the host its client. For this, I need to resolve container's FQDN from the host and ... there's no straightforward solution to setting up the DNS for this case, while it feels that it should be as easy as instructing host's local resolver to forward requests for network-name.tld domain to the respective network's gateway:53)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants