DNS

Konzept

Für die interne Nutzung im Freifunknetz besitzt F3 Netze e.V. die Domain fff.community. Im Gegensatz zu anderen Communites verwenden wir keine eigene Toplevel-Domain, um Kollisionen vorzubeugen und Probleme mit DNSSEC zu vermeiden.

Die Zone wird in einem Git [1] verwaltet und über Skripte [2] auf die für diese Zone autoritativen Nameserver einiger Freifunker synchronisiert.

Wenn jemand eine Domain für seinen Service haben möchte, kann dies mit einen Pull Request angefragt werden: [3]
Die Delegation von Subdomains ist ebenfalls möglich.

Da es sich bei der Namensauflösung für unsere Adressbereiche um Bereiche des privaten Adressraums handelt, sollten diese IP-Adressen nicht bei eigenen global auflösbaren Domains gesetzt werden. Da einige DNS Server gegen rebind Attacken aus dem globalen DNS geschützt sind, kann es vorkommen, dass die eigene globale Domain nicht auf die fd43:[..] oder 10.[..] IPs aufgelöst werden kann. Sollte dennoch gern eine globale Domain verwendet werden, dann bitte den jeweiligen Eintrag als CNAME auf einen [..].fff.community hostname setzen und die IP im Git [4] setzen.

Zone extern

Die Zone extern.fff.community wird automatisch angelegt. Diese enthällt keine Adressen des privaten IP-Bereichs und ist von überall erreichbar. Deswegen können im Zonefile bei einem Hostnamen alle IP-Adressen angegeben werden und für benötigtes Peering kann der gleiche Hostname aus dieser extern-Domain genutzt werden. Das funktioniert auch für delegierte Subdomains (z.B. gw01.herpf.fff.community -> gw01.herpf.extern.fff.community)

Funktionsfähigkeit auf allen Gateways

Um sicher zu stellen, dass das DNS im ganzen Netz funktioniert, müssen alle Gateways korrekt konfiguriert sein. Dabei sollte man immer beachten, dass der DNS nicht aus dem Internet sondern nur aus dem Freifunknetz erreichbar ist. Es gibt mehrere Möglichkeiten um dies zu erreichen:

Andere DNS Server nutzen

Es muss nicht zwingend ein eigener DNS-Server betrieben werden. Es sollte aber möglichst nicht einer der großen bekannten öffentlichen (z.B. 1.1.1.1 oder 2606:4700:4700::1111) verwendet werden, sondern besser einer unserer eigenen Server. Somit braucht man sich um die Konfiguration keine Gedanken machen.

Aktuell wären das folgende:

IPv4-Adresse	IPv6-Adresse	Betreiber	Bemerkung
10.50.40.10	–	Mayosemmel	z.Z. offline
10.50.250.1	fd43:5602:29bd:62::1	Blackyfff
10.50.252.0	fd43:5602:29bd:ffff::252	RedDog
10.83.252.0	fd43:5602:29bd:ffff::42	fblaese
10.83.252.11	fd43:5602:29bd:ffff:a:a:a:a	ChristianD
10.83.252.62	fd43:5602:29bd:ffff::62	Adrian Schmutzler
–	fd43:5602:29bd:ffff::37	CHRiSNEW

Anycast

Unter der Anycast Adresse antwortet immer der am besten zu erreichende Server:

IPv4-Adresse	IPv6-Adresse	Bemerkung
-	fd43:5602:29bd:ffff:1:1:1:1	Anycast DNS
-	fd43:5602:29bd:ffff:1:1:1:64	Anycast DNS64

siehe auch Anycast-DNS.

DoH/DoT

Im Freifunk Franken Netz werden auch DoT/DoH DNS Server betrieben. Aktuell gibt es folgende Server:

IPv4-Adresse	IPv6-Adresse	Service	Domain für Zertifikat
10.50.250.1	fd43:5602:29bd:62::1	DoT	dns.herpf.fff.community
-	fd43:5602:29bd:62::3	DoT DNS64	dns64.herpf.fff.community

eigener DNS Server als Cache mit forwarding

Es kann auch ein eigener DNS Server betrieben werden und auf einen Freifunk DNS Server geforwardet werden.

siehe hier:
unbound als Cache mit forwarding
unbound als Cache mit forwarding auf DoT

eigener rekursiver Resolver mit Static-Stub

Wenn der Server die angefragten Domains nicht vorkonfiguriert weiterleitet, sondern den Namen selbst über die DNS Root Server auflöst, spricht man von einem rekursiven Resolver. Da aber unsere IP-Adressen nicht global aufgelöst werden können muss man die verantwortlichen Server selbst eintragen. Aktuell sind es 3 Reversezonen die eingetragen werden müssen. Optional kann man auch die Domain selbst eintragen, das beschleunigt die Namensauflösung ein bisschen.

