DNSSEC und PowerDNS Peer Heinlein 1 / 79. Linux höchstpersönlich

Transkript

1 1 / 79

2 Desoxyribonucleinsäure (DNS) Oder: Der Stoff, aus dem das Internet ist. 2 / 79

3 Teil I: Aufbau und Funktionsweise des DNS 3 / 79

4 Die DNS-Rootserver Die DNS-Root-Server verwalten die ca TLD-Zonen Es gibt 13 Root-Server (A-M)...untersteht dem US-Handelsministerium Betrieben wird die Root-Zone durch Verisign 5 / 79 Verteilung per Anycast auf ~930 reelle Systeme Verwaltet wird das durch die ICANN Root-Server-Datei muß als Startpunkt den DNS-Servern bekannt sein...ebenfalls unter US-Recht...

5 Von wegen atombombensicheres Internet 6 / 79 Anfang 2000: 10 von 13 Servern in den USA, davon 6 Server auf kleinstem Raum an der USOstküste

6 2006: Mirror in der ganzen Welt 7 / 79 Seit 2006: 123 Server verteilt per Anycast über die Welt

7 2018: Rund 1000 Anycast-Root-Server weltweit 8 / 79

8 Teil II: Neue DNS-Records 9 / 79

9 TLS-Absicherung mit TLSA ( DANE ) Der Fingerprint eines Zertifikats kann im TLSA-Record hinterlegt werden _443._tcp.mailbox.org. _443._tcp.mailbox.org IN IN TLSA TLSA D7841E22492CC79[ ] E89750F7D9D0867C28[ ] Syntax: <certification usage> <selector> <matching type> <value> Umfassende Beschreibung in unserem Vortrag DNSSEC und DANE : 10 / 79

10 SSH-Absicherung mit SSHFP Beim ersten Connect ist ein SSH-Schlüssel unbekannt. Anwender akzeptieren ihn einfach. Mittels ssh-keygen kann der Fingerprint als fertiger SSHFP-Record angezeigt werden flash:~ # ssh-keygen -r server.example.com server.example.com IN SSHFP e3ac99d5865f87f92681ba754a18c690d913c3 server.example.com IN SSHFP 1 2 d8f04122f60a722cbf46777f25e0d f5e6b0[...] server.example.com IN SSHFP f4b288e45a2a47e0d1fc93ce232fd3208bb219 SSH-Client ggf. noch konfigurieren: 11 / 79 Syntax: <algorithmus> <hash> <value> 1: RSA 1: SHA-1 2: DSS 2: SHA-256 3: ECDSA 4: ED25519 VerifyHostKeyDNS ask oder VerifyHostKeyDNS yes in /etc/ssh/ssh_config eintragen!

11 TLS-Absicherung mit CAA Jede CA kann Zertifikate für jede Domain ausstellen und diesen wird dann vertraut. Mittels CAA-Record gibt ein Domainbesitzer bekannt, welche CAs Zertifikate ausstellen dürfen Seit 2017 müssen CAs den CAA-Record prüfen mailbox.org. mailbox.org. mailbox.org. mailbox.org IN IN IN IN CAA CAA CAA CAA iodef issue issue issue "mailto:mail@heinlein-support.de" "globalsign.com" "swisssign.com" "comodoca.com" Syntax: <flag> <tag> <value>: iodef: URL für Abuse-Meldungen issue: Diese CA darf Zertifikate ausstellen issuewild: Diese CA darf Wildcard-Zertifikate ausstellen 12 / 79

12 Autokonfiguration mit SRV-Records Auto-Konfiguration für Dienste wie Mail, XMPP, SIP, LDAP uvam. _xmpp-client._tcp.mailbox.org. 300 IN _autodiscover._tcp.mailbox.org. 30 IN 13 / 79 _<service>._<protokoll>.example.com. IN SRV SRV SRV xmpp.mailbox.org mailbox.org. <priorität> <gewichtung> <port> <ziel>

