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 KSK der Root-Zone als Trust Anchor.
• Dieser 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:
  • KSK (Key Signing Key) signiert nur den DNSKEY-Record.
  • ZSK (Zone Signing Key) signiert alle anderen Records (z. B. den DS-Record für .com).

• Der Resolver überprüft den ZSK der Root-Zone mit dem KSK der Root-Zone.
  • Der KSK signiert den DNSKEY-Record, der den ZSK enthält.
  • Der Resolver prüft, ob die Signatur des KSK korrekt ist.
  • Wenn ja, kann er nun dem ZSK der Root-Zone vertrauen.

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.