dnssec: einfach und schnell gemacht? ein praxisbericht zur ... · veri kation i.d.r. nur durch...

Einfuhrung Ausgangslage Greifswald DNSSec-Theorie DNSSec-Middleware

DNSSec: Einfach und schnell gemacht?Ein Praxisbericht zur Einfuhrung an der

Universitat Greifswald

UniversitatsrechenzentrumG.K. Grubert

20.03.2019


Wozu braucht man DNSSec uberhaupt?

geringe Verbreitung lasst praktischen Nutzen anzweifeln

es gibt eigentlich funktionierende Alternativen

ABER:

es gibt keine funktionierenden Alternativen

hat man DNSSec, hat man automatisch alle daraufaufbauende Features(z.B. DANE, SSHFP)

Universitatsrechenzentrum Greifswald – rz.uni-greifswald.de 1

https://rz.uni-greifswald.de


Warum ist DNSSec so wenig verbreitet?

Implementierung konnte einfacher sein

praktisch keine umfassenden Dokumentationen vorhanden

⇒ man muss ganze Domains analog zum bisherigenDNS-Management mit DNSSec einsetzen konnen

Designproblem bei Nutzung authoritativer Nameserver?

Weitere Grunde?

⇒ Sie selbst haben sicher ausreichend ...




Nutzung von DNSSec bei DFN-Mitgliedern




Nutzung von DNSSec bei DFN-Mitgliedern