13 Weitere wichtige Records im Mail-Bereich DKIM SPF Policy, ob und wie mit DKIM signiert wird Sender Policy Framework Liste von IP-Adressen, die Mails mit diesem Absender versenden dürfen Definiert, wie Mails gebrochenem SPF oder DKIM behandelt werden sollen Details dazu in unserem Vortrag SPF, DKIM & Greylisting auf 14 / 79 Author Domain Signing Praxis DMARC Domain based Message Authentication, Reporting & Conformance Public Key eines serverseitig signierenden Mailservers ADSP Domain Key Identified Mail

14 Teil III: PowerDNS schmackhaft gemacht 15 / 79

15 PowerDNS History Existiert seit ~Ende 1990 Maßgeblich von Bert Hubert entwickelt (Niederlande) Seit 2015 Teil der Open Xchange AG (ebenso wie Dovecot) Allgemeine Community-Version reicht völlig aus Aber auch kommerzielle Lizenzen + Enterprise Support verfügbar Advanced Features erfordern Lizenz 16 / 79 Advanced Carrier Grade Anti-Abuse / Malware Parental Control Rate-Limiting / Protection

16 PowerDNS und PowerDNS sind zwei verschiedene Dinge... PDNS unterscheidet mitterweile zwischen den verschiedenen Rollen Authoritativer Server (gibt Antworten aus Zone-Files) DNS Recurser (löst allgemein auf) Getrennte Server / Instanzen für beide Rollen notwendig Bei BIND und im alten PDNS war das anders! Migrationen notwendig! 17 / 79

17 Die Backends von PowerDNS PowerDNS kann die Domaindaten in einer Vielzahl verschiedener Backends speichern Volle Featureunterstützung nur bei *SQL Aber auch Auslesen aus Hosts aus LDAP kann interessant sein Mischbetrieb möglich! Slaves kriegen Zonen-Files per AXFR-Verfahren im DNS (Hidden?) Master: LDAP Slave: SQL Volle Übersicht und backend-spezifische Konfiguration auf 18 / 79

18 19 / 79

19 Konfigurationen in PowerDNS Überschaubare Konfiguration in /etc/pdns/pdns.conf Eine grundsätzliche Modi wie Master, Slave, Dynamic Updates, DNSSEC hier global zu aktiveren Aber auch eine generischen Config-Optionen wie z.b. default-soa-name default-soa-mail default-ttl Viele Einstellungen können wahlweise in der pdns.conf global oder in den Domain-Metadaten individuell eingestellt werden, z.b.: ALLOW-AXFR-FROM ALLOW-DNSUPDATE-FROM ALSO-NOTIFY uvam. 20 / 79

20 PDNS-Tools: pdnsutil & pdns_control Arbeiten finden i.d.r. in Datenbanken statt daher full-service CLI notwendig Mit pdnsutil verwaltet man bequem Zonen und Inhalte: create-zone, delete-zone (Typ=Master, Typ=Slave o.ä.) add-record, delete-rrset, replace-rrset, clear-zone list-zone edit-zone (ggf: export EDITOR=joe vi emacs) Beispiel: pdnsutil add-record example.org www A Mit pdns_control triggert man einzelne Aktionen 21 / 79 Send-Notify an andere Nameserver der Domain o.ä.

21 PowerDNS: Abgefahrenes Zeug 22 / 79

22 DNSSEC Signing Nameserver als Proxy 23 / 79 PowerDNS kann als Slave live signing Alter NS hat kein DNSSEC aber tief gewachsene Infrastruktur Altes DNS-System als Hidden Primary belassen PDNS als Signing Proxy davor und diesen als Primary/Slave betreiben Slaves bekommen unsignierte Zonendatei Slaves bringen DNSSEC in die Zone rein und antworten mit DNSSEC Slaves geben signierte Zonen an andere Slaves ready-to-run weiter

