# dns-scripts Dieses Git enthält eine Sammlung an Scripten zur Aktualisierung der Zonen für fff.community. Dabei werden aus der Forward-Zone und optional eigener Subdomain (durch community-Zonefile gesteuert) auch passende Reverse-Zonen für unsere internen RFC 1918 und RFC 4193 Adressen erzeugen. Es werden bei eigener Subdomain die momentan vergebenen Adressen von dnsmasq und odhcpd (alles unter /tmp/hosts/) inkludiert. Das ermöglicht eine Namensauflösung für Freifunk-Teilnehmer ohne manuelle Konfiguration. Damit kann jeder Freifunk-Teilnehmer ein gültiges TLS-Zertifikat bekommen, sofern DHCPv6 am Gateway aktiviert ist. Unterstützt wird Split-DNS für Freifunk-interne und -externe Anfragen, dabei kann auch eine Subdomain angelegt werden unter welcher nur extern erreichbare IPs herausgegeben werden. DNSSEC wird für jede Zone unterstützt, allerdings nur für die Hauptzone mit mehreren Servern. Für Subdomainserver darf mit DNSSEC nur jeweils ein Server autoritativ sein. ## Installation #### Systemanforderungen curl bind9 named-checkzone (z.B. bei bind oder bind-tools enthalten) für DNSSEC: delv; bind9 >= 9.16.18 #### dns-scripts klonen Die Scripte müssen geklont werden, oder anderweitig auf dem Server abgelegt werden. Die Ordner sind im Git vorgegeben. /usr/lib/ffdns für die Scripte und /etc/ffdns für die Konfigurationsdateien. ``` git clone https://git.freifunk-franken.de/freifunk-franken/dns-scripts.git ``` #### konfigurieren Die Datei /etc/ffdns/community.conf wird für eine Community konfiguriert (vorzugsweise im Git), und sollte nicht lokal geändert werden. Die Datei /etc/ffdns/local.conf muss serverspezifisch konfiguriert werden. Für die Konfiguration der Zonendatei siehe https://git.freifunk-franken.de/freifunk-franken/dns #### Cron anlegen Das Script muss regelmäßig aufgerufen werden, z.B. via Cron: ``` 1-59/5 * * * * /usr/lib/ffdns/update-dns.sh ``` #### DNS-Server konfigurieren ##### Erstkonfiguration Vor der Konfiguration des DNS-Dienstes bietet es sich an, das update-dns.sh Script einmalig manuell aus zu führen, um die Konfigurationsdateien anlegen zu lassen. Dafür empfiehlt sich `DNSSCRIPT_BIND_RELOAD_VER=-1` (local.conf). Hat die vorherige Konfiguration von `bind` noch keine `views`, so muss beachtet werden, dass `zone`-Einträge bei der Konfiguration mit `views` sich nur noch innerhalb von `view`-Einträgen befinden dürfen. Deswegen muss meißt die Standardkonfiguration angepasst werden. ##### Konfiguration des DNS-Dienstes Die Scripte sind auf `bind` ausgerichtet. Andere Distributionen sind auch möglich, aber DNSSEC und automatische Konfiguration der verschiedenen Zonen müssen dann selbst gelöst werden. Für `bind` werden durch die Scripte für jeden `view` include-Dateien im Ordner `$GeneratedIncludeFileFolder` (local.conf) angelegt (z.B. icvpn-internal-view.conf) und zusätzlich eine icvpn-acl.conf: ##### Konfiguration: Die Reihenfolge der Einträge ist obligatorisch ``` $ cat named.conf.local [..] acl icvpnlocal { 10.0.0.0/8; 172.16.0.0/12; fc00::/7; }; include "/etc/bind/icvpn-acl.conf"; # auto-generated [..] options { [..] # eigene Optionen recursion no; check-names master warn; # Wichtig, da sonst Hostnamen mit _ (z.B.: HUAWEI_P30_lite ) bind nicht laden lassen }; [..] view "icvpn-internal-view" { match-clients { icvpnrange; localhost; }; allow-query-cache { any; }; recursion yes; [..] # eigene Optionen include "/etc/bind/icvpn-internal-view.conf"; # auto-generated include "/etc/bind/icvpn-zones.conf"; # Nicht vergessen ;) siehe https://github.com/freifunk/icvpn-scripts#dns-mkdns [..] }; view "external-view" { match-clients { any; }; [..] # eigene Optionen include "/etc/bind/external-view.conf"; # auto-generated [..] }; [..] ``` ##### Beispielkonfiguration mit DNSSEC: ``` [..] options { [..] # eigene Optionen }; dnssec-policy { # Name muss in der config gesetzt werden keys { ksk key-directory lifetime unlimited algorithm ECDSAP384SHA384; # Alle Server einer Domain müssen den gleichen Algorithmus für ksk wählen zsk key-directory lifetime P30D algorithm ECDSAP384SHA384; # Alle Server einer Domain müssen den gleichen Algorithmus für zsk wählen }; max-zone-ttl 3600; nsec3param; }; [..] ``` ##### Beispielkonfiguration für DNS64: ``` [..] view "icvpn-internal-dns64-view" { match-destinations { ; # eine separate Adresse ist für DNS64 notwendig }; match-clients { icvpnrange; localhost; }; allow-query-cache { any; }; recursion yes; dns64 64:ff9b::/96 { break-dnssec yes; mapped { !10/8; !192.168/16; !172.16/12; any; }; exclude { 64:FF9B::/96; }; }; include "/etc/bind/icvpn-internal-dns64-view.conf"; [..] }; view "icvpn-internal-view" { [..] ``` ##### empfohlene Konfigurationen: ``` options { [..] # eigene Optionen minimal-responses yes; server-id "" # sehr hilfreich wenn anycast-Adressen bedient werden }; view "external-view" { [..] rate-limit { responses-per-second 50; }; [..] }; ``` ## Konfiguration der Zonendatei ### Einträge generell Alle Einträge sollten im relativen Schema vorliegen, also ohne die Rootdomain und ohne abschließenden Punkt. ### Subdomains Subdomains der Rootzone können von Root-Servern selbst oder auch von jedem anderen Server gehostet werden. Subdomains sollten im folgenden Format angelegt werden ``` IN NS [ ; Subnets:[ /| /]+]? ``` z.B.: ``` herpf IN NS dns.herpf.fff.community. ; Subnets: 10.50.250.0/24 fd43:5602:29bd:62::/64 ``` Serverhostname muss mit der Konfiguration in local.conf übereinstimmen und muss absolut sein (mit abschließendem Punkt). Die Subnetzparameter sind für die Delegierung und Erstellung der Reversezonen notwendig. Sofern noch nicht vorhanden wird dann eine neue Zonendatei für diese Subdomain erstellt. Diese darf dann auch oberhalb der Zeile ``` ;### Leases ### ``` wie die Rootzonendatei editiert werden. ### Subsubdomains Auch unterhalb von bereits delegierten Subdomains können beliebig viele weitere Subdomains bedient werden. Dazu muss in local.conf angegeben werden wo die Zonendatei der nächst höheren Zone zu erreichen ist.