DNSSEC

Motivation

DNSSEC zielt darauf ab, Sicherheitslücken im Internet wie Cache-Poisoning und DNS-Spoofing zu schließen.

Um für die Validierung bei DNSSEC eine Vertrauenskette (chain of trust) aufbauen zu können, sieht das DNSSEC-Protokoll vor, in der delegierenden Zone einen Hinweis auf den oder die Schlüssel der delegierten Zone zu hinterlegen. Die Vertrauenskette folgt damit dem Delegationspfad. Der entscheidende Schlüssel ist der Key Signing Key der delegierten Zone, der in der Regel als Secure Entry Point (SEP) markiert ist. Diese Information liegt in einem DNSKEY-RR in der delegierten Zone vor und ist dort (mindestens) von diesem Dnskey selbst unterschrieben. In der delegierenden Zone wird diese Information aus Platzgründen nicht exakt wiederholt. Statt des eigentlichen Schlüssels wird dort ein entsprechender Fingerprint in einem DS-RR (Delegation Signer) abgelegt.

Im Rahmen der Zonengenerierung werden die entsprechenden DS-Records erzeugt (derzeit genau ein DS-RR pro mitgeteilten Trust Anchor), signiert und mit der Zone verteilt.

Dnskey

DNSKEY Resource Records dienen der Propagierung öffentlicher Schlüssel durch das DNS und sind ein technisches Attribut einer Domain (vergleichbar mit Nameserver-Einträge oder NS-Entries).

Aufbau des Dnskeys im bei K/V- und XML-Aufträgen

Folgende vier Angaben werden als Wert von „Dnskey:“ (siehe Präsentationsformat in RFC 4034) benötigt:

  • Flags: 256 oder 257,
  • Protokoll, zurzeit immer 3,
  • Numerische Kodierung des genutzten Algorithmus,

    • Im Feld "Algorithm" dürfen nur Werte vorkommen, die in der IANA-Registry enthalten, als nutzbar markiert und nicht für private Zwecke reserviert sind. Als kryptographische Algorithmen sind dabei nur RSA, DSA, ECDSA und GOST mit verschiedenen Hash-Verfahren definiert:

    • 3(DSA/SHA1)
      5(RSA/SHA-1)
      6(DSA-NSEC3-SHA1)
      7(RSASHA1-NSEC3-SHA1)
      8(RSA/SHA-256)
      10(RSA/SHA-512)
      12(GOST)
      13ECDSAP256SHA256)
      14(ECDSAP384SHA384)
    • Public-Key, base64-kodiert.
    • Der Wert des Schlüsselwortes „Dnskey“ muss in einer Zeile angeben werden und darf nicht durch Umbrüche getrennt werden.

Domain CREATE-Auftrags-Beispiel mit Angabe eines Dnskeys im K/V-Format

Action:     create
Version:    3.0
CtId:       cba-987654321
Domain:     beispiel-fünf.de
Domain-ace: xn--beispiel-fnf-mlb.de
Holder:     DENIC-99990-BSP
Nserver:    ns1.provider.de
Nserver:    ns2.xn--tste-loa.de 192.0.2.1
Dnskey:     257 3 5 AwEAAdDECajHaTjfSoNTY58WcBah1BxPKVIHBz4IfLjfqMvium4lgKtKZLe97DgJ5/NQrNEGGQ r6fKvUj67cfrZUojZ2cGRizVhgkOqZ9scaTVXNuXLM5Tw7VWOVIceeXAuuH2mPIiEV6MhJYUsW6dvmNsJ4XwCgNgroAmXhoMEoWEj BB+wjYZQ5GtZHBFKVXACSWTiCtddHcueOeSVPi5WH94VlubhHfiytNPZLrObhUCHT6k0tNE6phLoHnXWU+6vpsYpz6GhMw/R9BFxW5PdPFIWBgoWk2/XFVRSKG9Lr61b2z1R126xeUwvw46RVy3hanV3vNO7LM5HniqaYclBbhk=

Domain CREATE-Auftrags-Beispiel mit Angabe eines Dnskeys im XML-Format

<?xml version='1.0' encoding='UTF-8'?>