23 Das GeoIP-Backend! Egal ob interne IP oder globales Loadbalancing: für verschiedene Client-IPs wollen wir unterschiedlich antworten können! PowerDNS braucht dazu eine GeoIP-Datenbank Und ein Zone-File in ASCII-Datei launch=geoip geoip-database-files=/var/lib/geoip/geoip.dat geoip-zones-file=/var/lib/geoip/zonefile.dat 24 / 79 Im GeoIP-Zonefile matchen wir den Client mit Variablen zunächst auf einen Service-Hostnamen Unter diesem Service-Hostnamen können dann (etwas umständlich) Records definiert werden PowerDNS probiert, welche Service-Hostnamen er findet => ansonsten matcht default

24 Die wichtigsten GeoIP-Platzhalter 25 / 79

25 domains: - domain: geo.example.com ttl: 30 records: geo.example.com: - soa: ns1.example.com hostmaster.example.com ns: content: ns1.example.com ttl: ns: ns2.example.com - mx: 10 mx.example.com de.eu.service.geo.example.com: - a: txt: hello world # this will result first record being handed out 10% of time unknown.service.geo.example.com: - a: content: weight: 10 - a: services: service.geo.example.com: default: [ '%co.%cn.service.geo.example.com', '%cn.service.geo.example.com' ] /8: 'internal.service.geo.example.com' 26 / 79