Hierbei ist zu beachten, dass die rekursiven Abfragen (IPv4 und IPv6) immer aus dem FFF-Netz heraus kommen sollten. Das ist für die Teilnehmer besser, da so die Antworten auf das FFF-Netz angepasst sind, was zu meißt kürzeren Routen zu externen Adressen führt. Da man dies in bind9 nicht direkt konfigurieren kann, sollte dies sichergestellt (metric, o.ä.) werden. Daher bietet sich hier eher unbound an. Ist es nicht möglich die Abfragen von FFF-internen Adressen zu führen, können die externen IPs auch entweder via babel announced werden oder (sofern die IPs statisch sind) auch in der Datei external.dnsserverips im Git [5] eingetragen werden. Ist auch das nicht möglich, muss die fff.community Zone geforwardet werden (kein Static-Stub).

Hinweis: Wenn ein eigener DNS-Server betrieben werden soll, sollte man unbedingt in Betracht ziehen auch die deutschlandweiten Freifunk-Zonen zu übernehmen. Wie das geht, steht hier: https://wiki.freifunk.net/DNS

siehe hier:
bind9 als rekursiver Resolver
unbound als rekursiver Resolver

eigener rekursiver Resolver als autoritativer DNS

Die Grundfunktionalität ist wie beim Static-Stub, nur werden unsere eigenen Zonen hier auf dem Server selbst gespeichert.

siehe hier:
bind9 als autoritativer DNS mit DNS64 und Split-View

Beispielhafte Installation

Die Installation könnte dann etwa so aussehen:

cd /etc/bind

cat <<EOF >> named.conf.local
zone "50.10.in-addr.arpa" {
    type static-stub;
    server-addresses { 10.50.40.10; 10.83.252.11; 10.50.252.0; 10.83.252.62; };
};

zone "fff.community" {
    type static-stub;
    server-addresses { 10.50.40.10; 10.83.252.11; 10.50.252.0; 10.83.252.62; };
};
EOF

aptitude install python-yaml
git clone https://github.com/freifunk/icvpn-scripts.git
git clone https://github.com/freifunk/icvpn-meta.git
echo 'include "/etc/bind/named.conf.icvpn";' >> named.conf

cat <<EOF > update-icvpn.sh
#!/bin/bash
cd /etc/bind/icvpn-meta
git pull
cd ..
icvpn-scripts/mkdns -x franken -f bind -s icvpn-meta > named.conf.icvpn
/usr/sbin/rndc reload
EOF
chmod +x update-icvpn.sh

# falls das sich wg. fehlendem yaml beschwert wird python3 für das script verwendet - dann python3-yaml nachinstallieren!
./update-icvpn.sh

echo "10 2    * * *   root    /etc/bind/update-icvpn.sh" >> /etc/crontab

Der DHCP sollte natürlich auch angepasst werden:

In der dhcpd config:

• option domain-name "fff.community";
• Bitte auch keine Freifunk Fremden DNS Server verteilen, wenn kein eigener DNS betrieben werden soll, lieber einige vorhandene Freifunk DNS Server announcen.

Danach:

• /etc/init.d/isc-dhcp-server restart

Konfigurationsbeispiele

In den aufgeführten Beispielen müssen die <XXXXX> jeweils durch selbst gewählte DNS Server und/oder eine der Anycast Adressen ersetzt werden. Vorzugsweise IPv6 vorrangig und IPv4 als sekundäre.

unbound als Cache mit forwarding

Konfigurationsdatei: /etc/unbound/unbound.conf

server:
  access-control: 10.0.0.0/8 allow
  access-control: 127.0.0.0/8 allow
  access-control: 192.168.0.0/16 allow
  access-control: fc00::/7 allow
  cache-max-ttl: 14400
  cache-min-ttl: 1200
  hide-identity: yes
  hide-version: yes
  interface: 0.0.0.0
  interface: ::0
  rrset-roundrobin: yes
 
# Enable or disable whether TCP queries are answered or issued.
do-tcp: yes

# Enable  or disable whether the upstream queries use TCP only for
# transport.  Useful in tunneling scenarios.
#tcp-upstream: yes

# If enabled id.server and hostname.bind queries are refused.
hide-identity: yes

# If enabled version.server and version.bind queries are refused.
hide-version: yes

# If yes, Unbound doesn't insert authority/additional sections
# into response messages when those sections are not required.
minimal-responses: yes

# If yes, message cache elements are prefetched before they expire
# to keep the cache up to date.
prefetch: yes

# Send minimum amount of information to  upstream servers to
# enhance privacy.
qname-minimisation: yes

