CAA, SRV, TLSA & SVCB
Vier Themen, fünf Record-Typen: CAA, SRV, TLSA sowie SVCB und HTTPS — zwei eigene Typen, die hier zusammen stehen, weil sie dasselbe Format haben. Samt der Antwort auf die Frage, was es bedeutet, wenn nichts gefunden wird.
Eine nackte Domain genügt: Die Namen für SRV und TLSA (_dienst._protokoll.domain) baut das Werkzeug selbst zusammen und fragt die verbreiteten Dienste sowie die Mailserver der Domain ab. Einen vollständigen Unterstrich-Namen kannst du aber auch direkt eingeben.
CAA — wer darf Zertifikate ausstellen?
Ein CAA-Eintrag sagt jeder Zertifizierungsstelle, ob sie für diese Domain ausstellen darf. Fehlt er, darf jede. Die Regel wird nach unten vererbt: Was an der Domain steht, gilt auch für ihre Unternamen — es sei denn, dort steht ein eigener CAA-Satz, der den oberen dann vollständig ersetzt. CAA verhindert keine Übernahme deiner Domain; es verkleinert aber den Kreis der Stellen, bei denen so ein Versuch überhaupt Erfolg haben könnte.
SRV — wo liegt der Dienst?
SRV-Einträge sagen einem Programm, auf welchem Rechner und welchem Port ein Dienst liegt — Autodiscover, SIP, XMPP, Matrix, Minecraft. Damit richtet sich ein Mailprogramm selbst ein oder ein Spiel findet den Server hinter einer schöneren Adresse. Sie stehen nie an der Domain selbst, sondern immer unter _dienst._protokoll.domain — und genau daran scheitern die meisten Versuche.
TLSA — welches Zertifikat gehört dazu? (DANE)
Ein TLSA-Eintrag hinterlegt im DNS, woran das Zertifikat eines Dienstes zu erkennen ist. Was genau er beschreibt, sagen drei Zahlen: Nutzung (Endzertifikat oder ausstellende Stelle, mit oder ohne die üblichen Wurzelzertifikate), Auswahl (das ganze Zertifikat oder nur sein öffentlicher Schlüssel) und Abgleich (vollständig oder als Fingerabdruck). Gebräuchlich ist das vor allem bei Mailservern: Von einem Mailserver zum nächsten wird normalerweise opportunistisch verschlüsselt — verschlüsselt zwar, aber ohne dass das Zertifikat wirklich geprüft würde. DANE ändert das. Denselben Zweck erfüllt MTA-STS, nur über die gewohnten Zertifikate und eine Datei auf einem Webserver statt über das DNS. Sinnvoll ist das nur zusammen mit DNSSEC: Ohne Signatur kann jeder, der die Verbindung umlenkt, den Eintrag genauso gut aus der Antwort entfernen. Geprüft werden die Mailserver der Domain (Port 25) und ihr Webserver (Port 443).
SVCB und HTTPS — wie ein Browser verbindet
Der HTTPS-Record ist der neueste der vier. Ein Browser erfährt daraus schon vor dem ersten Paket, wie er am besten verbindet: welche Protokolle gehen (HTTP/3), welche Adressen gelten und ob der Name der Website verschlüsselt übertragen werden kann (ECH). Ohne ihn braucht er dafür den Umweg über die erste Verbindung.
Selbst nachprüfen
Dieselben Abfragen im Terminal — mit genau den Namen, die gefragt wurden.
Wer darf hier Zertifikate ausstellen?
dig +short CAA example.comWo liegt dieser Dienst?
dig +short SRV _autodiscover._tcp.example.comWelches Zertifikat gehört zu diesem Mailserver?
dig +short TLSA _25._tcp.mail.example.comWie erreicht ein Browser diesen Namen am schnellsten?
dig +short HTTPS example.comÄltere dig-Fassungen (etwa die auf macOS mitgelieferte) kennen die Namen HTTPS und SVCB noch nicht. Dort stattdessen die Typnummer angeben: dig -t TYPE65 example.com für HTTPS, TYPE64 für SVCB, TYPE52 für TLSA.