26 LUA als Scripting-Backend Lua-Backends können auch programmierte Aufgaben übernehmen LUA-Funktionen wie beispielsweise pickrandom: Zufallsergebnisse pickclosest: Liefert nächste IP zur Client-IP closestmagic: Liefert nächste IP zur Client-IP, braucht etwas kompliziert Hostnamen mit Ranges view: Clients aus verschiedenen IP-Netzen sehen unterschiedliche Antworten pickwhashed: Liste von Ergebnissen, wird gewichtet ermittelt createreverse: Generiert PTR nach Muster/Platzhaltern ( => static.example.com) createforward: Generiert Vorwärts-Lookup ( static.example.com => Aber auch: ifportup ifurlup 27 / 79 Geil.

27 LUA für Failover/Loadbalancing Darüber auch dynamisches Loadbalancing/Failover möglich www IN LUA A "ifportup(443, {' ', ' '})" www IN LUA A "pickclosest({' ',' ',' '})" www IN LUA A ("ifportup(443, {' ', ' ', ' '}" ", {selector='pickclosest'}) ") west www 28 / 79 IN IN LUA LUA A CNAME ( "ifurlup(' "{{' ', ' '}, {' '}}, "{stringmatch='programming in Lua'}) " " " ) ( ";if(continent('eu')) then return 'west.powerdns.org' " "else return 'usa.powerdns.org' end" )

28 LUA Scripting-Backend cool stuff LUA-Scripte können anderen Content includen kompakte zentrale Config möglich! Variablen können gesetzt und ausgewertet werden 29 / 79 config IN LUA LUA ("settings={stringmatch='programming in Lua'} "EUips={' ', ' '} "USAips={' '} " " ") www IN LUA CNAME ( ";if(continent('eu')) then return 'west.powerdns.org' " "else return 'usa.powerdns.org' end" ) usa IN LUA A ( ";include('config') "return ifurlup(' "{USAips, EUips}, settings) west IN LUA A ( ";include('config') "return ifurlup(' "{EUips, USAips}, settings) " " ) " " ) " "

29 Das PDNS Supermaster/Superslave-Setup Automatische Zonenkonfiguration auf einem Slave Dabei vertraut ein Slave einem Master als Supermaster Ab Version zusätzlich supermaster=yes in pdns.conf setzen! Erhält er ein NOTIFY einer bislang unbekannten Zone, wird diese automatisch als SLAVE eingerichtet und ein Zonen-Transfer gestartet. IP des Masters muß in der supermaster -Tabelle gelistet sein (bislang kein CLI-Kommando) Supermaster muß in NS-Records der Zone gelistet sein Ist die Notification mit einem TSIG-Key signiert, wird dieser Key gleich an die Domain gebunden Problem: Es gibt keinen Mechanismus um veraltete Zonen zu löschen 30 / 79 Admin muß sich selbst überlegen, wie er alte Zonen austrägt.

30 Teil IV: 31 / 79

31 So funktioniert DNSSEC (von unten nach oben gesehen) 32 / 79

32 Das ist ein A-Record :-) mailbox.org. IN A 33 /

33 Damit den keiner fälschen kann, brauchen wir eine digitale Unterschrift: mailbox.org. IN A mailbox.org. IN RRSIG A mailbox.org. JqMJ9tzkwU6Yn2unUzlsbr0 kvapvnvhvkzyauoarvozciswkzrpkeuz7swu 34 / 79

34 Damit wir die digitale Unterschrift prüfen können, brauchen wir einen Public Key. mailbox.org. IN A mailbox.org. IN RRSIG [...] mailbox.org. IN DNSKEY BQEAAAABwcvTaaZokGcz2HFSgv+ixKiuypnYzA3z/pu 9MlZ1XFD2qeN7KgVB/mmlvFKDUgKdraUV2m2KglZLzc 4d8GoXTnpLDhcWVJx9et9t 35 / 79

35 Damit der Public Key sicher ist ( Trust hat ), publizieren wir ihn in der nächsthöheren Ebene. mailbox.org. IN DS F226E410BFBD86BDE1FD276EC9E88D778449A65B BDCF1F218E4D1 9F / 79

36 Auch die TLD signiert unseren Key per RRSIG: mailbox.org. IN DS F226E410BFBD86BDE1FD276EC9E88D778449A65B BDCF1F218E4D1 9F mailbox.org. IN RRSIG DS org. b9owu3satlnaii7bp9+odhiwx 37 / 79

37 Damit wir die digitale Unterschrift der TLD prüfen können, hat auch sie einen Public Key: mailbox.org. IN DS [...] mailbox.org. IN RRSIG DS [...] org. IN DNSKEY AwEAAYpYfj3aaRzzkxWQqMdl7YExY81NdYSv+qayuZD odnz9imh0bwmcisdua7ssaiuziuz 38 / 79

38 Die TLD muß ihren Key als DS-Record in. veröffentlichen... Den Key von. müssen wir kennen / hart importieren. => Trust Chain steht. 39 / 79

39 root.hint: Ohne Vorwissen geht nichts! Resolver müssen die allerobersten DNSKEY-Records der Root-Nameserver kennen Muß halt ähnlich wie root.hint verteilt werden Hilfsweise: dig +nocomments +nostats +nocmd +noquestion -t DNSKEY. > trusted-key.key Clients verifizieren nicht, sondern vertrauen ihrem DNS-Resolver, dass dieser authenticated data liefert dig kann jedoch auch selbst validieren WENN entsprechend compiliert dig +topdown +sigchase +multiline +trusted-key=./trusted-key.key -t A heinleinsupport.eu 40 / 79

40 Soweit so gut. Aber nun fangen die Probleme erst an. 41 / 79

41 Die eigene Domain muß in die trust chain An irgendeiner Stelle ( Trust Anchor ) muß man beginnen, jemandem zu glauben. Im Idealfall ganz oben, also. auf den Root-Servern Hilfsweise irgendwo Quereinstieg und dann von dort aus abwärts ( Security Island ) Jeder signiert den Einstieg bei seinem Nachfolger Man muß seine Keys bei der nächst höheren Ebene hinterlegen Problem: Schlüsseltausch aufwändig/manuell durchführbar Regelmäßiger Schlüsseltausch aber sinnvoll! 42 / 79

42 Das Problem: Das Publizieren der Keys Automatische Verfahren zum Publizieren des Keys in der nächst höheren Ebene gibt es nicht. Wir wollen unseren Key aber von Zeit zu Zeit ohne Aufwand tauschen. Abhilfe: Wir ziehen eine weitere Ebene ein: 1) Wir signieren unsere Records mit einem Zone Signing Key (ZSK), den wir häufig (monatlich?) tauschen können 2) Der kurzlebige ZSK wird vom langlebigen Key Signing Key (KSK) signiert 3) Erst der KSK wird in der nächst höheren Ebene publiziert 43 / 79 => Wir haben also jeweils ZWEI Keys (ZSK + KSK).