# Enabled or disable whether the upstream queries use SSL only for
# transport.
# ACHTUNG! Nur einschalten wenn als Forwarder DoT Server verwendet werden
# ansonsten auskommentieren!
#ssl-upstream: yes

# Use 0x20-encoded random bits in the query to foil spoof
# attempts.
use-caps-for-id: no

forward-zone:
   name: "."
   forward-addr: <XXXXX>
   forward-addr: <XXXXX>
   [optional noch mehr]

unbound als Cache mit forwarding auf DoT

folgende Parameter müssen zur Konfiguration ohne DoT geändert werden:

tcp-upstream: yes
ssl-upstream: yes

forward-zone:
    name: "."
    forward-addr: <XXXXX-DNS64>@853#<XXXXX-DNS64-Servername>

unbound als Cache bei mehreren Hoods auf einem Gateway

Bei mehreren Hoods arbeitet DNS je nach Hood auf verschiedenen IP-Adressen. Will man nun den DNS-Cache analog zur Konfiguration mit Community DNS-Servern einheitlich auf den Transfer-Adressen nutzen, muss die Antwort-IP-Adresse an die jeweilige Quell-IP-Adresse angepasst werden. Dafür ergänze folgenden Parameter in der Konfigurationsdatei: /etc/unbound/unbound.conf

# Listen on all addresses on all (current and future) interfaces,
# detect the source interface on UDP queries and copy them to
# replies. Experimental feature, default value is no.
interface-automatic: yes

Als alternative Methode können auch für jedes Interface, also jede Hood, die IPv4 und IPv6 Adressen im jeweils für die Hood reservierten Adressband konfiguriert werden. Dies darf dann nur nicht vergessen werden, wenn später im Betrieb neue Interfaces hinzukommen.

bind9 als rekursiver Resolver

named.conf oder named.conf.options und named.conf.local; je nach Betriebssystem

acl icvpnlocal {
	10.0.0.0/8;
	172.16.0.0/12;
	fc00::/7;
};

options {
	directory "/tmp";

	auth-nxdomain no;
	listen-on port 53 { any; };
	listen-on-v6 port 53 { any; };
	recursion yes;
	allow-query-cache { icvpnlocal; localhost; };
	allow-recursion { icvpnlocal; localhost; };
	dnssec-validation no;
	
	zone "." {
		type hint;
		file "/etc/bind/db.root";
	};
	
	zone "50.10.in-addr.arpa" {
		type static-stub;
		server-addresses { <XXXXX>; <XXXXX>; };
	};
	
	zone "83.10.in-addr.arpa" {
		type static-stub;
		server-addresses { <XXXXX>; <XXXXX>; };
	};
	
	zone "d.b.9.2.2.0.6.5.3.4.d.f.ip6.arpa" {
		type static-stub;
		server-addresses { <XXXXX>; <XXXXX>; };
	};
	
	zone "fff.community" {
		type static-stub;
		server-addresses { <XXXXX>; <XXXXX>; };
	};
	
	include "/etc/bind/icvpn-zones.conf";

	// be authoritative for the localhost forward and reverse zones, and for
	// broadcast zones as per RFC 1912
	
	zone "localhost" {
		type master;
		file "/etc/bind/db.local";
	};
	
	zone "127.in-addr.arpa" {
		type master;
		file "/etc/bind/db.127";
	};
	
	zone "0.in-addr.arpa" {
		type master;
		file "/etc/bind/db.0";
	};
	
	zone "255.in-addr.arpa" {
		type master;
		file "/etc/bind/db.255";
	};
};

unbound als rekursiver Resolver

zu beachten ist, dass man die Anfragen (IPv4 und IPv6) immer aus dem FFF-Netz heraus stellt. Ansonsten bekommt man bei Subdomains von fff.community nicht die internen IP-Adressen ausgeliefert. folgende Parameter müssen zur forwarding Konfiguration hinzugefügt/entfernt werden:

  # file to read root hints from.
  # get one from https://www.internic.net/domain/named.cache
  root-hints: "/var/lib/unbound/root.hints"
  auto-trust-anchor-file: /var/lib/unbound/root.key
  do-ip4: yes
  do-ip6: yes
  prefer-ip6: yes
  outgoing-interface: <public Freifunk IPv6>
  outgoing-interface: <lokale 10er Netz IPv4>

stub-zone:
  name: 50.10.in-addr.arpa
  stub-addr: <XXXXX>
  stub-addr: <XXXXX>

stub-zone:
  name: 83.10.in-addr.arpa
  stub-addr: <XXXXX>
  stub-addr: <XXXXX>

stub-zone:
  name: d.b.9.2.2.0.6.5.3.4.d.f.ip6.arpa
  stub-addr: <XXXXX>
  stub-addr: <XXXXX>

stub-zone:
  name: fff.community
  stub-addr: <XXXXX>
  stub-addr: <XXXXX>

