systemd-resolved vs. split-horizon DNS

In diesem Fall meine ich mit "split-horizon DNS" die Client-Seite: Auf dem Client möchte ich für bestimmte Domains bestimmte DNS-Server fragen und für "normale" Domains bitte "normale" DNS-Server.

Konkreter Fall: Wenn ich ein Consul-Setup habe, möchte ich natürlich auch Consul-DNS verwenden. Für Domains in der TLD consul. sollte die DNS-Schnittstelle des lokalen Consul-Clients zur Namensauflösung verwendet werden - für alle anderen TLDs sollen bitte die "normalen" DNS-Server verwendet werden.

Der gewünschte Effekt sieht etwa so aus:

root@nomad-client-0~# dig +short consul.service.consul
192.168.0.39
192.168.0.175
192.168.0.43

Natürlich kann man Consul auch so konfigurieren, dass er DNS-Anfragen, die er selbst nicht final beantworten kann, an andere DNS-Server weitergibt. Dazu trägt man in die consul.hcl z. B. passende DNS-Server wie folgt ein:

recursors = ["62.138.222.111","62.138.222.222"]

In der /etc/resolv.conf der VM steht dabei sowas drin (das sind z. B. die Einträge, die in der /run/systemd/resolve/stub-resolv.conf zu finden sind):

nameserver 127.0.0.53
options edns0 trust-ad
search .

Alle lokalen DNS-Clients fragen also auf 127.0.0.53:53 an. Wenn auf der VM systemd-resolved installiert und konfiguriert ist, muss dieser - wie in Forward DNS for Consul service discovery beschrieben - umkonfiguriert werden, damit dieser die Anfragen an die lokale Consul-Instanz auf Port 8600 weitergibt. Je nach systemd-Version sind sogar verschiedene Konfiguration nötig.

Leider unterstützt systemd-resolved das oben beschriebene split-horizon Szenario nicht. Systemd-resolved kann entweder nur alle DNS-Anfragen lokal weiterleiten oder keine.

Wenn in so einer Konfiguration der lokale Consul-Client aus irgendwelchen Gründen nicht startet (oder nicht starten kann - z. B. bei einer Konfiguration mit auto_config), dann sind auf der VM überhaupt keine DNS-Auflösungen mehr möglich.

Zum Glück wird unter Forward DNS for Consul service discovery auch gleich ein Setup mit dnsmasq beschrieben denn dnsmasq kann die gewünschten Anforderungen erfüllen. Da systemd-resolved aber oft in der Standardinstallation von Linux-Distributionen verwendet wird, muss dnsmasq erst installiert und dann systemd-resolved dis- und dnsmasq enabled werden.