<registry-request xmlns='http://registry.denic.de/global/3.0' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:domain='http://registry.denic.de/domain/3.0' xmlns:dnsentry='http://registry.denic.de/dnsentry/3.0'>
 <domain:create>
  <domain:handle>beispiel-fünf.de</domain:handle>
  <domain:ace> xn--beispiel-fnf-mlb.de</domain:ace>
  <domain:contact role='holder'>DENIC-99990-BSP</domain:contact>
  <dnsentry:dnsentry xsi:type="dnsentry:NS">
   <dnsentry:owner>xn--beispiel-fnf-mlb.de</dnsentry:owner>
   <dnsentry:rdata>
    <dnsentry:nameserver>ns1.provider.de</dnsentry:nameserver>
   </dnsentry:rdata>
  </dnsentry:dnsentry>
  <dnsentry:dnsentry xsi:type="dnsentry:NS">
   <dnsentry:owner>xn--beispiel-fnf-mlb.de</dnsentry:owner>
   <dnsentry:rdata>
    <dnsentry:nameserver>ns1.marco-testdns1.de</dnsentry:nameserver>
    <dnsentry:address>192.0.2.1</dnsentry:address>
   </dnsentry:rdata>
  </dnsentry:dnsentry>
  <dnsentry:dnsentry xsi:type="dnsentry:DNSKEY">
   <dnsentry:owner>denic-itstt-11864785.de.</dnsentry:owner>
   <dnsentry:rdata>
    <dnsentry:flags>257</dnsentry:flags>
    <dnsentry:protocol>3</dnsentry:protocol>
    <dnsentry:algorithm>5</dnsentry:algorithm>
    <dnsentry:publicKey>AwEAAdDECajHaTjfSoNTY58WcBah1BxPKVIHBz4IfLjfqMvium4lgKtKZLe97DgJ5/NQrNEGGQmr6fKvUj67cfrZ UojZ2cGRizVhgkOqZ9scaTVXNuXLM5Tw7VWOVIceeXAuuH2mPIiEV6MhJYUsW6dvmNsJ4XwCgNgroAmXhoMEiWEjBB+wjYZQ5GtZHBFKVXACSWTiCtddHcueOeSVPi5WH94VlubhHfiytNPZLrObhUCHT6k0tNE6phLoHnXWU+6vpsYpz6GhMw/R9BFxW5PdPFIWBgoWk2/XFVRSKG9Lr61b2z1R126xeUwvw46RVy3h anV3vNO7LM5H niqaYclBbhk=</dnsentry:publicKey>
   </dnsentry:rdata>
  </dnsentry:dnsentry>
 </domain:create>
</registry-request>

Besonderheiten

  • CREATE Wenn die Registrierung einer Domain erfolgreich ist, aber die Konnektierung fehlschlägt (die Domain also im Status „failed“ registriert wird), so werden die aus den Dnskey-Einträgen berechneten DS-Records bei der Zonengenerierung nicht berücksichtigt.
  • UPDATE / CHHOLDER Wenn für eine Domain keine Dnskey-Einträge vorhanden sind, so können diese über ein UPDATE bzw. CHHOLDER eingetragen werden.

    Wenn für eine Domain bereits ein oder mehrere Dnskey- Einträge vorhanden ist/sind und bei einem Domain-UPDATE- bzw. Domain-CHHOLDER-Auftrag das Schlüsselwort „Dnskey:“ nicht vorhanden oder leer ist, so wird der Auftrag ausgeführt und der ursprüngliche Wert von „Dnskey:“ gelöscht.
  • CHPROV, Siehe Dokumentation "Operatorwechsel"
  • TRANSIT Bei TRANSIT-Aufträgen werden eventuelle Dnskey-Einträge (unabhängig davon ob der Wert von „Disconnect:“ „true“ oder „false“ ist) gelöscht.
  • DELETE Bei DELETE-Aufträgen werden auch die aus den Dnskey-Einträgen erzeugten DS-Records aus der .de-Zone entfernt.

Nameserver Predelegation Check

Informationen dazu unter DENIC-23p und https://nast.denic.de.