Man man man… Da bittet ein Kollege um ein Zertifikat, ich schraube das schnell zusammen und schiebe es im als .PEM – Base64-kodiertes Zertifikat, umschlossen von „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE—–“ zu.
Nun versucht dieser das Zertifikat auf seinem Windows Server zu importieren. Klappt aber so einfach nicht. Microsoft hätte nämlich gerne das Zertifikat als .PFX (.P12 – PKCS#12, kann öffentliche Zertifikate und private Schlüssel (Kennwort-geschützt) enthalten.) Macht ja auch Sinn wenn es eh in einer Zertifikatsverwaltung liegt und dass ganze Kennwortgeschützt ist. So ist es etwas sicherer, wenn die Datei mal jemanden in die Hände fällt, der es nicht haben soll!
Wie also nun aus PEM ein PFX machen? Openssl hilft:
telefon.de.key sowie telefon.de.crt sollten wir beim einfachen erstellen des Zertifikates per Openssl ja bereits haben. CACert.crt ist einfach der Zertifikat der CA, mit welchem unsere CSR unterschrieben wurde. Noch Fragen?
Vor einiger Zeit ist mir ein Buch mit dem Titel „Kabelsalat: Wie ich einem kaputten Kabel folgte und das Innere des Internets entdeckte“ empfohlen worden. Klang spannend, also bestellt. So eine Bestellung ist ja schnell gemacht, das Lesen dauert dann doch länger.
Inzwischen habe ich es durch und finde: nicht schlecht. Das Buch ist nicht so technisch, dass man es nicht versteht. Ich glaube selbst meine Mutter könnte es ohne Probleme lesen. Genau das ist aber auch der Punkt — wenn man sich für das Thema nicht interessiert, ist es trotzdem nichts. Wenn man wissen will, wie das Internet wirklich aussieht, sollte man es unbedingt lesen.
Wer ist Andrew Blum?
Andrew Blum ist Journalist und schreibt unter anderem für Wired und die New York Times. Der Anlass für das Buch war ziemlich banal: in seinem Garten in Brooklyn fing ein Eichhörnchen an, ein Kabel anzunagen. Sein Internet wurde langsam und immer wieder gestört. Beim Versuch zu verstehen, wo dieses Kabel eigentlich hinführt, stellte er fest, dass er keine Ahnung hat, wie das Internet physisch aufgebaut ist. Aus dieser Frage wurde dann eine Reise und am Ende ein Buch. Das Original heißt „Tubes: A Journey to the Center of the Internet“ und ist 2012 erschienen, die deutsche Übersetzung kam ein Jahr später im Heyne Verlag.
Was steckt drin?
Blum besucht die Orte, an denen das Internet tatsächlich existiert. Und das sind nicht „die Cloud“ oder „irgendwo im Netz“, sondern sehr konkrete Gebäude mit sehr konkreten Stromanschlüssen. Ein paar Stationen aus dem Buch:
DE-CIX in Frankfurt — einer der größten Internet-Knoten der Welt, in dem ein Großteil des europäischen Traffics zusammenläuft
MAE-East in Ashburn (Virginia) und das Equinix-Cluster drumherum, wo gefühlt das halbe US-Internet seine Pakete austauscht
Pionen, der ehemalige Atombunker in Stockholm, in dem damals unter anderem Bahnhof seine Server stehen hatte (auch Wikileaks war dort einquartiert)
Cornwall, wo Transatlantik-Glasfasern an Land kommen — inklusive der Verlegeschiffe, die das Zeug über tausende Kilometer auf den Meeresboden bringen
The Dalles in Oregon, wo Google eines seiner ersten großen Rechenzentren am billigen Strom des Columbia River gebaut hat
Blum erklärt dabei nebenbei, wie Peering überhaupt funktioniert, was ein Tier-1-Carrier ist, warum Glasfaserverbindungen genau so verlaufen, wie sie verlaufen, und wer diese ganze Infrastruktur eigentlich besitzt. Das Tempo ist dabei eher Reisereportage als Lehrbuch — wer schon BGP-Sessions konfiguriert hat, lernt fachlich nicht viel Neues, bekommt aber viele Geschichten zu Orten und Menschen, die hinter den abstrakten Begriffen stecken.
Update 2026: Was hat sich seit 2012 geändert?
Das Buch ist inzwischen über zehn Jahre alt. Die Grundstrukturen stehen noch genauso und an vielen Stellen hat sich die Logik sogar verfestigt, an ein paar Punkten ist die Realität aber weitergezogen:
Hyperscaler-Konzentration: AWS, Google, Microsoft und Meta betreiben mittlerweile eigene Backbones rund um die Welt und legen sogar eigene Seekabel. Was Blum bei Google in Oregon noch als Ausnahme beschreibt, ist heute Standard.
Submarine-Cable-Sabotage: Die Verletzlichkeit von Seekabeln war 2012 eher Theorie. Seit den Vorfällen in der Ostsee 2023/2024 reden auch Politik und Medien drüber.
RPKI und BGP-Hijacks: Routing-Sicherheit war im Buch nur am Rande Thema. Heute haben große Provider RPKI-Validierung eingeschaltet, und trotzdem gibt es regelmäßig Routenleaks. Wer mehr will, schaut bei bgp.tools oder im eigenen BGP-Beitrag vorbei.
Satelliten-Internet: Starlink, Kuiper und Co. haben einen Teil der Infrastruktur über die Wolkendecke verlagert. Das Buch endet noch mit dem Bild „alles läuft durch Glasfasern“. Stimmt nicht mehr ganz.
Datacenter-Strom: Was bei Blum als „günstiger Wasserkraftstrom in Oregon“ auftaucht, ist heute eines der Hauptthemen der Branche — Datacenter sind in vielen Regionen zur Belastung für das Stromnetz geworden.
Lohnt sich das Buch heute noch?
Ja, mit Einschränkungen. Wer das Internet nur als Cloud-Symbol auf einer Powerpoint-Folie kennt, dem öffnet das Buch die Augen. Wer schon mal in einem Rechenzentrum stand oder selbst Peering verhandelt hat, wird gelegentlich schmunzeln und sich bei den Reisebeschreibungen wiederfinden. Auf jeden Fall lesbar, nicht zu lang, gut geschrieben — und nach den 250 Seiten weiß man, warum „die Cloud“ eben doch ein paar sehr konkrete Adressen hat.
Thunderbird kann sich selbst konfigurieren. Der Benutzer gibt E-Mail-Adresse und Passwort ein, Thunderbird sucht die Servereinstellungen automatisch — kein Eintippen von Hostnamen, Ports oder Verschlüsselungsoptionen. Das funktioniert nicht nur bei Gmail oder GMX, sondern auch mit dem eigenen Mailserver. Man muss nur eine XML-Datei an der richtigen Stelle bereitstellen.
Wo Thunderbird nach der Konfiguration sucht
Thunderbird arbeitet eine feste Reihenfolge ab. Sobald ein Schritt eine gültige Konfiguration liefert, ist die Einrichtung fertig:
1. Thunderbird ISPDB — Mozilla pflegt eine zentrale Datenbank mit Konfigurationen für große Provider. Steht die Domain dort, ist sofort alles konfiguriert. Für eigene Mailserver irrelevant.
2. autoconfig.<domain> — Thunderbird fragt https://autoconfig.example.org/mail/config-v1.1.xml. Das ist der Weg, den wir nutzen. Ein CNAME im DNS, ein Webserver mit gültigem TLS-Zertifikat, eine statische XML-Datei — fertig.
3. .well-known auf der Domain — Thunderbird versucht https://example.org/.well-known/autoconfig/mail/config-v1.1.xml. Funktioniert, wenn die Domain selbst einen Webserver hat. Braucht keinen eigenen Hostnamen.
4. MX-Heuristik — Als Fallback versucht Thunderbird gängige Hostnamen wie imap.example.org und smtp.example.org mit üblichen Ports und Verschlüsselung. Klappt oft, ist aber Glückssache.
5. Manuell — Wenn nichts funktioniert, muss der Benutzer alles von Hand eingeben. Genau das wollen wir vermeiden.
Die config-v1.1.xml
Die XML-Datei beschreibt alle Servereinstellungen. Thunderbird liest sie und konfiguriert das Konto automatisch. Hier die Version, die ich für alle meine Maildomains einsetze:
%EMAILADDRESS% — Thunderbird ersetzt das automatisch durch die eingegebene E-Mail-Adresse. Kein PHP nötig, kein dynamisches Script — eine statische Datei reicht. Das ist der große Unterschied zu Outlook Autodiscover, wo ein PHP-Script die E-Mail-Adresse aus dem POST extrahieren muss.
password-cleartext — Klingt gefährlich, ist es nicht. Es bedeutet, dass das Passwort über die TLS-verschlüsselte Verbindung gesendet wird. Der Name ist irreführend — Mozilla meint damit „Klartext innerhalb des verschlüsselten Kanals“ im Gegensatz zu Challenge-Response-Verfahren wie CRAM-MD5.
Port 465 (implizites TLS) — Die Verbindung ist sofort verschlüsselt, kein STARTTLS-Handshake nötig. Ein Eintrag reicht — Thunderbird braucht keinen Fallback.
Mehrere <domain>-Einträge — Eine XML-Datei für alle Maildomains. Thunderbird prüft, ob die Domain der eingegebenen E-Mail-Adresse in der Liste steht.
DNS und Webserver
Für jede Maildomain wird ein DNS-CNAME angelegt:
autoconfig.vandemeer.de. IN CNAME www.kernel-error.de.
Alle CNAMEs zeigen auf denselben Webserver. Dort braucht jeder Hostname einen eigenen HTTPS-Server-Block mit passendem TLS-Zertifikat — Thunderbird akzeptiert keine Zertifikatsfehler. Die Nginx-Konfiguration ist simpel:
Das TLS-Zertifikat muss autoconfig.vandemeer.de als SAN enthalten. Bei Let’s Encrypt reicht ein certbot --cert-name vandemeer.de -d vandemeer.de -d www.vandemeer.de -d autoconfig.vandemeer.de beim nächsten Renewal.
Für Domains mit Wildcard-Zertifikat (*.kernel-error.de) entfällt das — der Hostname ist direkt abgedeckt.
Unterschied zu Outlook Autodiscover
Thunderbird und Outlook lösen dasselbe Problem auf unterschiedlichen Wegen:
Thunderbird Autoconfig — Statische XML-Datei, %EMAILADDRESS% als Platzhalter, GET-Request, kein serverseitiges Scripting nötig.
Outlook Autodiscover — POST-Request mit E-Mail-Adresse im Body, PHP-Script extrahiert den Benutzernamen dynamisch, DNS SRV-Records statt CNAME. Details dazu: Outlook Autodiscover für IMAP/SMTP
Beide können auf demselben Webserver laufen. Bei mir bedient autodiscover.kernel-error.de Outlook per POST und liefert gleichzeitig /mail/config-v1.1.xml für Thunderbird aus.
Wie gewohnt habe ich dann den TXT-RECORD in mein Zonenfile gekippt. Beim signieren der Zone per DNSsec sprang mich aber folgende Fehlermeldung an:
dnssec-signzone: error: dns_rdata_fromtext: kernel-error.de:25: ran out of space
Na nu? Ach so… ja klar! Der TXT-RECORD ist zu lang. Da gibt es ja eine Beschränkung…. Fast vergessen! Mehr als 255 Zeichen sind ja nicht zulässig. Ich musste den DKIM TXT-RECORD also in ein multi-line TXT-RECORD umwandeln. Nicht weiter kompliziert, einfach Klammer auf, Klammer zu und alles brav mit Anführungszeichen trennen. Damit sieht mein Zoneneintrag nun wie folgt aus:
----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result: pass (matches From: kernel-error@kernel-error.com)
ID(s) verified: header.d=kernel-error.com
Canonicalized Headers:
To:'20'<check-auth@verifier.port25.com>;'0D''0A'
Subject:'20'check-auth@verifier.port25.com'0D''0A'
MIME-Version:'20'1.0'0D''0A'
Content-Type:'20'text/plain;'20'charset=UTF-8;'0D''0A'
'20'format=flowed'0D''0A'
Content-Transfer-Encoding:'20'7bit'0D''0A'
Date:'20'Fri,'20'09'20'Nov'20'2012'20'11:33:48'20'+0100'0D''0A'
From:'20'Sebastian'20'van'20'de'20'Meer'20'<kernel-error@kernel-error.com>;'0D''0A'
Message-ID:'20'<c580aed4c89d48c1a93fea35ee80fe30@vandemeer.de>;'0D''0A'
DKIM-Signature:'20'v=1;'20'a=rsa-sha256;'20'c=simple/simple;'20'd=kernel-error.com;'0D''0A'
'09's=kernel-error.com;'20't=1352457228;'0D''0A'
'09'bh=v55t4Oe0VsnE3Xa3exogjgnS10dkjG1rhPQxGz4STJo=;'0D''0A'
'09'h=To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:'0D''0A'
'09''20'Date:From:Message-ID;'0D''0A'
'09'b=
Canonicalized Body:
check-auth@verifier.port25.com'0D''0A'
DNS record(s):
kernel-error.com._domainkey.kernel-error.com. 300 IN TXT "v=DKIM1; g=*; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtlhidIl+KZgelAOOVYiGHi+uGxEnpjmhXH2IVZNpH69ZsWYTYd1OgXIvWQnAiQ4rRCyvbjcrKaFnXJUpda9eGJeqlr3hE4YhOPLS34K86+8Gr17+WOofkdc3STmlqAI60r1+bQQh8rCWb1YPXIssinq3ll8GVDwAEmh3Bm8zSWz2Ntc+W/maURTlZbMGaRoi+lwhBzr+DnNYL+mPs3UVQoE9ei2Z/bjNQzdpzWeriFgfk56muVZNTvmn8LxkugMhoHMohCr/vkr99xTVmIeMFwMerB2B/JOpeADIf4Wsz6OJQR3GaBA91MX9T2nFncvW3pL03O4wYYVCGnFqz8gbcQIDAQAB"
NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions. If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.
Verschlüsselte E-Mail-Übertragungen sind meist ganz gut. Zumindest hält sie einem lästige Lauscher vom Hals. Besonders wichtig ist dabei der verschlüsselte Austausch zwischen Mail-Server und Mail-Client. Denn die User sitzen mit ihren Mail-Clients sehr schnell in einem „unsicheren“ Netzwerk. Daher wird inzwischen sehr oft und gut darauf geachtet diese Verbindungen zu sichern.
Die Verbindungen zwischen den Servern werden oft als nicht SO wichtig empfunden. Denn die Kisten stehen ja meist in gesicherten Bereichen (Serverraum, DMZ, Rechenzentrum) und dort zu lauschen ist schon aufwendiger – nicht unmöglich. Es macht also Sinn seinem Postfix zu ermöglichen seine Server zu Server Verbindungen kryptisch zu gestalten.
Mit folgender Änderung sagt man seinem Postfix dass bei ausgehenden Verbindungen TLS benutzt werden kann, wenn möglich.
$ postconf -e smtp_tls_security_level=may
Wird Postfix nun ein Zertifikat gereicht, welches von Postfix mangels der Root-Zertifikate nicht geprüft werden kann… Ja, dann ist hier schon wieder Ende.
Dass mein DNS-Server DNSsec http://www.kernel-error.de/dnssec beherscht und so meine Zonen schützt, das wissen ja fast alle. Wie man damit nun seinen GPG Schlüssel verteilen kann und/oder die SSH-Fingerprints einzelner Hosts gegen den DNS Server validieren lassen kann…. Dieses findet sich nun hier:
Hinweis: PKA (Public Key Association) wird von GnuPG seit Version 2.1 (2014) nicht mehr unterstützt. Der Nachfolger ist der OPENPGPKEY Resource Record, der den kompletten Schlüssel direkt im DNS speichert. Dieser Beitrag beschreibt das ältere PKA-Verfahren — historisch interessant, aber für neue Setups nicht mehr empfehlenswert.
Die Idee hinter PKA
GnuPG konnte über DNS nach GPG-Schlüsseln fragen. Der Vorteil: Ich muss meinen öffentlichen Schlüssel nicht auf Keyservern verteilen, sondern veröffentliche ihn über meinen eigenen DNS-Server. Ist die Zone per DNSSEC geschützt, kann der Schlüssel nicht gefälscht werden — deutlich vertrauenswürdiger als Keyserver, auf denen jeder beliebige Schlüssel hochladen kann.
PKA funktioniert mit einem TXT-Record, der den Fingerprint des Schlüssels und eine URL zum Download enthält. GnuPG prüft den Fingerprint gegen den heruntergeladenen Schlüssel — stimmt beides überein, wird der Schlüssel importiert.
Schlüssel exportieren
Zuerst den öffentlichen Schlüssel exportieren und auf dem Webserver ablegen:
Die exportierte Datei muss per HTTP erreichbar sein — HTTPS ist nicht zwingend nötig, da der Schlüssel am Ende gegen den Fingerprint aus dem DNS geprüft wird.
PKA-Record erstellen
Der PKA-Record ist ein TXT-Record unter localpart._pka.domain. Er enthält den Fingerprint und die URL zum Schlüssel:
kernel-error._pka.kernel-error.com. IN TXT "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"
Aufbau: Das @ in der E-Mail-Adresse wird durch ._pka. ersetzt. Der Record enthält die PKA-Version (v=pka1), den vollständigen Fingerprint (fpr=...) und die Download-URL (uri=...). Für jede E-Mail-Adresse, unter der man erreichbar ist, braucht man einen eigenen Record — auch über verschiedene Zonen hinweg.
Prüfen
Mit dig testen, ob der Record im DNS angekommen ist:
GnuPG fragt den PKA-Record ab, lädt den Schlüssel von der angegebenen URL herunter, prüft den Fingerprint und importiert den Schlüssel in den Keyring.
Warum OPENPGPKEY besser ist
PKA hatte zwei Schwächen: Der Schlüssel lag nicht im DNS selbst, sondern musste per HTTP heruntergeladen werden — ein zusätzlicher Angriffsvektor. Und der TXT-Record war auf 255 Bytes pro String begrenzt, was bei langen URLs und Fingerprints knapp wurde.
Der OPENPGPKEY Resource Record (RFC 7929) löst beides: Der komplette Schlüssel steckt direkt im DNS, kein HTTP-Download nötig. Mit DNSSEC ist die gesamte Kette vom DNS-Lookup bis zum Schlüssel kryptographisch abgesichert.
OpenSSH kann die Fingerprints seiner Host Keys als SSHFP-Records im DNS veröffentlichen. Beim Verbindungsaufbau prüft der Client dann automatisch, ob der Fingerprint des Servers mit dem DNS-Eintrag übereinstimmt, ein wirksamer Schutz gegen Man-in-the-Middle-Angriffe. Ist die Zone zusätzlich per DNSSEC gesichert, kann der DNS-Record selbst nicht gefälscht werden. Die Spezifikation steht in RFC 4255.
Client konfigurieren
Damit OpenSSH beim Verbindungsaufbau SSHFP-Records prüft, muss VerifyHostKeyDNS aktiviert werden. Global für alle Benutzer in /etc/ssh/ssh_config:
VerifyHostKeyDNS yes
Oder nur für die aktuelle Sitzung:
ssh -o "VerifyHostKeyDNS=yes" server.example.de
SSHFP-Records erzeugen
Am einfachsten direkt auf dem Server mit ssh-keygen, das erzeugt die fertigen DNS-Records für alle vorhandenen Host Keys:
ssh-keygen -r server.example.de.
Ausgabe (Beispiel mit RSA, ECDSA und Ed25519):
server.example.de. IN SSHFP 1 1 47890eecc9a2893061734b07b8f60caa1a856148
server.example.de. IN SSHFP 1 2 b2518ad49cc2adf517d3f6a9faaf4017abc2c3e3...
server.example.de. IN SSHFP 3 1 3dd9de0dcf1523341b45a53f1d57043609e26c62
server.example.de. IN SSHFP 3 2 e1c76bd66b5a0641789b0b37be5b80ae3f6395c1...
server.example.de. IN SSHFP 4 1 a1b2c3d4e5f6...
server.example.de. IN SSHFP 4 2 d4e5f6a7b8c9...
Aufbau des SSHFP-Records
Ein SSHFP-Record besteht aus zwei Zahlen und dem Fingerprint:
hostname IN SSHFP [Algorithmus] [Hash-Typ] [Fingerprint]
Algorithmus:
1, RSA
3, ECDSA
4, Ed25519 (empfohlen, ab OpenSSH 6.7)
DSS (2) ist seit OpenSSH 7.0 standardmäßig deaktiviert und sollte nicht mehr verwendet werden.
Hash-Typ: 1 = SHA-1, 2 = SHA-256. Beide sollten veröffentlicht werden, ältere Clients verstehen nur SHA-1, neuere bevorzugen SHA-256.
Prüfen
Mit dig lässt sich prüfen, ob die Records im DNS angekommen sind:
DNS lookup error: data does not exist
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
Mit SSHFP-Records und DNSSEC:
debug1: found 4 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
secure bedeutet: Die DNS-Antwort wurde per DNSSEC validiert. Ohne DNSSEC steht dort insecure, der Fingerprint wurde zwar gefunden, aber der DNS-Antwort selbst kann nicht vertraut werden. Für echte Sicherheit braucht man beides: SSHFP-Records und DNSSEC.
Strenge Prüfung erzwingen
Optional: OpenSSH anweisen, die Verbindung nur aufzubauen, wenn der Host Key erfolgreich validiert wurde:
Damit wird die Verbindung abgelehnt, wenn kein passender SSHFP-Record gefunden wird oder die DNSSEC-Validierung fehlschlägt. Das ist die sicherste Einstellung, setzt aber voraus, dass alle Zielserver SSHFP-Records haben.
Kleiner Aufwand, viel mehr Sicherheit. Fragen? Einfach melden.
Ich nutze Evolution als E-Mail Client. In den Zertifikatseinstellungen habe ich unter Zertifizierungsstellen auch eine ganze Latte von CAs. Ich kann auch welche hinzufügen und entfernen alles kein Problem.
Will ich aber deren Einstellung bearbeiten, sprich für welche Dinge ich dieser CA vertrauen möchte bleiben diese Einstellungen nur immer für die aktuelle Sitzung gespeichert. Schließe und Starte ich Evolution wieder sind die Einstellungen alles wieder weg 🙁 Das ist doof!
Wer sucht, der findet einen Workaround……..
Das Problem ist wohl dass Evolution aus irgendwelchen Gründen die cert9.db / key4.db unter ~/.pki/nssdb nicht updatet.
So kann ich mir anschauen was bei mir eingetragen ist:
$ certutil -L -d sql:/home/kernel/.pki/nssdb/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
StartCom Ltd. ID von Sebastian Van De Meer u,u,u
StartCom Class 2 Primary Intermediate Client CA - StartCom Ltd. ,,
CA Cert Signing Authority - Root CA ,,
CAcert Class 3 Root - Root CA ,,
StartCom Class 1 Primary Intermediate Client CA - StartCom Ltd. ,,
StartCom Certification Authority - StartCom Ltd. ,,
StartCom Ltd. ,,
StartCom Certification Authority ,,
......
Und so verpasse ich den einzelnen Zertifikaten die passenden „Verwendungsmöglichkeiten“:
DNSSEC (Domain Name System Security Extensions) schützt DNS-Antworten vor Fälschung. Ein anfragender Resolver kann damit prüfen, ob die gelieferten Zonendaten tatsächlich vom autorisierten Nameserver stammen und unterwegs nicht verändert wurden. DNSSEC wurde als Mittel gegen Cache Poisoning entwickelt — Serverauthentifizierung findet nicht statt.
Die Vertrauenskette
Was mich beim ersten Lesen zu DNSSEC durcheinandergebracht hat, war das Umherwerfen mit Begriffen: KSK, ZSK, DNSKEY, RRSIG, DS. Im Grunde ist es einfach:
Der KSK (Key Signing Key) hat eine Aufgabe: den ZSK unterschreiben. Der KSK wird als DS-Record in der übergeordneten Zone hinterlegt. Der ZSK (Zone Signing Key) hat auch nur eine Aufgabe: die eigentlichen Zonendaten unterschreiben.
Es beginnt bei der Root-Zone. Die Root-Server wissen, welche Nameserver für die TLDs zuständig sind. Die TLD-Server wissen, welche Nameserver für die einzelnen Domains zuständig sind. Jede Ebene signiert ihre Zone und veröffentlicht den DS-Record der Ebene darunter. So entsteht eine durchgehende Kette vom Root-KSK bis zu meiner Zone.
Will ein Angreifer dafür sorgen, dass www.kernel-error.org auf seinen Server zeigt, hat er zwei Möglichkeiten:
Er antwortet auf die Delegation-Anfrage mit seinem eigenen Nameserver.
Er antwortet mit gefälschter Absenderadresse schneller als der echte Server.
Mit DNSSEC kann der Resolver beide Angriffe erkennen — die gefälschte Antwort hat keine gültige Signatur.
DNSSEC in BIND aktivieren
Auf dem autoritativen Nameserver muss DNSSEC-Validierung aktiv sein. In modernen BIND-Versionen (ab 9.16) reicht im options-Block:
options {
dnssec-validation auto;
};
auto bedeutet, dass BIND den eingebauten Root-Trust-Anchor nutzt und diesen bei KSK-Rollovers automatisch aktualisiert (RFC 5011). Der alte dnssec-enable yes wurde in BIND 9.18 entfernt — DNSSEC ist seitdem immer aktiv.
Zone signieren — der moderne Weg
Seit BIND 9.16 gibt es dnssec-policy. Damit übernimmt BIND die Schlüsselerzeugung, das Signieren und den Key-Rollover vollautomatisch:
zone "kernel-error.org" {
type primary;
file "kernel-error.org";
dnssec-policy default;
inline-signing yes;
};
Die default-Policy verwendet ECDSAP256SHA256 (Algorithmus 13) — schneller und sicherer als das früher übliche NSEC3RSASHA1 mit 4096-Bit-Schlüsseln. inline-signing yes bedeutet: BIND signiert die Zone im Speicher, die Zonendatei auf der Platte bleibt unsigniert und lässt sich wie gewohnt bearbeiten.
Zone manuell signieren
Wer mehr Kontrolle will oder eine ältere BIND-Version hat, kann die Schlüssel von Hand erzeugen. KSK erstellen:
$ dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE kernel-error.org
Kkernel-error.org.+013+12345
ZSK erstellen:
$ dnssec-keygen -a ECDSAP256SHA256 -n ZONE kernel-error.org
Kkernel-error.org.+013+67890
Die öffentlichen Teile (*.key) in die Zonendatei einbinden und signieren:
$ cat Kkernel-error.org.+013+*.key >> kernel-error.org
$ dnssec-signzone -S -K /pfad/zu/keys -o kernel-error.org kernel-error.org
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone signing complete:
Algorithm: ECDSAP256SHA256: ZSKs: 1, KSKs: 1 active, 0 stand-by
kernel-error.org.signed
Dann BIND anweisen, die signierte Zonendatei zu laden. Nach jeder Änderung an der Zone muss neu signiert werden — oder man nutzt inline-signing, dann entfällt das.
DS-Record beim Registrar einreichen
Der öffentliche KSK muss als DS-Record in der übergeordneten Zone landen. Bei der DENIC (.de) und den meisten TLD-Registries gibt es dafür ein Webinterface beim Registrar. Man schickt den öffentlichen KSK hin, der Registrar erstellt daraus einen DS-Record und veröffentlicht ihn neben den NS-Records.
Ob der DS-Record gesetzt ist, lässt sich prüfen, indem man die TLD-Nameserver direkt fragt:
DNSSEC-Signaturen machen DNS-Antworten deutlich größer als die 512 Bytes, die klassisches DNS über UDP erlaubt. EDNS (RFC 6891) hebt dieses Limit auf. Das ist seit 1999 spezifiziert, aber manche Firewalls und Billig-Router haben damit immer noch Probleme — sie filtern große UDP-Pakete oder EDNS-Optionen.
Wichtig: Gehen die Schlüssel verloren oder die signierte Zonendatei brennt ab, hat man ein Problem. Vor jeder großen Änderung (Key-Rollover, Algorithmus-Wechsel) immer die längste TTL der Zone abwarten. Sonst sind gecachte Antworten mit der alten Signatur noch gültig, während die neue Signatur schon aktiv ist — die Zone wird temporär nicht validierbar.
Meinen „analogen“ DNSSEC-Masterplan dazu habe ich mir damals aufgezeichnet:
Was man auf DNSSEC aufbauen kann
Wenn die Zone signiert ist, lassen sich darüber weitere Sicherheitsmechanismen verteilen:
DANE/TLSA — TLS-Zertifikate per DNS verifizieren, unabhängig von CAs.
