DNSSEC: Neuer Vertrauensanker für Dnsmasq

Am 11. Juli 2017 hat die DNS-Root-Zone einen neuen kryptografischen Schlüssel zur Absicherung von DNS-Informationen erhalten (Vertrauensanker). Während der Übergangsphase, die bis Januar 2018 dauern soll, stecken nun sowohl der alte Schlüssel als auch der neue in der Root-Zone. Alle validierenden DNS-Resolver müssen den neuen Schlüssel beziehen und zur Validierung von signierten DNS-Antworten verwenden. Beim Validieren prüft ein Resolver, ob die DNS-Daten unverfälscht sind und ob der Absender der Nachricht vertrauenswürdig ist. Die Umstellung auf den neuen Schlüssel muss spätestens bis zum 11. Oktober erfolgen. Andernfalls setzt der DNS-Dienst des betreffenden Resolvers aus. Im Weiteren beschreiben wir, wie man den neuen Schlüssel im populären Dnsmasq einrichtet.

Dnsmasq ist genau genommen kein Resolver, sondern ein validierender DNS-Forwarder. Als solcher ist er auf die Zuarbeit von Servern wie BIND9, Unbound oder Knot angewiesen (auch Upstream-Resolver genannt). Daher wirkt es sich für Dnsmasq nicht ganz so fatal aus, wenn er am 11. Oktober ohne passenden Schlüssel dasteht: Er kann dann immerhin unsignierte DNS-Daten abfragen lassen – sofern der Upstream-Resolver den neuen Key hat, liefern solche Anfragen immerhin die IP-Adressen von unsignierten Domains (und darauf entfällt der Großteil der Domains).

Beliebt, weil schnell

Dnsmasq ist unter anderem deshalb beliebt, weil er bereits gestellte Anfragen aus seinem lokalen Cache beantwortet – die Clients erhalten die Adressen von bereits angefragten Zielen schneller als bei Anfragen, die sie zum Beispiel an den Resolver des Providers stellen. Dnsmasq findet sich zum Beispiel auf Linux-Systemen in Verbindung mit dem NetworkManager, auf Fedora- und Ubuntu-Linux, auf Routern mit OpenWRT-Linux und auch in vielen Heim-Routern von kommerziellen Herstellern.

Dnsmasq kann signierte DNS-Antworten seit der Version 2.69 selbst validieren. Dazu muss der Upstream-Resolver signierte DNS-Antworten lediglich durchleiten, also nicht selbst validieren. Dnsmasq setzt man am besten zur Absicherung der DNS-Daten auf der "letzte Meile" ein, also zum Beispiel zwischen einem DNS-Resolver beim Provider und dem eigenen LAN. Als Resolver kommen auch die DNS-Server von Google oder von Xiala in Frage.

Die aktuelle Version von Dnsmasq ist 2.77. Die Versionsnummer der installierten Instanz lässt sich mit diesem Befehl auslesen:

dnsmasq --version

Der Befehl liefert eine Ausgabe wie diese:

Dnsmasq version 2.77 Copyright (c) 2000-2016 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify


Der Ausgabe kann man unter anderem entnehmen, dass diese Instanz mit DNSSEC-Funktionen kompiliert worden ist. Das ist die Grundvoraussetzung zum Validieren. Außerdem muss die Funktion beim Start der Software aktiviert werden. Dazu trägt man in der Konfigurationsdatei /etc/dnsmasq.conf das Schlüsselwort dnssec ein oder gibt es beim Programmstart auf der Kommandozeile an (dnsmasq --dnssec). Daneben benötigt Dnsmasq die aktuellen Vertrauensanker der DNS-Root-Zone. Dazu ist ein Eintrag in der Konfigurationsdatei /etc/dnsmasq.conf oder in /etc/dnsmasq.d/trust-anchor.conf erforderlich. Das macht die Software nicht selbstständig, aber mit einem gewöhnlichen Editor wie pico lässt sich das schnell per Hand nachtragen. Der Abschnitt sollte so aussehen:

# The root DNSSEC trust anchor, valid as at 10/02/2017
# Note that this is a DS record (ie a hash of the root Zone Signing Key)
# If was downloaded from https://data.iana.org/root-anchors/root-anchors.xml


trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

Der erste Eintrag mit der Schlüsselnummer 19036 entspricht dem alten Key-Signing-Key (KSK), der zweite entspricht dem neuen, der ab Oktober 2017 verwendet werden soll (Schlüsselnummer 20326).

Sind beide Vertrauensanker eingetragen, starten Sie Dnsmasq neu. Beim Neustart trägt die Software einige Statusmeldungen ins Syslog oder in das Systemd-Journal ein. Darunter sollte auch die Meldung stehen, dass die DNSSEC-Validierung eingeschaltet ist (enabled):

Jul 18 16:06:37 dnsmasq-box dnsmasq[11528]: started, version 2.77 cachesize 150
Jul 18 16:06:37 dnsmasq-box dnsmasq[11528]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect
Jul 18 16:06:37 dnsmasq-box dnsmasq[11528]: DNSSEC validation enabled
Jul 18 16:06:37 dnsmasq-box dnsmasq[11528]: using nameserver 2001:4860:4860::8888#53
Jul 18 16:06:37 dnsmasq-box dnsmasq[11528]: using nameserver 8.8.8.8#53
Jul 18 16:06:37 dnsmasq-box dnsmasq[11528]: read /etc/hosts - 6 addresses

Kleiner Validierungstest

Stellt man einem solchen Dnsmasq mit dem Programm dig eine DNS-Anfrage nach einer signierten Domain, sollte es validierte Daten liefern. Das zeigt dig mit dem Flag ad an. Das ad-Flag steht für Authentic Data. So sieht ein Beispiel für die signierte Domain dnssec.works aus, wenn man die Anfrage auf dem Rechner stellt, auf dem Dnsmasq installiert ist:

dig @localhost dnssec.works
; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> @localhost dnssec.works
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42883
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dnssec.works. IN A

;; ANSWER SECTION:
dnssec.works. 3599 IN A 5.45.109.212


;; Query time: 154 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Jul 18 16:20:04 UTC 2017
;; MSG SIZE rcvd: 57

In der Answer-Section sollte die IP-Adresse der Domain dnssec.works stehen. Zurzeit ist das 5.45.109.212. (dz)