forward-zone:
   name: "."
   forward-addr: <XXXXX>
   forward-addr: <XXXXX>
   [optional noch mehr]

randomisierte Upstream IPv6

Um DNS spoofing zu erschweren bietet es sich an für den Upstream einen IPv6 Netzwerkblock anstelle einer einzelnen Adresse zu verwenden. Dafür muss man sich ein eigens dafür genutztes IPv6/64er Netz klicken, routing einrichten und im ifup an das lo interface hängen. Dann benutzt unbound für jede Abfrage (welche via IPv6 gemacht werden kann) eine zufällige Adresse aus diesem Netzblock.

ifup

ip -6 addr add <public IPv6 Präfix>/64 dev lo
ip -6 ro add local <public IPv6 Präfix>/64 dev lo

unbound config

	outgoing-interface: <public IPv6 Präfix>/64
	outgoing-interface: <lokale 10er Netz IPv4>

bind9 als autoritativer DNS mit DNS64 und Split-View

Bei dieser Konfiguration ist der Server autoritativ für die fff.community Domain und beantwortet Anfragen für diese und unsere Reversezonen direkt. Da der Server autoritativ ist muss er auch Anfragen aus dem Internet beantworten. Diese Anfragen landen dann im external-view und es werden dort hin nur Antworten für unsere Zone gegeben und auch nur öffentlich erreichbare IPs herausgegeben.

Autoritative Server sollten nur in Absprache erstellt und auch als solche in der Zonendatei im Git [6] eingetragen werden.

Die nötigen Scripte und Konfigrationsbeispiele für den autoritativen Teil befinden sich im Git [7]

Für DNS64 benötigt man noch einen weiteren view

named.conf

[..]
view "icvpn-internal-dns64-view" {
	match-destinations {
		<separate IPv6 für dns64>;
		<anycast-dns64>;
	};
	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";

	[..]

	zone "." {
		type hint;
		file "/etc/bind/db.root";
	};
};
[..]

Der letzte Eintrag (zone ".") sorgt dafür, dass bind9 alle anderen Anfragen rekursiv auflöst. Das bitte nur bei den internen views setzen.

Alternativ kann die "." Zone auch an unbound geforwarded werden. Dann kann im unbound dnssec aktiviert werden und funktioniert dann wenigstens fürs Internet.

zone "." {
	type forward;
	forward only;
	forwarders {
		::1 port <unbound port>;
	};
};

um doppeltes Cachen zu unterbinden muss man in den bind9 optionen dann noch folgendes setzen:

	max-cache-size 0;

bekannte Probleme

Kommen folgende 4 Dinge zusammen:
1. bind ist autoritativ für eine Zone
2. diese Zone delegiert Subdomains an andere Server (NS) für welche bind nicht autoritativ ist
3. bind ist neben der Aufgabe als autoritativer Server auch Resolver
4. für die Aufgabe als Resolver ist in bind ein Forwarder eingetragen (ist bind selbst rekursiver Resolver tritt das Problem nicht auf)

Wird nun ein Hostname der delegierten Subdomain angefragt, kommt es zu einer Schleife zwischen bind und dem Forwarder mit folgender Fehlermeldung:

DNS format error from <FORWARDER> resolving <HOSTNAME> for <CLIENT>: Name <OWN AUTH DOMAIN> (NS) not subdomain of zone <DELEGATED SUBDOMAIN> -- invalid response

Um das Problem zu beheben müssen im Forwarder für die von bind delegierten Subdomains die jeweils dafür verantwortlichen Nameserver explizit für die Subdomain als Forwardingserver eingetragen werden.

Testen

Testen können wir, indem wir vom DNS Server des Gateways (localhost/127.0.0.1) eine DNS-Auflösung abfragen.

Ein DNS Resolve für freifunk-franken.de ... dig @127.0.0.1 freifunk-franken.de

...sollte von uns selber (Server localhost; 127.0.0.1) beantwortet werden:

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5819
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:
;freifunk-franken.de. IN A
;; ANSWER SECTION:
freifunk-franken.de. 3599 IN A 31.172.113.113	
.
. 
.
;; Query time: 117 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 08 14:16:32 EEST 2015
;; MSG SIZE  rcvd: 275

Welche DNS Server ein angeschlossener Client angeboten bekommt, kann laufzeitaktuell mit folgenden Befehlen abgefragt werden:

nmcli device show <Netzwerkschnittstelle> | grep "IP4.DNS"
nmcli device show <Netzwerkschnittstelle> | grep "IP6.DNS"

Script um die Reverse DNS Zone zu erstellen

Viel Magie, liegt jetzt im Git: [8]

Monitoring

Ein quick&dirty Monitor ist hier: [9]