DNSSEC

Motivation

DNSSEC aims at closing security holes in the Internet such as cache poisoning and DNS spoofing.

For validating DNSSEC a chain of trust must be established. To meet this requirement, the DNSSEC protocol requires that a reference to the key(s) of the delegated zone is entered into the delegating zone. Thus, the chain of trust follows the delegation path. The relevant key is the Key Signing Key of the delegated zone, which is usually flagged as Secure Entry Point (SEP). This information is available in a DNSKEY-RR in the delegated zone and is signed there (at least) by this very DNSKEY. It is not repeated in exactly the same way in the delegating zone for reasons of space. Instead of the actual key, a corresponding fingerprint is stored there in a DS-RR (Delegation Signer).

The corresponding DS records are generated together with the zone (currently precisely one DS-RR per communicated Trust Anchor), signed and distributed with the zone.

Dnskey

DNSKEY Resource Records serve for propagating public keys throughout the DNS and represent a new technical attribute of a domain (comparable to “Nserver” or “Nsentry” attributes).

Structure of the DNSkeys in K/V and XML requests

The following four fields are required as values of the keyword "Dnskey:" (cf. presentation format in RFC 4034):

  • Flags: 256 or 257,
  • Protocol: currently always 3,
  • Numerical encoding of the used algorithm:
    • The values in the “Algorithm” field must be taken from the IANA-Registry, marked as usable and not reserved for private purposes. Only RSA, DSA, ECDSA and GOST with different hash procedures are defined as cryptographic algorithms:
      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.

The value of the “Dnskey” keyword must be entered on one line and must not be separated by line breaks.

 

Domain CREATE request example with specification of a Dnskey in 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 order example with specification of a DNS key in 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>

Special Features

  • CREATE If a domain is registered successfully but the connection fails (the domain is registered with the status “failed”), the DS records calculated from the Dnskey records are not taken into account when generating the zone.
  • UPDATE / CHHOLDER If there are no DNSKEY records for a domain, these can be entered using an UPDATE or CHHOLDER.

    If one or more Dnskey entries already exist for a domain and the keyword “Dnskey:” is not present or is empty in a domain UPDATE or domain CHHOLDER order, the order will be executed and the original value of “Dnskey:” will be deleted.
  • CHPROV, See the “Change of operator” documentation
  • TRANSIT Any DNSkey entries are deleted for TRANSIT requests (regardless of whether the value of “Disconnect:” is “true” or “false”).
  • DELETE For DELETE requests, the DS records generated from the Dnskey entries are also removed from the.de zone.

Nameserver Predelegation Check

For more information, see DENIC-23p and https://nast.denic.de.