43 Es gibt zwei Keys: KSK und ZSK Darum: DNSSEC kennt zwei verschiedene Key-Typen! ZSK (256): Zone-Signing Keys, unterschreibt Records in Zonen Häufiger Tausch sinnvoll Wird lokal vom KSK unterschrieben, vergleichsweise einfach automatisierbar Empfehlung: Monatlich tauschen KSK (257): Key-Signing Keys, unterschreibt andere (ZSK-) Keys Tausch aufwändig weil Upstream zu veröffentlichen Wird nur genutzt um Unterschlüssel zu unterschreiben Empfehlung: 1 x pro Jahr tauschen 44 / 79

44 KSK (TLD) ZSK (TLD) KSK (Domain) KSK (Domain) ZSK (Domain) 45 / 79

45 Howto: Einrichtung von DNSSEC mit PowerDNS 4.x 46 / 79

46 Die zwei DNSSEC-Betriebsmodi des PDNS Live-Signing Key-Material ist getrennt von den DNS-Records Signatur wird live bei Abfrage der Records erzeugt PDNS berechnet RRSIGS automatisch jede Woche neu Presignd Zone Zonendatei beinhaltet alle DNS-Records (DNSKEY, NSEC, RRSIG) PDNS bedient die Abfragen nach den Records, versteht quasi nichts von DNSSEC Unterschiede auf dem Slave: Enthielt der Zone-Transfer bereits alle Records? Enthielt die Zone keine DNSSEC-Records? Dann nachträgliches Live-Signing 47 / 79 Dann wird implizit presigned=yes gesetzt. Slave erkennt, wenn RRSIGs abgelaufen sind und macht Zone-Transfer, auch ohne daß die serial anstieg! Einsatz als Signing-Proxy ( Front-Signing )! Kann signierte Zone per Zone-Transfer an weitere Slaves geben!

47 Der Weg zu DNSSEC pdnsutil kann KSK und ZSK-Schlüssel erzeugen pdns1:~ # pdnsutil generate-zone-key ksk Generating a KSK with algorithm = 13 Flags: 257 Private-key-format: v1.2 Algorithm: 13 (ECDSAP256SHA256) PrivateKey: 1FfQkpZLkR4dS9yeYYssIOZBPtGEvfjrIEJFY79tZa8= pdns1:~ # pdnsutil generate-zone-key zsk Generating a ZSK with algorithm = 13 Flags: 256 Private-key-format: v1.2 Algorithm: 13 (ECDSAP256SHA256) PrivateKey: X1JFm/DWMgQx7CIqhaCc5hZ+hw+uHcUU9Vq1R+Dof2g= 48 / 79

48 Von Null auf DNSSEC in einem Schritt Alternativ erledigt pdnsutil auch alles in einem Rutsch: pdns1:~ # pdnsutil secure-zone peer.supportbycall.org Securing zone with default key size Adding CSK (257) with algorithm ecdsa256 Zone peer.supportbycall.org secured Adding NSEC ordering information Allerdings erzeugt PDNS dann nur einen ZSK (257) und verzichtet auf den Key-Split Begründung: Eh alles in Datenbank und live-signiert. DS-Record muß allerdings manuell extrahiert und upstream publiziert werden pdns1:~ # pdnsutil export-zone-ds peer.supportbycall.org peer.supportbycall.org. IN DS a02438ca777df1fbfb761d795e5eb1c74ded78 ; (SHA1 digest) peer.supportbycall.org. IN DS d02984c7327b57493bca36db71c35e415424b e956c3e72462df2ecdcb ; (SHA256 digest) peer.supportbycall.org. IN DS b110aeeb7182e c4041d83a b c25125e80e268539a44da4a0c 8a04b aca ; ( SHA-384 digest ) 49 / 79

