Sagt mal… Kann dieser lustige Microsoft Windows Server 2012 nun eigentlich DNSSEC? Ja klar, kann er es aber mich meine so richtig? Also kann der mit dem Schlüssel umgehen mit dem die ROOT-Zone unterschrieben wurde?
Weiß dass gerade zufällig jemand oder muss ich dafür wirklich ne TestVM aus dem Glas ziehen?
Schlagwort: DNSSEC (Seite 2 von 2)
OpenSSH bietet die Möglichkeit die Fingerprints der Host Keys in einer DNS Zone als SSHFP-RECORD zu speichern. Dieses ermöglicht bei einem Verbindungsaufbau, die Fingerprints gegenn welche in der DNS Zone zu validieren. Es kann daher helfen, sich z.B. gegen man in the middle Angriffe zu schützen. Ist die Zone zusätzlich noch per DNSSEC (http://www.kernel-error.de/dnssec) geschützt, hat man schon eine recht hohe Sicherheit gegen solche Angriffe. Dieses zielt hauptsächlich darauf ab, Zugriffe per Kennwort zu sichern. Basiert das Login auf SSH Schlüssel, kann ein Angreifer im seltensten Fall etwas mit den Daten anfangen, dennoch hilft jedes Stückchen mehr Sicherheit! OK, es steht und fällt alles wieder beim Thema DNS, daher bitte auf DNSSEC achten.
Damit SSH auch prüft ob es im DNS einen passenden RECORD gibt muss folgendes in die Konfigurationsdatei /etc/ssh/ssh_config eingetragen werden, sofern man es global für alle Benutzer auf seinem Client aktivieren möchte:
$ echo "VerifyHostKeyDNS yes" >> /etc/ssh/ssh_config
Soll es für die eigene Benutzerumgebung geschehen liegt diese Konfigurationsdatei natürlich unter: ~/.ssh/ssh_config Soll es nur für die aktuelle Sitzung aktiviert werden, lässt es sich als Option einfach mitgeben:
$ ssh -o "VerifyHostKeyDNS=yes" www.kernel-error.de
Baut man nun eine Verbindung auf, fragt OpenSSH den DNS Server ob dieser Informationen zum erwarteten Fingerprint liefern kann. Sind keine Einträge in der DNS Zone vorhanden schaut der Verbindungsaufbau wie folgt aus:
$ ssh -v www.kernel-error.de OpenSSH_5.5p1 Debian-6+squeeze2, OpenSSL 0.9.8o 01 Jun 2010 ..... DNS lookup error: data does not exist The authenticity of host 'www.kernel-error.de (2001:7d8:8001:100::dead:beef)' can't be established. RSA key fingerprint is fc:aa:73:17:bc:6a:0a:4f:af:3a:98:9e:73:b8:c4:68. No matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?
Um dieses zu „verbessern“, gibt mehrere Möglichkeiten die SSHFP RR für seine Zone zu erstellen. Es gibt das Programm sshfp…
$ sshfp www.kernel-error.de www.kernel-error.de IN SSHFP 1 1 f9dfcb6311e31da8c267ae53a5830887bd2bb3b3 www.kernel-error.de IN SSHFP 2 1 97179afabaaf9b68b05dbf1357cffe3de6ce76fe
Dann gibt es unter anderem noch die, von mir präferierte Lösung, direkt per ssh-keygen auf dem Zielhost (Server):
$ ssh-keygen -f /etc/ssh/ssh_host_rsa_key.pub -r www.kernel-error.de. www.kernel-error.de. IN SSHFP 1 1 47890eecc9a2893061734b07b8f60caa1a856148 www.kernel-error.de. IN SSHFP 1 2 b2518ad49cc2adf517d3f6a9faaf4017abc2c3e33dae0a29c46226e9ff691cd2 $ ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -r www.kernel-error.de. www.kernel-error.de. IN SSHFP 3 1 3dd9de0dcf1523341b45a53f1d57043609e26c62 www.kernel-error.de. IN SSHFP 3 2 e1c76bd66b5a0641789b0b37be5b80ae3f6395c1cd2b73cca532a8111c9515b4
Dabei ist der SSHFP-RECORD wie folgt aufgebaut:
Zielhost ==> Protrokollart ==> RR-Typ ==> Host-Key Algorithmus ==> Hash-Art des FP ==> Fingerprint
Folgende Host-Key-Algorithmen sind bisher definiert:
- 1 ssh-rsa
- 2 ssh-dss
- 3 ecdsa
- 4 ed25519
Hash-Arten des FP sind dabei SHA1 und SHA2(56). 1 wäre dabei SHA1 und 2 logischerweise SHA2
Diese fertigen RECORDS kann man nun in seiner DNS-Zone veröffentlichen, dass die Zone zum Host zu passen hat, muss ich ja sicher nicht mehr erwähnen, oder?
Baut man nun die Verbindung erneut auf, findet OpenSSH auch etwas.
$ ssh -v www.kernel-error.de OpenSSH_5.5p1 Debian-6+squeeze2, OpenSSL 0.9.8o 01 Jun 2010 ..... debug1: found 2 insecure fingerprints in DNS debug1: matching host key fingerprint found in DNS The authenticity of host 'www.kernel-error.de (2001:7d8:8001:100::dead:beef)' can't be established. RSA key fingerprint is fc:aa:73:17:bc:6a:0a:4f:af:3a:98:9e:73:b8:c4:68. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?
Natürlich lassen sich die Einträge auch mit dig abrufen:
$ dig +short www.kernel-error.de IN SSHFP 3 1 3DD9DE0DCF1523341B45A53F1D57043609E26C62 3 2 E1C76BD66B5A0641789B0B37BE5B80AE3F6395C1CD2B73CCA532A811 1C9515B4 1 1 47890EECC9A2893061734B07B8F60CAA1A856148 1 2 B2518AD49CC2ADF517D3F6A9FAAF4017ABC2C3E33DAE0A29C46226E9 FF691CD2 SSHFP 7 3 86400 20160307114536 20150313114536 13952 kernel-error.de. hib4uoiPCBlAXytsVHsqvGdGDRPdec42nA2J7IW8mQVV/o7fb5kPfV6J ZIp4D6O0RsSWW++9QzvCd0gHiTQcQLXdpypCoSBbLYGpWnBl3zCk9zFS iLhawl79VFun7xccZU9UjWoHRyrEo5pDfN3heBgT4ycjlB2m0i40D5WQ 25pCh95yAnSB/wchW4MwffDgc+10GrRcpxWL662k6pFRpLFHsDZ2YS6c zYEK2u1nAc0hI0XqtJrXxDxZZ9reHWvmk5wAK3LHcoWOv5DFP6LyIzY8 omhm+zF9KzIt8V0PuzMD9rUfeZAZjjCsllxv39bx+UHcS0ZsKxpCV4Ny c2OSCOCyHjtc1+qgYuZlkL5rej7wOVvCTB5Jym4B0vTO7ct22/VoqEdh zLjiWXSDW87qkNnImGU1EXHMqOXU5qzxgKgRjMu6AfJYB+zRP2B2P5eJ I9sGWOWJIV24ot1dWisWeSvItXNHW84mzFVgqUUuMKZ5uQGocpWjMc7c b0h0o4P4D0HtarBuRV7Z6QsJjEy0zMst2PChi3y+WFP4ar7Tl59K3ePN 7Qw/695jjA2YitpUYWBZL052r5d2u9hBTZGPvxvJRjFfvNcdy7Sv3ii1 sl6dTp/XIlJ82xsVEwNEYqgSQVJwNEzIcH+doUF4pGKnFmOWG/NlXfYJ 9Kx2Xon6c7Y= SSHFP 10 3 86400 20160307114536 20150313114536 12698 kernel-error.de. dbv2KMbxb4Vd+kLz86hGjdc12b3/8THtIfThd8kjm5ik9Yxo3njcw60/ sJ9wvJ4/2AiBNoEebh3wUxnoJprqsjyEdIq+7mPggVhs6VV5Sl9GZoNM 1bzkq85xjHt9/KVzLwou9/s0t9PgZ3vl2wU6MMl5MvleGumw+w6DnZpz NXzX57IpMs3TCMHPVhpYglGjtRcDPnfFSqbLLwnM5rbidp80iEob/d3J Xm6lSPBuwrry4aAYErWMxxsDJBosXKGC2EQNKK5PrkVF9JbWwXUFXowU H9m1iNsDaRBP6xqKoa+I4efR9GNojb55s2Nh1b6T+9zVyjcclp2rYbt/ QL6l6GSTHvoP6L7o3H3heg1Q4uUu+mj7a8lEHfuF2jbp6afjrL17hR/b v7ArzP7PpV6KOmx15pBLH3V0GoEle7WKon65+6mNaDDvs5yh7LSd1Im3 zAi1C0TUkf4VN4MU+FhDh+r6KKsqh0WvP0hc7UaTcpEIH3ox7QbHGvf7 zxiBypRVfrrW3OQhQvRk6U4wIIx1XicaYRfkPmEL/OtYTc9B81dGe3ci JLZLedMCWifPtsO+B3ml5apH8+MTu7fyWEpf4NPz2egWzFkHYsl8Out8 2z7jzhPwgAfyZ2qr0z1SZWSpxvZ/P7LqNaauoFQxpyZT6/qFXA8M1quf Tornope2Y4E=
Wie immer bei DNSSEC zur Sicherheit prüfen ob die Antwort „sauber“ ist:
$ dig +dnssec www.kernel-error.de IN SSHFP |grep flags ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ; EDNS: version: 0, flags:; MBZ: 7e06 , udp: 512
In der Antwort muss das ad flag gesetzt sein!!!
Nach all dieser Arbeit könnte man nun noch OpenSSH anweisen, die Verbindung nur aufzubauen, wenn der Host-Key erfolgreich validiert werden konnte. Dieses wieder, wie oben beschrieben, in der /etc/ssh/ssh_config oder den anderen Stellen:
Host * StrictHostKeyChecking yes
Ich mag solche Dinge sehr 🙂 Sehr kleiner Aufwand und schon ist es um einiges sicherer…
Kleines Update 16.02.2015
ed25519 erst richtig ab OpenSSH Version 6.7, ecdsa fragwürdig sicher und dss bitte NICHT! Ich will sagen >= OpenSSH 6.6 4096bit RSA bitte 🙂
Der Verbindungsaufbau sieht in der aktuellen OpenSSH Version etwas anders aus. Erfolgreich sollte es so aussehen:
debug1: found 4 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS
Inzwischen arbeitet OpenSSH direkt mit DNSSEC, wenn möglich. Solltet ihr also der Meinung sein, Fingerprints und Zone korrekt konfiguriert zu haben, OpenSSH wird aber einfach nicht „glücklich“… Dann prüft doch mal bitte auf Extension mechanisms for DNS (http://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS)! Aktiviert sich normalerweise mit folgender Zeile in der /etc/resolv.conf
options edns0
Die Domain Name System Security Extensions (DNSSEC) sind eine Erweiterung des DNS, mit der Authentizität und Datenintegrität von DNS-Transaktionen gewährleistet werden. Ein DNS-Teilnehmer kann damit verifizieren, dass die durch den Server, mit dem er kommuniziert, gelieferten Zonendaten auch tatsächlich identisch mit denen sind, die der für die Zone autorisierte und die Zone signierende Server ausliefert. DNSSEC wurde als Mittel gegen Cache-Poisoning entwickelt, Serverauthentifizierung findet nicht statt. Wer jetzt noch genauere Informationen dazu haben möchte beginnt am besten >>hier<<….
Was mich beim ersten Lesen eines Artikels zu DNSSEC etwas durcheinander gebracht hat, war dieses Umhergewerfe mit den Begriffen: KSK, ZSK, SEP, DNSKEY, RRSIG und DS… Daher versuche ich das mal kurz verständlich zu erklären, den im Grunde ist das alles total einfach!
Der KSK (Key signing Key) hat grob gesehen nur eine einzige Aufgabe. Er muss den ZSK (Zone signing Key) unterschreiben. Der KSK ist nämlich immer in der übergeordneten Zone hinterlegt (von kernel-error.org ist die übergeordnete Zone z.B.: org). Der ZSK hat auch nur eine Aufgabe, das unterschreiben der Zone…..
Es beginnt also alles mit dem KSK der Rootzone. Die Rootzone ist „.“! Mal angenommen wir wollen nach www.kernel-error.org fragen. Dann geht es ganz oben los. Die Nameserver der Rootzone wissen welche Nameserver für die einzelnen TLDs (Top level domains) zuständig sind. Die Nameserver der TLDs wissen welche Nameserver für die einzelnen Unterdomains (z.B.: kernel-error.org) zuständig sind. Der Nameserver der Unterdomain kennt nun selbst die Adresse für www.kernel-error.org oder kann zumindest sagen welcher Nameserver für die Unterdomain „www“ zuständig ist. Will ein Angreifer nun also dafür sorgen dass man mit seinem Browser beim Aufruf von www.kernel-error.org nicht auf meinem Webserver landet, sondern auf seinem (bei Banken hätte das ja was, oder?), dann hat er zwei einfache Möglichkeiten.
- Er antwortet auf die Anfrage des Clients (wer ist denn der für die Domain kernel-error.org zuständige Nameserver) mit seinem eigenen Nameserver. Somit fragt der Client immer den Nameserver des Angreifers, welcher mit den falschen Adressen antwortet.
- Er antwortet auf jede Anfrage des Clients (mit gefälschter Absenderkennung) schneller als der eigentlich zuständige DNS-Server und kann so falsche Informationen übermitteln.
Mal angenommen man würde nun auf DNSSEC setzten und jeder Nameserver würde seine Zone signieren. Woher wüsste man dann, dass die Antwort korrekt ist? Angreifer können genau so signierte Antworten schicken. Genau, man muss die Gültigkeit der Signatur prüfen. Genau dafür ist nun der KSK. Der KSK signiert die Zone und zusätzlich wird der KSK jeweils in der übergeordneten Zone bekannt gemacht. Die übergeordnete Zone wird mit dem ZSK signiert, welcher mit dem KSK der übergeordneten Zone unterschrieben wurde, dieser KSK ist natürlich wieder der Zone darüber bekannt…. Man kann also Stück für Stück nach oben gehen. Am Ende steht dann der KSK der Root-Zone. Die folgende Zeichnung soll das ganze noch verständlicher darstellen.
![DNSSEC Vertrauenskette](https://www.kernel-error.de/wp-content/uploads/2010/11/vertrauenskette.jpg)
Sollte es jemandem denn noch nicht klar sein, helfe ich gerne weiter. >>Einfach fragen<<
Es sind leider noch lange nicht alle TLDs signiert bzw. haben DS-Records in den Root-Servern. Eine ganz nette Liste über bereits signierte TLDs findet sich hier: https://www.tldwithdnssec.se/
Unsere DENIC hat ein .de testbed eingerichtet. Die Jungs wollen Anfang 2011 aber auch loslegen. Infos zum DENIC DNSSEC testbed gibt es hier.
Möchte man seine Domain per DNSSEC schützen muss natürlich als erstes der für die Domain zuständige DNS-Server DNSSEC unterstützen und es muss aktiviert sein. Klingt logisch, oder? Ich bin, unter anderem, ein Freund von Bind. Daher beschränke ich mich hier einfach mal auf diesen…. Ab ISC Bind 9.6.2 sind alle Tools und Funktionen wohl soweit ausgereift dass man es im Zusammenhang mit DNSSEC sauber nutzen kann!
DNSSEC schaltet man recht einfach im options-Block ein:
options { ........ dnssec-enable yes; dnssec-validation yes; ........ };
Recursive DNS-Server benötigen natürlich noch den KSK der Rootzone. Diesen muss man als vertrauenswürdig einstufen. Am einfachsten bekommt man diesen mit folgendem Aufruf:
$ dig . dnskey | grep -w 257 > dnssec_root.key
Diesen legt man jetzt im trusted-keys Block ab:
trusted-keys { . 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";<br />};</div> <p>Um sicherzustellen das man auch den richtigen bekommen hat, erstellt man kurzerhand daraus einen DS-Record und vergleicht diesen...</p> <div style="padding: 7pt; width: 100%; background-color: #7e0000;"># dnssec-dsfromkey -2 dnssec_root.key . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32 F24E8FB5
Für die Integritätsprüfung dieses Schlüssels hat die ICANN mehrere Methoden spezifiziert. Dieses liest sich sehr gut >>hier<<.
Nun sollte man Bind neu starten, damit er die Änderungen übernimmt. Theoretisch ist Bind nun schon in der Lage mit DNSSEC umzugehen.
Frage ich z.B.: meinen DNS-Server zuhause nach einer signierten Domain (www.cacert.org), das Flag +ad fordert den Nameserver auf die Antwort per DNSSEC zu validieren:
$ dig +ad www.cacert.org SOA @2a01:198:6ce::1
Dann bekomme ich die folgende Antwort.
![dig +ad www.cacert.org SOA](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec01.jpg)
Möchte man wissen ob sein DNS-Server überhaupt DNSSEC beherrscht, setzt man bei seiner Anfrage einfach das Flag +dnssec
Beherrscht der gefragte Nameserver DNSSEC erhält man signierte Records….
$ dig +dnssec www.cacert.org SOA @2a01:198:6ce::1
![dig +dnssec www.cacert.org SOA](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec02.jpg)
Gehen einem die, gleich erstellten, Schlüssel verloren, oder die signierte Zonendatei brennt ab, hat mein ein Problem. Genau wie bei der eigentlichen Einrichtung oder Aktualisierung ist die Reihenfolge sehr wichtig und einzuhalten. Denn die rekursiven DNS-Server halten ja für die Zeit der TTL die Abfrage im Cache…. Somit könnte man, bei falschem Vorgehen, für die Zeit der längsten TTL ~nicht~ erreichbar sein!
Ich habe mir folgenden Masterplan fürs DNSSEC aufgestellt. Im Grunde nichts weiter also vor jeder „großen“ Änderung immer die längste TTL der Zone abzuwarten und fertig! Dieses habe ich mir mal irgendwann aufgemalt (nicht schön aber extrem selten). Hier also dieses ~analoge~ Bild!
![Analoger DNSSEC Masterplan](https://www.kernel-error.de/wp-content/uploads/2010/11/DNSSEC-MASTERPLAN-scaled.jpg)
Nun könnte man schon beginnen seine Zonen zu signieren. Dazu muss natürlich erstmal ein neuer Schlüssel erzeugt werden. In meinem Fall dreht sich alles um die Domain kernel-errror.org
Um für diese ZONE nun einen 4096 Bit langen KSK zu erzeugen gibt man folgendes ein:
$ dnssec-keygen -r /dev/urandom -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE kernel-error.org Kkernel-error.org.+007+55836
Den ZSK für die ZONE erstellt man mit:
$ dnssec-keygen -r /dev/urandom -a NSEC3RSASHA1 -b 4096 -n ZONE kernel-error.org Kkernel-error.org.+007+25685
Nun finden sich im Verzeichnis vier neue Dateien. Kkernel-error.org ist die Domain, +007 ist der Schlüsseltyp und +55836 bzw. +25685 ist die ID des Schlüssels. Die Endung .key bezeichnet jeweils den öffentlichen Teil, .privat steht für den privaten Teil. Den privaten Teil sollte keiner in die Finger bekommen
Den öffentlichen Teil des KSK und des ZSK müssen nun noch in der Zone hinzugefügt werden.
$ cat *.key >> kernel-error.org
Der öffentliche Teil des KSK ist zusätzlich der Teil, welcher in der übergeordneten Zone publiziert werden muss. In diesem Fall müssen also die Jungs an den Root-Servern der TLD .org einen DS aus unserem öffentlichen KSK erstellen und ihn neben die NS-Records klatschen! Das läuft überall etwas anders. Die Vorgehensweise von der DENIC und EURID schaut so aus, dass man seinen öffentlichen KSK dort hinschickt die Jungs basteln daraus einen DS-Record (sie trauen es einem wohl nicht selbst zu) und veröffentlichen diesen daraufhin.
Somit kann man nun das eigentliche Zonenfile signieren 🙂 Folgender Aufruf erledigt dieses:
dnssec-signzone -r /dev/urandom -e +31104000 -k Kkernel-error.org.+007+55836 -f kernel-error.org.signed kernel-error.org Kkernel-error.org.+007+25685 Verifying the zone using the following algorithms: NSEC3RSASHA1. Zone signing complete: Algorithm: NSEC3RSASHA1: ZSKs: 1, KSKs: 1 active, 0 revoked, 0 stand-by kernel-error.org.signed
+31104000 ist hier etwas besonders. Denn das ist die Zeit in Sekunden, welche die Signatur gültig ist. In diesem Fall 360 Tage….
Nun teilt man Bind noch mit dass er anstelle der Zonendatei kernel-error.org die Datei kernel-error.org.signed >>laden<< soll, restart und schon ist die Arbeit fast beendet… Änderungen an der Zone nimmt man nun weiterhin wie gewohnt in der kernel-error.org vor, muss nach diesen Änderungen nur jeweils die Zone neu signieren. Ist ja klar, oder?
Man darf natürlich nicht vergessen den KSK in der übergeordneten Zone bekannt zu machen. Für die Publikation des KSK haben die meisten Registries ein Webinterface (meiner leider nicht :-/). Am Ende sind dann neben den NS-Records auch die nötigen DS-Records. Ob diese gesetzt sind findet man am besten heraus, indem man die DNS-Server der übergeordneten Zone (hier also die der TLD .org) danach fragt…..
$ dig org. in NS
Wirft uns die zuständigen DNS-Server für die TLD .org entgegen. Von diesen fischt man sich einfach einen heraus und fragt nach dem DS-Record der gewünschten Domain (ich frage einfach mal wieder nach cacert.org)!
$ dig +short @b2.org.afilias-nst.org cacert.org in DS cacert.org. 86400 IN DS 59365 3 1 DA0668FAF7F726EF64284FC8D1393CF3DD0A39C5 cacert.org. 86400 IN DS 59365 7 2 3A4F6F9F8CFB0FABB508CDE5E874206F159B8A893938A8792C091613 6CF499BD
Vom feinsten, oder?
Gibt es etwas besonders zu beachten, gibt es Probleme?
Ja, die gibt es :-/
Normalerweise läuft die Kommunikation mit den Nameservern über das UDP Protokoll, schlägt dieses fehl kommt der Fallback auf TCP. Das UDP Protokoll hat aber ein Größenlimit von 512 Bytes pro Paket. Die Schlüssel bei DNSSEC sind dafür einfach zu groß. Vor allem bei NSEC3 Schlüsseln! EDNS (Extension Mechanisms for DNS) heben dieses auf. EDNS (RFC 2671) erlaubt nämlich unter anderem größere Pakete. Dieses wurde alles schon 1999 festgelegt. Na ja, wie bei so vielen schönen Dingen hängt, wie z.B. bei IPv6, die Umsetzung leider etwas durch . Somit hat die ein oder andere Firewall, security appliance und vor allem einige plaste DSL-Router damit Probleme. Einige lösen einfach nichts mehr auf und andere erschrecken sich bei einer signierten Antwort so sehr, dass sie erstmal abstürzen!
Ich als Freund vom Firefox habe da noch ein Addon gefunden. Dieses Firefox Plugin, der DNSSEC Validator zeigt einem jeweils den Status der aktuellen Seite an: https://addons.mozilla.org/de/firefox/addon/64247/
* UPDATES 08.02.2011 *
Heute gibt es zwei schöne Updates….
1. DeNIC will die de-Domain bald signieren
2. Mein Registrar hat es endlich geschafft meinen DS-Record in der ORG-Zone zu veröffentlichen 🙂
![Domain kernel-error.org ist nun sauber signiert](https://www.kernel-error.de/wp-content/uploads/2010/11/valid.png)
Ich habe mir natürlich auch mal angeschaut in wie weit Microsofts Serverbetriebssystem hier mitspielt. Windows Server 2008 R2 SP1…. Der mitgelieferte DNS-Server soll/kann DNSSEC. Leider frisst der DNS-Server aus den Windows Sever 2008 R2 SP1 Boardmitteln nur Schlüssel vom Type SHA1. Das kommt daher, weil zuerst geplant war die ROOT-Zone so zu signieren. Später ist es dann aber doch SHA256 geworden. Daher lässt sich mit dem Systemeigenen DNS-Server nicht viel anfangen. Im SP2rc habe ich auch keine Verbessungen dazu gesehen. Wann dazu ein Update kommt, keine Ahnung 🙂
Davon mal abgesehen…. So geht es!
![Windows Server2008RC2 SP1 DNSSEC](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2008server01.jpg)
Klickt man im DNS-Manager mit der rechten Maustaste auf den gewünschten DNS-Server und geht dort in die Eigenschaften öffnen sich diese auch in einem neuen Fenster. Hier findet sich nun der Reiter: „Anchors für Vertrauensstellung“. Hier werden nun alle als vertrauenswürdig eingestuften Schlüssel aufgelistet. Die DNSKEYs der TLD se sind schon seit (ich glaube) 2007 signiert. Die Jungs haben Schlüssel vom Type SHA1… Diese lassen sich also importieren. Die Schlüssel besorgt man sich am einfachsten wieder mit dig:
$ dig se. dnsskey
![dig se. dnssec](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2008server02.jpg)
Nun ist es wohl am Einfachsten die Schlüssel in einen Texteditor zu werfern und dort schnell die Leerzeichen zu entfernen, sonst firsst der Windows Server 2008RC2 SP1 DNS-Server die Schlüssel nicht!
![DNSKEY se anpassen](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2008server03.jpg)
Dann schnell die Eingabeaufforderung des Admins öffnen und mit dem Befehl:
c:\>dnscmd /TrustAnchorADD se ##Schlüssel##
Den DNSKEY In den lokalen DNS-Server werfen…..
![Windows Server 2008RC2 SP1 DNS-Server DNSSEC](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2008server04.jpg)
Und schon ist der Schlüssel in der Liste 🙂 Auch wenn man damit keine vollständige Vertrauenskette bilden kann.
Wir warten also alle mal auf ein Update!
Was der Microsoft Server 2011 da kann, werde ich in den nächsten Tagen mal testen.
Ok, habe mir dann mal den Microsoft Windows Server 2011 SBS in den ESX4-Cluster geworfen…. Was soll ich sagen? Laut GUI kann der 2011 SBS Standard DNS-Server das auch ~noch~ nicht 🙁
![Microsoft Windows Server 2011 SBS DNSSEC](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2011server01.jpg)
Wer mit Microsoft Systemen und deren Boardmitteln arbeiten will, dem bleibt nichts weiter übrig als zu warten….
* UPDATES 22.02.2011 *
Ich habe gerade meine kernel-error.de Domain auch signiert. Mein Registrar hat den DNSKEY freundlicherweise direkt veröffentlicht. Das bringt zwar erst etwas, wenn die TLD de. offiziell signiert ist…. Denn noch fängt der frühe Vogel den Wurm (oder so ähnlich)!
Über die Resolver aus dem DeNIC Testbed kann natürlich auch jetzt schon sauber abgefragt werden!
![dnssec kernel-error.de denic testbed dnskey](https://www.kernel-error.de/wp-content/uploads/2010/11/kernel-error.jpg)
![DNSSEC Testbed DNSKEY kernel-error.de](https://www.kernel-error.de/wp-content/uploads/2010/11/kernel-error01.jpg)
* UPDATE 08.06.2011 *
Wooohoooo DeNIC hat ja inzwischen die TLD de sauber signiert. Inzwischen sind die DS-RR auch in der Root-Zone angekommen und nutzbar 🙂 Damit ist die TLD .de. fertig signiert und voll nutzbar *freu*
* UPDATE 28.02.2012 *
Ich habe gerade alles in die Wege geleitet um die Domain: kernel-error.com zu schützen.
Zusätzlich habe ich eine ganz nette Möglichkeit gefunden sich alles nett grafisch darstellen zu lassen. Für meine Domains wären es folgende Links:
Wer sich den Link anschaut, wird erkennen wie er schnell „seine“ Domain dort eintragen kann.
Um zu testen ob sein eigener Rechner derzeit überhaupt die Möglichkeit hat mit DNSSEC zu arbeiten klickt am besten kurz hier:
* UPDATE 27.05.2012 *
Wenn man schon eine so geschützten DNS-Server hat, dann lassen sich natürlich sehr gut darüber weitere Informationen als nur A-RECORDS oder ähnliches verteilen.
Ich habe hier https://www.kernel-error.de/dnssec/gpg-im-dns beschrieben wie sich die eigenen GPG Schlüssel über den DNS Server verteilen lassen und hier https://www.kernel-error.de/dnssec/ssh-key-im-dns ist beschrieben wie sich mit OpenSSH die Fingerprints einzelner Hosts mit dem DNS Server abgleichen lassen.
* UPDATE 12.10.2012 *
Ich glaub es nicht der geht… nö der geööööhhht!
Der Microsoft Windows Server 8 also öhm der Microsoft Windows Server 2012 kann es. Komplett sauber und ganz Microsoft in klickibunti… Ich habe sogar sinnige und nutzbare Informationen zu dem Thema bei Microsoft selbst gefunden.
Es lässt sich wirklich fast alles mit der Maus erledigen, vom Zonen signieren bis im Im- und Export von allem möglichen Zeugs. Auch eine Schritt für Schritt Anleitung habe ich gefunden. https://technet.microsoft.com/en-us/library/hh831411.aspx
Ich habe hier auch noch ein paar Bilder zum gucken!
![Windows Server 2012 DNSsec Windows Server 2012 DNSsec](https://www.kernel-error.de/wp-content/uploads/2010/11/windows-server-2012-01.png)
![Windows Server 2012 DNSsec Windows Server 2012 DNSsec](https://www.kernel-error.de/wp-content/uploads/2010/11/windows-server-2012-02.png)
![Windows Server 2012 DNSsec Windows Server 2012 DNSsec](https://www.kernel-error.de/wp-content/uploads/2010/11/windows-server-2012-03.png)
![Windows Server 2012 DNSsec Windows Server 2012 DNSsec](https://www.kernel-error.de/wp-content/uploads/2010/11/windows-server-2012-04.png)
* UPDATE 10.08.2013 *
Jetzt sind zusätzlich die TLS/SSL Schlüssel meiner Dienste per DANE mit dem DNS abgleichbar 🙂
* UPDATE 14.11.2012 *
Ich habe dann mal die Schlüssellänge auf 4096bit angepasst 😀