Einigen sehr aufmerksamen Bloglesern ist es ja inzwischen aufgefallen. Ja ich habe meine Schlüssel getauscht 🙂
Schlagwort: DNSSEC (Seite 1 von 2)
Mir ist in der letzten Zeit an ein paar Systemen ein kleines „Problem“ im Zusammenhang mit DNSSEC, IPv6 und UDP Paketgrößen aufgefallen. Wobei aufgefallen hier nicht ganz korrekt ist, ich bin durch http://dnsviz.net darauf gestoßen worden. Die Jungs kommen mir nämlich mit der folgenden Warnung entgegen:
domain.tld/A: No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (2001:210:5000:bbbb::aaaa:1, UDP_0_EDNS0_32768_4096)
Diese Meldung besagt das es vom jeweiligen DNS Server erst eine Antwort gegeben hat, nachdem die UDP Größe verringert wurde. Dieses fällt einem im normalen Tests mit dig / drill oder ähnlichem nicht wirklich auf. Denn hier wird absolut automatisch die Paketgröße weiter verringert bis es klappt. Es „dauert“ nur etwas länger….
Der DNS-Server, in diesem Fall ein bind9.11, versucht auf die Frage mit einem IPv6 UDP Paket zu Antworten und schickt dieses mit 4096 Byte raus. Aus irgendeinem Grund (Firewall, Einstellungen im OS, Filter auf dem Netzwerk….) wird dieses Paket auf seinem Weg aber verworfen und erreicht sein Ziel nicht. Da wir hier über UDP sprechen merkt das der Server nicht und glaubt er habe seinen Job gut gemacht. Woher soll bind auch wissen das sein Paket nicht angekommen ist oder irgendwas auf dem Weg sein Pakete mit dieser Größe nicht mag?
Um als Admins herauszufinden wie groß die Pakete von seinem System denn werden können kann man folgenden einfachen Test nutzen:
$ dig +short rs.dns-oarc.net txt rst.x490.rs.dns-oarc.net. rst.x499.x490.rs.dns-oarc.net. rst.x457.x499.x490.rs.dns-oarc.net. "2001:310:6000:f::1fc7:1 sent EDNS buffer size 512" "Tested at 2017-07-05 08:23:52 UTC" "2001:310:6000:f::1fc7:1 DNS reply size limit is at least 499"
Wie zu erkennen ist endet es auf diesem System bei 512 Byte. Wenn wir uns jetzt nicht weiter um den Grund kümmern wollen oder können, müssten wir also unserem bind sagen das er bitte immer nur mit maximal 512 Byte arbeitet, wenn er UDP nutzt. Dieses geht wie folgt im Options Block:
options {
[....]
edns-udp-size 512;
max-udp-size 512;
[....]
};
edns-upd-size ist hier für das Empfangen und max-udp-size für das Senden von Paketen. Ab dem Moment probiert es bind nur noch mit 512 Byte und die Clients werde auf ihre erste Frage hin direkt eine Antwort bekommen, ohne die Frage so oft wiederholen zu müssen, bis sie schrittweise zurück auf 512 Byte sind.
So long…
Ich brauche mal eure Hilfe…
Zum Spaß habe ich mir einen VPS Server in Japan geklickt. Was nun damit tun? Einfach mal ein weiteren DNS Server nutzen \o/ Gute Idee? Nein… Warum nicht? Weil der Server in Japan steht, höhere Antwortzeiten hat und der meist zufällig entscheidet, welcher DNS Server nun gefragt wird. Ich habe somit also sporadisch DEUTLICH langsamere DNS Antworten. Für meinen Spieltrieb aber gerade OK .-P
Ist also nun ein FreeBSD 10 mit einem Bind9.11 als slave für drei Spielzonen (kernel-error.org, kernel-error.com, kernel-error.de). FreeBSD ans Ende gepatcht, aktuellen Bind drauf, getestet ob die Kiste sauber signierte Zonen abfragen und prüfen kann (TCP/UDP und größer 512) alles gut. Dann als slave eingebunden wieder getestet und dann in die Zone darüber eintragen lassen. Die Zonen org. sowie com. haben den DNS-Server einfach gefressen. die Zone de. meckert aber! DNS timeout bei IPv6 O_o Öhm, ok… dig und drill sagen das geht aber. Bind ist auch fest ein und ausgehend an die IPv6 Adresse gebunden. Als „Firewall“ rennt PF, das mal deaktiviert ändert aber nichts. Vielleicht filter der Provider? Nope nur switch, iptables und ebtables öhm, das klingt sehr spartanisch.
Hat das Problem nur denic? Nö, DNSViz scheint es auch nicht zu können: http://dnsviz.net/d/kernel-error.com/dnssec/
Wie gesagt NUR bei IPv6! Jetzt habe ich mir alle Mühe gegeben diesen Timeout selbst mal zu produzieren, klappt aber nicht. Bei mir geht es einfach IMMER egal was für Optionen ich dig mitgebe.
# dig @2001:310:6000:f::1fc7:1 +edns +multi +norec +bufsize=4096 kernel-error.com IN MX +short 10 smtp.kernel-error.de. # dig @2001:310:6000:f::1fc7:1 +tcp +edns +multi +norec +bufsize=4096 kernel-error.com IN MX +short 10 smtp.kernel-error.de.
Ich verstehe das nicht! Ich mache am bind keine Unterscheidung zwischen IPv4 und IPv6, für mich geht alles. Alle Antworten und Fragen in alle Richtungen laufen ohne jedes Problem. Nur DNSViz und denic scheinen ein „Problem“ zu haben. Mal sehen ob jemand von der denic mit einen sinnvollen Tipp geben kann. Mir würde ja schon der dig Aufruf reichen der zu einem timeout führt :-/ Dann hätte ich etwas zum Testen.
Oh ja, ich habe natürlich auch ganz brav mal tcpdump laufen lassen. Leider sieht es hier ebenfalls einfach funktionstüchtig aus 🙁
https://www.kernel-error.de/download/dns.tar.gz
Hat von euch irgendjemand eine Idee?
*U-P-D-A-T-E*
Die interne Fehlermeldung der API DENIC:
ERROR: 223 Timeout after switching from UDP to TCP – switch to TCP due to timeout (target) (ns3.kernel-error.com./2001:310:6000:f:0:0:1fc7:1:53)
*U-P-D-A-T-E*
Mal querry log eingeschaltet:
30-Jan-2017 18:30:04.669 client @0x802e62600 2a02:568:201:214::1:15#38145 (ns3.kernel-error.com): query: ns3.kernel-error.com IN A -E(0)DC (2001:310:6000:f::1fc7:1) 30-Jan-2017 18:30:04.670 client @0x802e62600 2a02:568:201:214::1:15#41589 (ns3.kernel-error.com): query: ns3.kernel-error.com IN AAAA -E(0)DC (2001:310:6000:f::1fc7:1) 30-Jan-2017 18:30:04.938 client @0x802e62600 2a02:568:201:214::1:15#20703 (kernel-error.de): query: kernel-error.de IN SOA - (2001:310:6000:f::1fc7:1) 30-Jan-2017 18:30:05.510 client @0x802e6f800 2a02:568:201:214::1:15#58465 (kernel-error.de): query: kernel-error.de IN NS -T (2001:310:6000:f::1fc7:1) 30-Jan-2017 18:30:05.889 client @0x802e62600 2a02:568:201:214::1:15#47548 (kernel-error.de): query: kernel-error.de IN SOA -E(0)D (2001:310:6000:f::1fc7:1) 30-Jan-2017 18:30:05.896 client @0x802e62600 2a02:568:201:214::1:15#55493 (kernel-error.de): query: kernel-error.de IN DNSKEY -E(0)D (2001:310:6000:f::1fc7:1) 30-Jan-2017 18:30:06.416 client @0x802e70c00 2a02:568:201:214::1:15#37170 (kernel-error.de): query: kernel-error.de IN DNSKEY -E(0)TD (2001:310:6000:f::1fc7:1)
*U-P-D-A-T-E*
Ich glaube es nicht… Ich teste hier gerade rum, will einem Kollegen zeigen das es nicht geht und das Update läuft bei DENIC einfach durch und OK Ö_ö ich verstehe das nicht, wirklich nicht. Absolut 0,0 warum geht das jetzt und warum meint DNSViz das es dennoch nicht geht? Was passiert hier?
*U-P-D-A-T-E*
Bleibt nur noch meine Vermutung, dass es wirklich um die Antwortzeit des Servers geht… Die liegt so zwischen 200 und 300ms. Das ist echt lange aber auch nicht SOOOOOOO lange :-/ Mal sehen ob von denic irgendwas kommt?!?!
*U-P-D-A-T-E*
Da fliegt mir doch gerade folgende Info rein:
die DENIC meinte dazu:
unsere Kollegen können derzeit nicht genau sagen woran es hängt. Jedoch sind unsere Verbindungen nach Korea zeitweise leicht beeinträchtigt, evtl. wurde dir Nast Prüfung genau in dem Moment durchgeführt.
Es scheint als bekommen wir das nicht geklärt. Aber schön, wenn das
Update nun durch ist.
PS: Ein leicht ungutes Gefühl bleibt ...
Man man man… Was ist denn da passiert? Seit 3 oder 4 Tagen scheint das Thema im Internet irgendwie besonders aktiv zu sein, oder? Nur warum?!?!
Plötzlich bekomme ich nicht nur jeden Tag einen Haufen Anfragen zu dem Thema, viel scheinen auch irgendwas testen zu wollen und pumpen E-Mails mit Random-Empfängern an meine Domains….
Im Grunde habe ich ja nichts gegen Tests. Nur grob abgesprochen wäre schon schön, mein Monitoring wird sonst immer so „wuschig“! 😀
Um noch mal ein paar Themen zusammen zu fassen:
1. Basis von allem ist DNSsec
2. TLSA Records „ist DANE“
3. Postfix kann TLSA Records auswerden, ohne selbst welche für sein System zu haben.
DNSSEC und DNS-based Authentication of Named Entities (DANE)
Postfix SSL/TLS gesichert mit TLSA / DANE und DNSSEC
TLSA / DANE RECORD von Hand manuel prüfen.
So long…
Ich habe nach längerem dann mal meinen KSK für´s dnssec getauscht. Bzw. ich bin gerade dabei 🙂
Der alte war noch ein 1024bit NSEC3RSASHA1. Jetzt ist auch klar warum er getauscht werden musste 😛 Der neue ist nun ein NSEC3RSASHA1 mit 4096bit. Als zweiten neuen Key habe ich einen RSASHA512 mit ebenfalls 4096bit erstellt. So habe ich für den Fall der Fälle auch direkt einen ohne SHA1 im „Anschlag“.
Dieser neue Key ersetzt in Kürze den alten 1024bit KSK Schlüssel. Bereits jetzt sollte es aber für jeden nur noch über den 4096bit NSEC3RSASHA1 Schlüssel laufen.
Inzwischen sollte wohl jede halbwegs aktuelle Software mit dnssec Support mit diesen Schlüsseln umgehen können. Wenn nicht, wird es Zeit für ein Update 😀
In diesem Sinne!
* U-P-D-A-T-E *
Inzwischen ist auch der andere Schlüssel oben und sollte sich so langsam durch die Welt sprechen….
http://dnsviz.net/d/kernel-error.de/dnssec/
In der letzten Zeit häufen sich bei mir die Anfragen, mit welchem Registart ist zusammenarbeite. Vor allem im Hinblick auf DNSSEC und dem KSK oder besser der DS-RECORDS.
Hier kann und möchte ich gerne die SpeedPartner GmbH aus Neuss empfehlen. Hier arbeite ich gerne mit dem Herrn Metz zusammen. Es ist immer jemand erreichbar, vor allem lassen sich schnell und einfach auch etwas ungewöhnliche Dinge umsetzten. Zwar ist das Webinterface (stand 06.2014) noch nicht so weit das man darüber DS-RECORDS einwerfen kann, der Weg per E-Mail funktioniert aber in der Regel binnen Minuten / Stunden.
Es kommt ja eher selten bis nie vor, das ich hier Werbung für ein Unternehmen mache, dieses hat es aber verdient.
So long…
Webseite: http://www.speedpartner.de/
E-Mail Adresse: info@speedpartner.de
Na schau mal einer an… Das Browser Plugin für den DNSSEC Validator kann nun auch DANE / TLSA und er zeigt es angenehm übersichtlich an.
https://www.dnssec-validator.cz/pages/download.html
Ist in jedem Fall noch mal einen Klick wert 🙂
Mein Domains sind nun schon seit langem per DNSSEC gesichert. Schnell habe ich auch TLSA-RECORDS für mein SSL/TLS X.509 Zertifikat des Webservers Apache veröffentlicht, damit die verschlüsselte Verbindung zu meiner Webseite ebenfalls per DANE gesichert ist.
DNSSEC: https://www.kernel-error.de/dnssec
DANE: https://www.kernel-error.de/dnssec/tls-ssl-zertifikatschecksummen-im-dns
Seit Januar diesen Jahres beherscht nun Postfix ebenfalls die Möglichkeit TLSA Records zu prüfen. Da mache ich natürlich mit!
Zuerst muss die Postfix Version natürlich passen. Kleiner 2.11 sollte es nicht sein, die Postfixversion zeigt sich schnell per:
$ postconf -d | grep mail_version mail_version = 2.11.0
Mein Mailserver bietet natürlich schon immer die Möglichkeit einer verschlüsselten Verbindung an. Daher gehe ich einfach mal nicht näher darauf ein, wie man sein Postfix dazu überredet. Ganz kurz… Aktivieren lässt sich die Unterstützung für DANE / TLSA mit folgenden drei Konfigurationsänderungen:
$ postconf -e "smtpd_use_tls = yes" $ postconf -e "smtp_dns_support_level = dnssec" $ postconf -e "smtp_tls_security_level = dane"
Keine Sorge, alles bietet einen Failback an, so leidet die Kommunikation mit _nicht_ DANE fähigen Systemen nicht.
Zum erstellen des TLSA-RECORDS muss selbstverständlich nicht unbedingt der von mir in früheren Beiträgen erwähnte Hash-slinger eingesetzt werden. Openssl macht dieses fast genau so schnell.
$ openssl x509 -in postfix.pem -outform DER | openssl sha256 (stdin)= 94c8e1bdfff4f6d3fec0c4e2f26293d78870650bfd3534e77b93cdaccb77eb95
Aus diesem Hash erstelle ich nun den TLSA RECORD. Für die E-Mail Kommunikation ist es mir lieb, wenn der TTL (Lebensdauer) des Records nicht ZU lange ist. Bei einem Zertifikatswechsel dauert es sonst unnötig lange bis der neue Record gültig ist. Daher setzte ich ihn auf 1 Stunde.
_25._tcp.smtp.kernel-error.de. 1H IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1 _465._tcp.smtp.kernel-error.de. 1H IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
Wie zu sehen ist biete ich den TLSA RECORD direkt für Port TCP 25 und TCP 465 an. Schnell nur noch testen ob der TLSA RECORD mit dig auch sauber abgefragt werden kann.
$ dig _25._tcp.smtp.kernel-error.de +dnssec +m
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> _25._tcp.smtp.kernel-error.de +dnssec +m
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_25._tcp.smtp.kernel-error.de. IN A
;; AUTHORITY SECTION:
kernel-error.de. 86400 IN SOA ns1.kernel-error.de. root.kernel-error.de. (
20140102708 ; serial
10000 ; refresh (2 hours 46 minutes 40 seconds)
1800 ; retry (30 minutes)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
kernel-error.de. 86400 IN RRSIG SOA 7 2 86400 20150511054702 (
20140516054702 38150 kernel-error.de.
QXUpVl3myVAUGn/ox8J5aihAySHdWpojyPuhV5QKgDUy
qYRPyryWyBoGG+x5cGs0JpPBqQA3lRovAM4JFvC3hRmO
FU3fVTiYlvAJK7WsTSgPJLYpXrBnS+NN0O2UW3W+Ru1K
2P5dj+BWNO1wqXs+VU7WpMPwq/ESlK88hxXE1Gc= )
_25._tcp.smtp.kernel-error.de. 86400 IN NSEC _465._tcp.smtp.kernel-error.de. RRSIG NSEC TLSA
_25._tcp.smtp.kernel-error.de. 86400 IN RRSIG NSEC 7 5 86400 20150511054702 (
20140516054702 38150 kernel-error.de.
ToC8GtXFenieGjA32eoHACNGCg+tFr05vz6w9yiHYrDj
rHGBabc7MMjqUWNsf7L059YhR7dLoAPqhy2ZThWqFbRD
ZsfPQSgHIazEuKvOE7i2Ee/znU2d57X8nVkp8scUKZ1R
kGdK5DUDlAcYn0YdpjYaUTn2STdbM9IDcdrASPE= )
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mo Jan 27 08:50:36 2014
;; MSG SIZE rcvd: 506
Schon lässt sich im Postfix Logfile erkennen ob Verbindungen getraut wird oder nicht.
Jan 27 08:32:02 mailserver postfix/smtp[3779]: Verified TLS connection established to mx02.example.de[99.88.12.167]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Jan 27 08:33:19 mailserver postfix/smtp[3779]: Untrusted TLS connection established to smtp2.example.de[2001:333:6661:99::34]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
Wenn man mich fragt, ist die Kombination aus DNSSEC, DANE / TLSA deutlich besser als dieses hässliche EmiG. EmiG benötigt eine unnötig teure Zertifizierung durch den TüV, dieses kann sich nicht jeder leisten. Damit ist dieses „sichere“ Verfahren fast nur durch Unternehmen zu realisieren die genug Kohle haben. Kleinere werden damit einfach abgehängt. Verfahren die Sicherheit nur für „reiche“ zur Verfüfung stellen sollte man aus meiner Überzeugnung nicht unterstützen.
Eine weitere schnelle und einfache Möglichkeit seinen TLSA-RECORD des Mailservers / Postfix zu testen ist posttls-finger:
$ posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de posttls-finger: initializing the client-side TLS engine posttls-finger: using DANE RR: _25._tcp.smtp.kernel-error.de IN TLSA 1 0 1 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95 posttls-finger: setting up TLS connection to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25 posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL" posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 verify=1 subject=/description=y0xkuso3gx7t8h0o/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=smtp.kernel-error.de/emailAddress=postmaster@kernel-error.de posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 matched end entity certificate sha256 digest 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95 posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: subject_CN=smtp.kernel-error.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=E1:92:93:D4:CA:E9:5D:44:B5:CC:A4:15:1F:12:A6:E0:B5:C2:97:56, pkey_fingerprint=E9:84:8E:51:47:99:90:53:0B:2C:2E:1E:70:6E:DE:CA:A4:65:8A:C5 posttls-finger: Verified TLS connection established to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
So bei Fragen, einfach fragen 🙂
09-08-2014 Update
Ich habe zur Auswertung den Mailgraph etwas angepasst ( mailgraph Graphen um DANE erweitern ). Dieser wirft mir nun den unten stehenden Graphen für ausgehende Verbindungen raus.
Schon einige Zeit ist meine Domain per DNSSEC geschützt und der Zugriff ist ebenfalls per SSL/TLS möglich. Mit DANE (DNS-based Authentication of Named Entities) ist es jetzt möglich die eingesetzten X.509 Zertifikate bzw. deren Checksummen mit dem DNS „abzugleichen“.
Die Idee dahinter ist, das löchrige System der CAs (certificate authority oder certification authority) etwas sicherer zu machen / zu ersetzten.
Unterstützt ein Client, wie zum Beispiel ein Browser, DANE so kann er beim verschlüsselten Verbindungsaufbau mit einem Server (z.B.: Webserver). Prüfen ob die Checksumme des TLS Zertifikates mit der in der DNS Zone hinterlegten übereinstimmt. So kann man diesem Zertifikat „trauen“, selbst wenn es sich um ein selbst signiertes Zertifikat handelt oder das Root-Zertifikat der CA nicht in seinem Client enthalten ist.
Selbstverständlich wird damit nicht sichergestellt das die angegebene Person oder Organisation wirklich hinter dem Zertifikat steht. Hier hängt es dann wieder an der CA, der muss man zum einen selbst vertrauen und zum anderen sollte sie dafür sorgen dass niemand an ihre Zertifikate kommt. Nichts ist 100%tig sicher! Man kann nur versuchen dem absoluten Vertrauen so nahe wie möglich zu kommen. Daher ist es sehr angenehem wenn verschiedene Mechanismen ineinandergreifen und sich nach Möglichkeit auch gegenseitig prüfen.
Dabei sollte der Benutzer aber mit so wenig technischen Dingen gequält werden wie nur möglich. DNSSEC, DANE und TLS ist aus meiner Sicht im Moment eine recht gute Kombination. Wenn alles sauber im Client implementiert ist und die Admins ihre Arbeit gemacht haben, bekommt der Benutzer nur die Information: „Was du da gerade machst ist möglicherweise nicht der Server mit dem du sprechen wolltest. Lass es lieber!“
Klar steht und fällt am Ende alles mit dem Benutzer. Hier müssen die Benutzer geschult und aufgeklährt werden. Den technischen Hintergrund muss aber kein Anwender verstehen.
Ich stehe ja auf so etwas. Daher habe ich es direkt bei mir implementiert.
Bind kann ab der Version 9.8.3 mit TLSA RECORDS umgehen:
#### SCHNIPP ####
Feature Changes
* BIND now recognizes the TLSA resource record type, created to
support IETF DANE (DNS-based Authentication of Named Entities)
[RT #28989]
#### SCHNAPP ####
Damit es einfacher wird bietet die Internet Society (http://www.internetsociety.org/deploy360/resources/hashslinger-a-tool-for-creating-tlsa-records-for-dane/) ein Tool mit dem Namen Hash-slinger an. Dieses Tool unterstützt beim erstellen der TLSA-RECORDS und natürlich bei der Prüfung der DNS-RECORDS.
Für meine Hauptdomain findet sich folgender RECORD in der Zone:
_443._tcp.www.kernel-error.de. IN TLSA 3 0 1 a3218154fbaa792afba91075ea36b5ea6623d46766a10ff1d06e7de461f933f7
Geprüft wird dieser korrekt wie folgt, einmal für die IPv4 und einmal für die IPv6 Adresse:
$ ./tlsa -d -v www.kernel-error.de Received the following record for name _443._tcp.www.kernel-error.de.: Usage: 3 (End-Entity) Selector: 0 (Certificate) Matching Type: 1 (SHA-256) Certificate for Association: a3218154fbaa792afba91075ea36b5ea6623d46766a10ff1d06e7de461f933f7 This record is valid (well-formed). Attempting to verify the record with the TLS service... Got the following IP: 212.23.142.146 SUCCESS (usage 3): The certificate offered by the server matches the TLSA record The matched certificate has Subject: /description=3G0bqBiLJsg0y2nv/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=www.kernel-error.de/emailAddress=postmaster@kernel-error.de Got the following IP: 2001:7d8:8001:100::dead:beef SUCCESS (usage 3): The certificate offered by the server matches the TLSA record The matched certificate has Subject: /description=3G0bqBiLJsg0y2nv/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=www.kernel-error.de/emailAddress=postmaster@kernel-error.de
Die gängigen Browser lassen sich bereits mit Plugins nachrüsten.
Spannende Infos zum Thema DANE gibt es hier:
http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec
Wer nur schnell und einfach die TLSA Records testen möchte, kann dieses hier tun: http://check.sidnlabs.nl/dane/
U-P-D-A-T-E 28.01.2014
Wie sich das Thema zusammen mit Postfix nutzen lässt um auch etwas gegen dieses hässliche EmiG (E-Mail made in Germany) zu tun ist hier zu finden: https://www.kernel-error.de/kernel-error-blog/260-postfix-ssl-tls-gesichert-mit-tlsa-dane-und-dnssec
U-P-D-A-T-E 09.08.2014
Ich habe den Mailgraph erweitert ( mailgraph Graphen um DANE erweitern ), damit er mir den unten stehenden Graphen erzeugt.
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?
