How to resolve the names of docker containers?


#1

Hi,

When it will be possible to fully deploy Enough on a single Docker host for isolated self-hosting (the bind scenario works and others will be verified: it’s not too far away), it will be possible to use the forum (for instance) that is deployed locally.

But … how would one know how to find it? There are many options:

  • adding the name of all the docker containers together with their IP in /etc/hosts on the local machine
  • configure the DNS used in the intranet to delegate a subdomain like enough.internal.tld

The most like scenario is that after Enough is deployed the user / sysadmin will visit https://1.2.3.4 where the website scenario is deployed. And from there navigate to other services using the links in the top menu. But how those names will be resolved? Should they just be IP addresses?

Ideas are welcome


#2

Since Enough with Docker as it is can only be deployed with private IP, there should be a command similar to enough host inventory to display the names and IP in a format suitable for /etc/hosts. It could be enough host etc-host

172.28.0.3 bind.enough.my
172.28.0.4 postfix.enough.my
172.28.0.5 icinga.enough.my
...

Or services could be exposed via tor. The Nextcloud instance is already reachable via tor and it does not make a difference if it is deployed on private IPs.


#3

What about adding an API endpoint that would allow someone to manage a subdomain like foobar.d.enough.community? The way it is currently done is by delegating the subdomain to the DNS running in the Enough instance. But when it is deployed with no public IP, it won’t work.

The Enough instance that has no public IP would send a PUT request to the Enough instance that has public IPs:

PUT /set-zone/ foobar.d.enough.community <zone content>

Where <zone content> is the content of the zone, including A records SSHFP records etc. that defines the foobar.d.enough.community domain. It is a copy of what the bind server of the Enough instance has. As if the Enough instance with public IPs was a slave for the zone. Except it would not work because of the private IPs.

And the user would then resolv icinga-host.foobar.d.enough.community by querying the publicly available DNS of enough.community and obtain a private IP address. Of course such addresses would be useless for anyone but the people with access to the local network.

In other words, an Enough instance running on a local network could use the DNS of an Enough instance running with public IPs.


#4

As suggested by @pilou the API server could use also-notif with tsigs keys generated using dnssec-keygen (even if it is not related to DNSSEC)

# Generated with: dnssec-keygen -a HMAC-SHA512 -b 512 -n USER -r /dev/urandom master
key slave-master. {
    algorithm hmac-sha512;
    secret "XXXX";
};

#5

@pilou also suggested https://github.com/mageddo/dns-proxy-server could be used when overriding /etc/resolv.conf is safe and there only is a need to resolv on the local machine.