Der Eintrag von Servernamen in /etc/hosts genügt, um aus einem Redaktionssystem aus Sicht des Browsers einen namentlich ansprechbaren Webserver zu machen, aber auch ambitionierte Amateurinnen sollten nicht auf ein getrenntes System verzichten. Statt DNSMasq oder einem teuren Router kann man unter Ubuntu Bind9 konfigurieren, um eine eigene TLD im lokalen Netz zu etablieren:
# /etc/bind/named.conf.local zone "mytld" { type master; file "/etc/bind/db.mytld"; }; # /etc/bind/named.conf.options options { directory "/var/cache/bind"; dnssec-validation auto; validate-except { "mytld"; }; forwarders { 1.1.1.1; }; listen-on { 127.0.0.1; 192.168.78.0/24; }; listen-on-v6 { any; }; }; # /etc/bind/db.mytld $TTL 604800 @ IN SOA ns.mytld. root.mytld. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns.mytld. * IN A 192.168.78.42
Als Nameserver für alle anderen Domains (forwarders) kommt Cloudflare (1.1.1.1) zum Einsatz, und die DNSSEC-Validierung wird für die neue TLD deaktiviert. Interessanterweise hält diese Konfiguration Bind9 nicht davon ab, sich bei Cloudflare (erfolglos) nach dem Delegation Signer zu erkundigen:
16:28:34.165569 IP myserver.49728 > one.one.one.one.domain: 45669+% [1au] DS? mytld. (46) 16:28:34.179688 IP one.one.one.one.domain > myserver.49728: 45669 NXDomain* 0/6/1 (1026)
Wenn nun der neue DNS-Server auf einem lokalen Netgear-Router hinterlegt wird, bringt man sich um die Segnungen von DNSSEC, weil Netgear DNSSEC-Unterstützung im privaten Bereich offenbar für unnötig hält. Stattdessen müssen alle lokalen Endgeräte (solange sie sich im heimischen LAN/WLAN aufhalten) direkt mit dem DNS-Server und Cloudflare als Fallback interagieren.
Erstaunlich schwierig ist es, den Server zum dogfooding zu bewegen: Er erhält per DHCP die IP-Adresse des Routers und verwendet sie auch für DNS-Anfragen. Trägt man die Loopback-Adresse 127.0.0.1 in /etc/systemd/resolved.conf ein, meldet resolvectl status zwar:
Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Current DNS Server: 127.0.0.1 DNS Servers: 127.0.0.1
aber wegen der fehlenden netplan-Konfiguration auch:
Link 2 (eno1) Current Scopes: DNS Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.78.1 DNS Servers: 192.168.78.1
Abhilfe schaffen – anders als von Kumar getestet – nur folgende Einträge in /etc/netplan/00-installer-config.yaml:
network: ethernets: eno1: dhcp4: true dhcp4-overrides: use-dns: false nameservers: addresses: [127.0.0.1] version: 2
in Verbindung mit DNSSEC=yes in /etc/systemd/resolved.conf:
Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=yes/supported resolv.conf mode: stub Link 2 (eno1) Current Scopes: DNS Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=yes/supported Current DNS Server: 127.0.0.1 DNS Servers: 127.0.0.1
Den autoritativen Nameserver für eine TLD zu betreiben, ist ein erhebendes Gefühl (trotz kleiner Schwierigkeiten mit modernen HTTPS-Einträgen).