Vetrauenskette bei DNSSEC

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen

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.
Abgerufen von „http://wiki.ixheim.de/index.php?title=Vetrauenskette_bei_DNSSEC&oldid=60328“