Vetrauenskette bei DNSSEC

Ablauf in DNSSEC

• Der Nameserver signiert den A-Record:
  • Der ZSK (Zone Signing Key) des authoritativen Nameservers für die Domain erstellt einen Hash des A-Records (z. B. hund.example.com IN A 192.168.1.1).
  • Dieser Hash wird mit dem privaten ZSK signiert.
  • Das Ergebnis dieser Signierung ist der RRSIG-Record (die Signatur), die den Hash enthält.
  • Der Nameserver schickt dann den A-Record zusammen mit der RRSIG-Signatur an den Resolver.

• Der Resolver überprüft die Signatur:
  • Der Resolver erhält den A-Record und die dazugehörige RRSIG-Signatur.
  • Der Resolver berechnet selbst den Hash des A-Records (mit demselben Hash-Algorithmus wie der Nameserver).
  • Der Resolver zieht den DNSKEY-Record (der den öffentlichen ZSK enthält) und verwendet den öffentlichen ZSK, um die RRSIG-Signatur zu entschlüsseln.
  • Der Resolver vergleicht den entschlüsselten Wert der Signatur mit dem von ihm selbst berechneten Hash des A-Records.
  • Wenn beide Werte übereinstimmen, bedeutet dies, dass der A-Record authentisch ist und nicht manipuliert wurde.

Wie kann der Resolver dem autoritativen Nameserver vertrauen?

Startpunkt der Vertrauenskette

• Der Resolver kennt den Root-KSK als Trust Anchor.
• Dieser Root-KSK ist fest in den Resolvern hinterlegt (z. B. in bind, unbound).
• Er ist der Startpunkt der Vertrauenskette (Chain of Trust).

Validierung der Root-Zone

Die Root-Zone veröffentlicht einen DNSKEY-Record mit zwei Schlüsseln und den RRSIG

• Der Root-KSK (Key Signing Key der Root-Zone) signiert nur den DNSKEY-Record der Root-Zone.
• Der Root-ZSK (Zone Signing Key der Root-Zone) signiert alle anderen Records in der Root-Zone (z. B. den DS-Record für .com).
• Der Root-KSK signiert den gesamten DNSKEY-Record, der sowohl den Root-KSK als auch den Root-ZSK enthält.
• Diese Signatur heißt RRSIG für den DNSKEY-Record der Root-Zone.
• Der RRSIG für den DNSKEY-Record der Root-Zone und der DNSKEY-Record der Root-Zone werden in der Root-Zone veröffentlicht.

Der Resolver zieht sich den RRSIG- und DNSKEY-Record

• Der Resolver überprüft den Root-ZSK mit dem Root-KSK.
• Der Resolver berechnet einen Hash des DNSKEY-Records der Root-Zone und vergleicht ihn mit der Signatur aus dem RRSIG für den DNSKEY-Record der Root-Zone.
• Die Signatur des DNSKEY-Records der Root-Zone wird mit dem öffentlichen Root-KSK überprüft.
• Wenn die Signatur gültig ist, ist der DNSKEY-Record der Root-Zone authentisch.
• Der Resolver vertraut nun dem Root-ZSK.

Validierung der TLD (.com)

Die Root-Zone veröffentlicht den DS-Record für .com

• Die Root-Zone enthält einen DS-Record für .com.
• Der DS-Record enthält den Hash des KSK von .com.
• Der Root-ZSK signiert diesen DS-Record und erzeugt den zugehörigen RRSIG-Record für den DS-Record.
• Der RRSIG-Record enthält die Signatur des DS-Records, die mit dem Root-ZSK erstellt wurde.
• DS-Record und der dazugehörige RRSIG-Record für den DS-Record von .com werden in der Root-Zone veröffentlicht.

Der Resolver zieht sich den RRSIG- und DS-Record

• Der Resolver überprüft den DS-Record von .com mit dem Root-ZSK.
• Der Resolver berechnet einen Hash des DS-Records und vergleicht ihn mit der Signatur aus dem RRSIG-Record.
• Die Signatur des DS-Records wird mit dem öffentlichen Root-ZSK überprüft.
• Wenn die Signatur gültig ist, ist der DS-Record authentisch.
• Der Resolver vertraut nun dem KSK von .com.

Validierung der TLD (.com)

• Die Root-Zone enthält einen DS-Record für .com.
• Der DS-Record enthält den Hash des KSK von .com.
• Der ZSK der Root-Zone signiert diesen DS-Record.
• Da der Resolver dem ZSK der Root-Zone vertraut, kann er nun auch prüfen, ob der DS-Record für .com korrekt signiert wurde.
• Falls ja, gilt der DS-Record als authentisch und nicht manipuliert.

Validierung der Second-Level-Domain (example.com)

• Der Resolver nutzt nun den DS-Record, um den KSK von .com zu validieren.
• Er ruft den DNSKEY-Record von .com ab und berechnet den Hash des KSK.
• Wenn dieser Hash mit dem DS-Record aus der Root-Zone übereinstimmt, ist der KSK von .com authentisch.
• Der Resolver prüft nun den ZSK von .com, der im DNSKEY-Record von .com enthalten ist.
• Der KSK von .com signiert den DNSKEY-Record, um den ZSK abzusichern.
• Wenn die Signatur korrekt ist, vertraut der Resolver nun auch dem ZSK von .com.

Vertrauen zur Second-Level-Domain

• Der Resolver kann jetzt alle mit dem ZSK von .com signierten Records validieren.
• Dazu gehört auch der DS-Record für example.com, der in .com gespeichert ist.
• Dieser DS-Record verweist auf den KSK von example.com.
• Der Resolver ruft den DNSKEY-Record von example.com ab und vergleicht den KSK-Hash mit dem DS-Record aus .com.
• Wenn sie übereinstimmen, ist der KSK von example.com vertrauenswürdig.
• Der KSK von example.com signiert den DNSKEY-Record, um den ZSK abzusichern.
• Der Resolver prüft, ob diese Signatur gültig ist.
• Wenn ja, kann er nun dem ZSK von example.com vertrauen.

Abschluss der Vertrauenskette

• Der Resolver kann jetzt alle mit dem ZSK von example.com signierten Records validieren.
• Dazu gehören A-Records, MX-Records, TXT-Records usw.
• Wenn die Signaturprüfung erfolgreich ist, gelten diese Records als authentisch und nicht manipuliert.