49 Das DNSSEC einer Zone im Überblick pdnsutil zeigt den kompletten Zustand im Überblick: pdns1:~ # pdnsutil show-zone peer.supportbycall.org This is a Master zone Metadata items: None Zone has hashed NSEC3 semantics, configuration: ab keys: ID = 2 (CSK), flags = 257, tag = 56515, algo = 13, bits = 256 Active ( ECDSAP256SHA256 ) CSK DNSKEY = peer.supportbycall.org. IN DNSKEY WuE4eDgiCwdn/4Lqe7V7SaOL519ta5JdDW/71BqToPUJjw5Z175DUchBngbuqh95HpLSo0ZG0CWCOnpDhBWhLg== ; ( ECDSAP256SHA256 ) DS = peer.supportbycall.org. IN DS a02438ca777df1fbfb761d795e5eb1c74ded78 ; ( SHA1 digest ) DS = peer.supportbycall.org. IN DS d02984c7327b57493bca36db71c35e415424b e956c3e72462df2ecdcb ; ( SHA256 digest ) DS = peer.supportbycall.org. IN DS b110aeeb7182e c4041d83a b c25125e80e268539a44da4a0c8a04b aca ; ( SHA-384 digest ) 50 / 79

50 Die unsignierte Zone im Überblick supportbycall.org bla 51 / 79 NS NS A IN SOA ns.jpberlin.de. root.jpberlin.de. ( ; serial [...] ns.jpberlin.de. ns2.jpberlin.de

51 Die signierte Zone im Überblick supportbycall.org NS NS RRSIG IN SOA ns.jpberlin.de. root.jpberlin.de. ( ; serial [...] ns.jpberlin.de. ns2.jpberlin.de. NS ( supportbycall.org. RCvHznuQVC2KWtk+RZ DNSKEY DNSKEY bla 52 / ( F6am+W4bk87E= ( N/DrX56+g1a4sx4ekH ) ; key id = ) ; key id = RRSIG DNSKEY ( supportbycall.org. OUHmzQTlZuaYqvg4yQbVJClxD NSEC A RRSIG bla.supportbycall.org. A NS SOA DS RRSIG NSEC DNSKEY A ( supportbycall.org. 4I1S4b5GRgU3xH7O4

52 DNSSEC testen und debuggen 53 / 79

53 54 / 79 Prima DNS und DNSSEC-Validator:

54 55 / 79 Ebenso:

55 DNSSEC mit dig abfragen ; <<>> DiG <<>> bla.supportbycall.org +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;bla.supportbycall.org. IN A ;; ANSWER SECTION: bla.supportbycall.org IN A bla.supportbycall.org IN RRSIG A supportbycall.org. K5JgILUrc2XctYjkjH4I1S4b5GRgU3xH7O4PY4k9yfX9qjdSz8rnhg+s glrc3u/= DNSSEC-Antworten haben DO-Flag gesetzt Kaputtes DNSSEC führt zu NXDOMAIN 56 / 79

56 Die DNS-Flags im Überblick aa authoritative answer ad authenticated data Client bittet den Server um rekursive Auflösung ra recursion available 57 / 79 Antwort ist valide lt. DNSSEC. rd recursion desired Recursive Nameserver hatte Trust Anchor => Daten vertrauenswürdig do dnssec ok Daten kommen direkt vom authoritativen NS => Daten vertrauenswürdig Server würde Client rekursive Auflösung ermöglichen

57 DNSSEC einführen, DNSSEC abschalten DNSSEC bottom-up einführen Erst die Keys erzeugen und die Zone signieren Dann die DS-Records upstream veröffentlichen DNSSEC top down abschalten DS-Records upstream löschen (TTL abwarten!) 58 / 79 Verbindung steht, Clients erwarten DNSSEC-signierte Anworten! Verbindung unterbrochen, DNSSEC-Trust-Kette geht nicht mehr Keys in der Zone deaktivieren und löschen

58 Das Problem von Keys und TTL 59 / 79

59 Der Key-Rollover Werden Keys kompromittiert, müssen Sie ausgetauscht werden Webserver: Zertifikatstausch, Server-Restart, Fertig! Nameserver: Records mit alten Keys/Signaturen werden bis zu einer Woche lang gecacht Ein falscher Key-Austausch sorgt für ungültige Signaturen Ungültige Signaturen = Ungültige DNS-Records Ungültige DNS-Records = keine DNS-Records = Downtime Und eine Woche Downtime kann sehr lang sein! 60 / 79 Auch 1 Tag oder auch nur 5 Minuten Downtime sind inakzeptabel

60 So werden Keys getauscht Rechtzeitig vor Ablauf alten Keys werden parallel bereits neue Keys veröffentlicht Rechtzeitig = TTL-Zeit vor Ablauf! Nach dem Key-Wechsel müssen die alten Keys noch aktiv bleiben Gecachte Records müssen mit alten Keys noch validiert werden können Alte Keys also über die TTL-Zeit behalten Der Administrator muß permanent an den Key-Rollover denken! Empfohlener Zyklus: 1 x im Monat! TTL davor und danach Keys tauschen = fortlaufend zu tun haben 61 / 79

61 Wir brauchen eine fortlaufende Rotation Neue Keys müssen mindestens <TTL> vorher in die Zone aufgenommen werden, damit sie sicher bekannt sind. Erst dann darf mit ihnen signiert werden. Anschließend müssen Sie mindestens <TTL> in der Zone verbleiben, falls noch gecachte signierte Records kursieren. Key 1 Active Key 2 Published 62 / 79 <---- T T L - -> Key 1 Inactive Key 2 Active Key 3 Published Key 2 Inactive Key 3 Active Key 3 Inactive

62 Pre-Publish ZSK Zone Signing Key Rollover (RFC 6781) NEW DNSKEY: pdnsutil add-zone-key example.net zsk inactive ecdsa256 NEW RRSIG: pdnsutil activate-zone-key example.net <new-key-id> pdnsutil deactivate-zone-key example.net <old-key-id> Neuer Key signiert, alter Key signiert nicht mehr, wird aber noch ausgeliefert DNSKEY REMOVAL: pdnsutil remove-zone-key example.net zsk inactive ecdsa / 79 Neuer Key wird mit ausgeliefert, signiert aber noch nicht Alter Key wird auch nicht mehr ausgeliefert!

63 Pre-Publish KSK Zone Signing Key Rollover (RFC 6581) NEW KSK: pdnsutil add-zone-key example.net ksk active Neuer Key ist aktiv und signiert die anderen Keys DS CHANGE: pdnsutil show-zone example.net DS-Records upstream veröffentlichen! Abwarten, bis Key sicher verfügbar. DNSKEY REMOVAL: pdnsutil remove-zone-key example.net <old-key-id> 64 / 79 Alter Key wird auch nicht mehr ausgeliefert!

64 NSSEC und NSEC3 65 / 79

65 Beweise bitte, dass es keine Aliens gibt / 79 Vorhandene Records können nicht ausgetauscht werden gut. Aber was ist, wenn Abfragen und damit Records unterdrückt werden? Wie beweist man, daß es etwas NICHT gibt?

66 Zonewalking durch NSEC-Records NSEC-Records enthalten eine Liste vorhandener Records und den alphabetisch darauffolgenden Hostnamen Der letzte Record verweist wieder auf den alphabetisch Ersten supportbycall.org. bla.supportbycall.org. huhu.supportbycall.org. bla.supportbycall.org. A NS SOA DS RRSIG NSEC DNSKEY NSEC ( huhu.supportbycall.org. A RRSIG NSEC NSEC ( supportbycall.org. MX RRSIG NSEC NSEC ( Gegenproblem: Jeder kann sehen, was es gibt :-( 67 / 79 NSEC RRSIG NSEC RRSIG NSEC RRSIG Zonewalking : nmap -ssu -p 53 --script dns-nsec-enum script-args dns-nsec-enum.domains=example.com

67 NSEC3PARAM NSEC3 hasht die Hostnamen Der Ressource Record NSEC3PARAM definiert die benutzten Hash-Verfahren und den verwendeten SALT. ; supportbycall.org. NSEC3PARAM 1 <--- SALT ---> ABCDEF Hash Algorithm: The cryptographic hash algorithm used. 0 is Reserved. 1 is SHA Available for assignment. Flags: "Opt-out" (indicates if delegations are signed or not). Iterations: How many times the hash algorithm is applied. Salt: Salt value for the hash calculation. 68 / 79 Achtung: DNSKEY-Ciphers müssen NSEC3 können (=kein RSASHA1)!

68 Wechsel einer Zone auf NSEC3 in PDNS pdnsutil erledigt wieder mal alles recht bequem: pdns1:~ # pdnsutil set-nsec3 peer.supportbycall.org NSEC3 set, please rectify your zone if your backend needs it Ein rectify berechnet alle Records und Reihenfolge in einer Zone neu. Eigentlich nicht nötig, aber Ein Rectify kann nie schaden. 69 / 79 Edits Imports Komisches Zeug Kann der Slave auch automatisiert nach jedem Zone-Transfer machen.

69 Ist nun alles gut? Naja. Fast. Die letzte Meile vom Desktop zum Resolver ist idr. ohne DNSSEC Übermittelt wird nur das DO-Flag; dem Traffic wird aber so vertraut Client könnte selbst mit DNSSEC alles auflösen => unperformant Mein lokaler Provider bleibt (m)ein Unsicherheitsfaktor Alternative: DoH DNS over HTTPS Risiko: Zentrale Abfrageinstanz Google sehr daran interessiert und testet mit Mozilla/Firefox... Immenser Datenschutz zur Analyse DoT DNS over TLS Klassisches SSL/TLS auf Port 443 ( stunnel ) PowerDNS kann das Android neuerdigs auch 70 / 79

70 DNSSEC in der Zusammenfassung 71 / 79

71 Zusammenfassung: Die DNSSEC-Records im Überblick DNSSEC führt einige neue Record-Typen ein: DNSKEY: RRSIG: Next Secure Liste aller Records einer Zone (beweist, daß es etwas nicht gibt!) Next Secure V3 Wie NSEC, aber gehashte Hostnamen NSEC3PARAM: 72 / 79 Delegation von DNSSec für Subzonen NSEC3: Delegation Signer NSEC: Resource Record Signature Signatur für einen oder mehrere Records DS: Public-Key + Gültigkeiten Technische Parameter zu den Hashverfahren

72 Natürlich und gerne stehe ich Ihnen jederzeit mit Rat und Tat zur Verfügung und freue mich auf neue Kontakte. Wenn's brennt: 73 / 79 Peer Heinlein Mail: p.heinlein@heinlein-support.de Telefon: 030/ Heinlein Support 24/7 Notfall-Hotline: 030/

73 Ja, diese Folien stehen auch als PDF im Netz / 79

74 Soweit, so gut. Gleich sind Sie am Zug: Fragen und Diskussionen! 75 / 79

75 Heinlein & mailbox.org suchen: Admins, Consultants, Trainer, Helpdesk-Supporter! Wir bieten: Spannende Projekte, Kundenlob, eigenständige Arbeit, keine Überstunden, Teamarbeit...und natürlich: Linux, Linux, Linux / 79

76 Und nun... Vielen Dank für's Zuhören... Schönen Tag noch... Und viel Erfolg an der Tastatur... Bis bald. 77 / 79

77 Heinlein Support hilft bei allen Fragen rund um Linux-Server HEINLEIN AKADEMIE Von Profis für Profis: Wir vermitteln in Training und Schulung die oberen 10% Wissen: geballtes Wissen und umfangreiche Praxiserfahrung. HEINLEIN CONSULTING Das Backup für Ihre Linux-Administration: LPIC-2-Profis lösen im CompetenceCall Notfälle, auch in SLAs mit 24/7-Verfügbarkeit. 78 / 79 HEINLEIN HOSTING Individuelles Business-Hosting mit perfekter Maintenance durch unsere Profis. Sicherheit und Verfügbarkeit stehen an erster Stelle. HEINLEIN ELEMENTS Hard- und Software-Appliances für Archivierung, IMAP und Anti-Spam und speziell für den Serverbetrieb konzipierte Software rund ums Thema .

78 79 / 79

79 80 / 79