containers
Register common DNS suffix (containers.internal) to podman container networks
It would be very useful, if DNS cache on host could redirect whole subdomain used by one podman network from host's dns cache to network specific aarvwark-dns servers for each network.
I have noticed host.containers.internal is provided to podman images. It would be great, if containers.internal domain could be assigned to podman network. Then if one node with name nodeA should be accessed, it should register also nodeA.containers.internal.
If there should be more than one podman networks, each should have different search network. It could be for example nodeA.network-name.containers.internal. If the /etc/resolv.conf contains search network-name.containers.internal inside started node, then ping nodeB would work the same way as now, when only nodeB. is registered.
Important difference in this is that dnsmasq or unbound can forward one subdomain to specific server. By podman network inspect <network-name> can be obtained gateway IP, which usually runs DNS service with those registered names.
This would allow even from host to use ping nodeA.network-name.containers.internal to access pods in user-friendly way. If host would use search in resolv.conf also, it would be very pleasant to use with.
Is this already possible somehow? If not, what components need modification to implement this?
We use dns.podman by default as search domain. So containerA.dns.podman should resolve fine.
It is not per network though. Adding the network name as zones tracked and described in https://github.com/containers/aardvark-dns/issues/403 so if this would be added it should work as you like
Why do you use dns.podman domain name, when such name is not registered?. Every DNSSEC validating resolver will block resolving these queries, until you add podman. to Negative Trust Anchors. Zone like pods.podman.org would be much better default. home.arpa. domain would be less cool, but has working DNSSEC unsigned zone delegation. internal. zone does not have such delegation, but it is recommended for such uses by IANA. It is more likely it will have negative trust anchor already from DNS software vendor.
You can test it by dnssec validating clients, like delv example.dns.podman or unbound-host -rvD example.dns.podman. Unbound and BIND9 servers validate in default configuration, it is not required to enable it.
It seems like docker has something I would like to see in podman, according to https://github.com/containers/aardvark-dns/issues/403#issuecomment-1770459051. But I would like that network names with smart defaults, sharing common parent domains if possible. containers.internal. or pods.internal would be good parent for it. Does every network have separate aardvark-dns instance or all networks share only one instance?
If networks have separate instances, then they would require separate forwarding entry. Then they should contain network name in domain name used.
That name pre-dates me and was coming form our cni dnsname implementation. Changing that now would break users depending on it.
Also I think we explicitly block dns.podman from being forwarded so it really is only internal to aardvark-dns and we don't support DNSSEC for these internal names anyway. I am not really familiar with DNSSEC but I am not sure how we it could validate them regardless? OR are you just saying we need to use internal because clients will never validate that one?
Does every network have separate aardvark-dns instance or all networks share only one instance?
There is only one instance. But reading again I am not sure what you are trying to achive exactly. Are you trying to put a nameserver between the container and aardavark-dns or behind aardvark-dns as upstream resolver?
Because aardvark-dns uses the client ip to determine which contianer is talking to us and thus which names it is allowed to resolve and what upstream resolvers to us. If you put another sever in between that could break.
No. I am looking for a way to configure unbound on host machine to forward container names and container network IP ranges to podman managed dns service. For example I want to observe traffic by wireshark or iptraf. I want to be able to see pod names, not only IP addresses.
If there is only one instance, then the same instance listens on each network gateway address? Then forwarding whole dns.podman to gateway address should make resolving names from all networks working, right?
I do not want to put my namserver between pods and its service, no. I want to forward some names from host to the service those pods are using. To configure that, I need IP address and domain name to forward there. I tested gateway IP from podman network inspect is a good candidate, when DNS is enabled. But I have not found dns.podman domain mentioned anywhere.
How do you block dns.podman forwarding? It forwards all records except that domain and any names contained in it? Does it block also reverse address ranges the same way? That it good, it would prevent loops if host directed those queries to it.
[host] --+--- (shell)
|
+-- podman network1
|
+ -- pod example1
+ -- pod example2
what I am trying to configure is resolving name from host (shell) should get IP address of pod tried. Therefore dig example1.dns.podman should get pod IP not only when executed from example1 or example2 pods, but also on the host itself.
This would be nice especially for reverse address queries, when observing traffic by tcpdump for example.
Lets assume /etc/resolv.conf on host contains:
nameserver 127.0.0.1
# following only for fallback
nameserver 8.8.8.8
nameserver 1.1.1.1
options edns0
No. I am looking for a way to configure unbound on host machine to forward container names and container network IP ranges to podman managed dns service. For example I want to observe traffic by wireshark or iptraf. I want to be able to see pod names, not only IP addresses.
If there is only one instance, then the same instance listens on each network gateway address? Then forwarding whole dns.podman to gateway address should make resolving names from all networks working, right?
Ok I see, so in that case what we do is there is only one aardvark-dns process but it does listen on each network gateway bridge ip on the host. So as networks are added/removed we update our listen ips.
So I think that is effectively the use case from https://github.com/containers/aardvark-dns/issues/82 I think the way I made it work currently is that if you connect from a non container ip address it would only allow resolving names for network using the listen address where the query was received. So if you do not names across multiple networks you do indeed need to forward them to different ips I think.
How do you block dns.podman forwarding? It forwards all records except that domain and any names contained in it? Does it block also reverse address ranges the same way? That it good, it would prevent loops if host directed those queries to it.
https://github.com/containers/aardvark-dns/blob/3413c1b93c0d39ae631fd2f845655c8fbaa928a6/src/dns/coredns.rs#L211C16-L211C35
I don't think we block reverse lookups for the same ips so loop might be possible there. But I guess it should be simple enough to not forward PTR requests for the subnets we "own".