Modify DNS Search Domain

[9p4]

It seems that Netavark starts aardvark with the default DNS filter (.dns.podman). This should be customizable:

$ dig +short @10.88.0.1 container.podman.mycustomdomain
10.88.0.12

Aardvark sets the filter domain here:

https://github.com/containers/aardvark-dns/blob/8377c0a98bff609626cff273f829c34eca39ab08/src/main.rs#L69

This means that Netavark would need to set the filter domain here:

https://github.com/containers/netavark/blob/8377c0a98bff609626cff273f829c34eca39ab08/src/dns/aardvark.rs#L93

An optional entry in the network configuration that defaults to dns.podman would suffice here, much like this code:

netavark/src/network/bridge.rs

Lines 166 to 168 in 3a1902a

	let _ = response
	.dns_search_domains
	.insert(vec![constants::PODMAN_DEFAULT_SEARCH_DOMAIN.to_string()]);

[Luap99]

I have no objections to making it configurable, however it is unlikely that we will work on that. But feel free to discus the design here in case you or others would like to add this feature.
Could you explain more what your use case for this is? Is there anything not working with dns.podman?

[Luap99]

The biggest problem is that the name is global and not per network as of today as there is only one aardvark-dns running so setting the search domain in a individual network config cannot work as it would be inconsistent and only use the one from the first network setup.

So depending on what you need one option would be to set a global search domain in containers.conf, if you want search domains per network we would first need to implement such functionality in aardvark-dns

[mheon]

I have no objection to implementing this, but I begin to wonder if it isn't time to start implementing support for reading a (subset of) containers.conf in Netavark, so we don't have absurd CLI option growth as we start adding config knobs like this.

[Luap99]

I have no objection to implementing this, but I begin to wonder if it isn't time to start implementing support for reading a (subset of) containers.conf in Netavark, so we don't have absurd CLI option growth as we start adding config knobs like this.

I rather not, reading containers.conf correctly is not that trivial. Overrides, conf.d. support env vars, etc... reading the file correctly is actually not that easy.
I don't disagree on the cli options, we could just set the options in the json that we send to netavark so technically there is no reason for a cli option for each setting.

[9p4]

Ideally, a different domain should be able to be set based on the network. A usecase could be like so: a reverse proxy running bare-metal on the host that forwards requests to the domain names of containers. The DNS on the machine is configured to send dns.podman to the container network's DNS server. If there are two different networks that the reverse proxy sends requests to, either a DNS rewrite system is required (since the servers can resolve plain names without the dns.podman suffix), or a more robust system could be implemented by forwarding based on zone.