Basis: DFN-Mitgliederliste (https://www.dfn.de/verein/mv/mitglieder/)

Stand: 11.03.2019

Ergebnis bei 342 analysierten Mitgliedern

Nutzung von DNSSec: 42

Nutzung von DANE: 20


https://www.dfn.de/verein/mv/mitglieder/



Pre-DNSSec-Situation

Verwendung von Bind

Einsatz eines LDAP-basierten Echtzeit-DNShttp://bind-dlz.sourceforge.net/

es gibt keine Zonenfiles

ausschließliche Verwendung von authoritativen Nameservern

Nutzung von ACL-basierten DNS-Views




Pre-DNSSec-Situation




Anforderungen an die DNSSec-Implementierung

Beibehaltung der Datenpflege im zentalen LDAP-IdMS

Beibehaltung der DNS-Views, d.h. Beibehaltung von Bind

DNSSec muss fur interne Clients beim Zugriff aufauthoritative Nameserver moglich sein

DNSSec-Signatur aller Zonen in allen Views fur alle Domainsder Universitat Greifswald muss vollautomatisch laufen(einziger Eingriff darf DS-RR-Meldung an Registrar sein)

Verlust der Echtzeitfunktionalitat wird in Kauf genommen




Funktionsweise




Funktionsweise

DNSSec-Aktivierung erst durch KSK-Publizierung inParentzone und vollstandiger Keychain bis zur Rootzone⇒ unsignierte delegierte Subdomains moglich

fur Details befragen Sie einfach die Suchmaschine Ihres geringsten Misstrauens




Praktische Umsetzung

Schlusselerstellung (Key-IDs beachten)dnssec-keygen -K /var/lib/dnssec/keys -a ECDSAP384SHA384 <ZONE>

dnssec-keygen -K /var/lib/dnssec/keys -a ECDSAP384SHA384 -f KSK <ZONE>

Zone signieren# change into directory where zone file is located

cd <ZONEDIRECTORY>

dnssec-signzone -K /var/lib/dnssec/keys -g -x -S -o <ZONE> <ZONEFILE>

-g erzeugt Datei mit Delegation Signer Resource Record-x DNSKEY Resource Record wird nur mit KSK signiert-S Smart Signing (automatisches Key-Management)-T TTL nur dann andern, wenn Sie wissen, was Sie tun!

Update der Parentzonebereitgestellter DS RR

<ZONE> <TTL> IN DS 29234 14 1 BF1D9B52148C41E804A4DBCFF93EB64C68D2FC9F

<ZONE> <TTL> IN DS 29234 14 2 1D33D20F353CB50BACC0DBA0388A64C73CE87EFD...

NS RR der Zone




Visualisierung an einem Beispiel

http://dnsviz.net




Keyrollover (ZSK, Parentzone)

neuen ZSK erstellen (es liegen nun 2 ZSKs gleichzeitig vor)

Zonensignatur unter Vorhandensein beider ZSKs




Keyrollover (ZSK, Parentzone)

alten ZSK nach TTL-Ablauf loschen

Zone nur noch mit neuem ZSK signieren

DNSSec-Kontrolle durchfuhren!




Keyrollover (KSK, Parentzone)

neuen KSK erstellen (es liegen nun 2 KSKs gleichzeitig vor)

Zonensignatur unter Vorhandensein beider KSKs

DS RR in Top Level Domain (TLD) eintragen lassen





DS RR fur den alten KSK in der TLD loschen lassen





TTL-Ablauf der TLD abwarten (DE-Zone: 24h)

alten KSK loschen

Zone nur noch mit neuem KSK signieren

DNSSec-Kontrolle durchfuhren!




Verifikation (ad-Flag)

Verifikation i.d.R. nur durch DNS-Server-Software

authoritative Nameserver verifiziert sich nicht selbst⇒ ohne Caching-Resolver in der eigenen Einrichtung i.d.R. keine Verifikation moglich⇒ Caching-Resolver vs. ACL-View-Konzept

⇒ Losung ist Einsatz eines Local Resolvers

https://rz.uni-greifswald.de/support/dokumentation/anleitungen/dnssec/


https://rz.uni-greifswald.de/support/dokumentation/anleitungen/dnssec/



Praktische Hinweise

Nur im echten Bedarfsfall in die Signatur-TTLs eingreifen.

Bitte kein RSA-Schlusselverfahren mehr benutzen.

Inline-Signing ist nur dann sinnvoll, wenn man sowieso mitZonenfiles arbeitet.Zusatzliches DNSSec-Monitoring:

ZSK/KSK mussen via DNS-Abfrage in allen Zonen verfugbar seinGultigkeitsdauer der RRSIG RR prufenZonen mussen ad-Flag liefern

Es gibt leider keinen”Hierarchie-Automatismus“

⇒ Dann muss man diesen eben schaffen ...




Der Hierarchie-Automatismus

Erstellen einer Datenstruktur, fur welche Zonen es schonKSKs und ZSKs gibtLoop uber alle Views ausfuhren

Loschen aller vorhandenen DS-RR-FilesListe aller Zonen erstellenPrufen, ob Zonenfiles leer sindErstellen einer Datenstruktur, um die DNS-Hierachie abzubilden(fur jede Zone muss bestimmt werden, welches die Parentzone ist)fur jede Zone bestimmen, an welcher Hierarchieebene die Zone angesiedelt istZonen signieren(mit den Zonen in der untersten Hierarchieebene beginnen)Prufen, ob die Zone uberhaupt signiert werden muss oder nichtPrufen, ob KSK/ZSK vorhanden sind(Topzone: Pflicht, Subzone: werden dynamisch erstellt)Zone signierenDS/NS-RR in Parentzone eintragen

Loschen nicht benotigter KSKs/ZSKs




Konfiguration

[dnssec-middleware]

ZonesToSign = [...],ugreif.de,uni-greifswald.de,[...]

Views = urz,intern,extern,umg

TTL = 3600

#LogFacility = local2

#LockFile = /var/run/dnssec-middleware.lock

#RunFile = /var/lib/runtime/dnssec-middleware.lastrun

#KeyDir = /var/lib/dnssec/keys

#ZonefileDir = /var/lib/bind/zones

#KeyAlgorithm = ECDSAP384SHA384

# (default)

#KeyAlgorithm = RSASHA512 -b 2048

# (alternatively)

#Bin_keygen = /usr/sbin/dnssec-keygen

#Bin_signzone = /usr/sbin/dnssec-signzone




Einbindung in das DNS




Ergebnis

Aufbau und Test an einer Dummydomain (ca. 1,5 Monate)

Scharfschaltung fur uni-greifswald.de am 02.01.2019

Scharfschaltung fur all unsere Domains am 31.01.2019DNSSec-basierte Features fallen praktisch vom Himmel:

DANE (u.a. Postfix tls policys dane-only an DANE-Domains)SSHFP (VerifyHostKeyDNS=yes)SSH-Public-Keys der Nutzer stehen fur Serveranmeldungen im DNS bereit




Fazit

Die Middleware macht’s

Falls Sie derzeit mit Zonenfiles arbeiten oder IhrenDNS-Datenbestand in Zonenfiles abbilden konnen, sind Sie relativeinfach DNSSec-ready!

Ausblick

Erweiterung der Middleware fur einen vollautomatischenKeyrollover



dnssec: einfach und schnell gemacht? ein praxisbericht zur ... · veri kation i.d.r. nur durch...

Documents