DNSSEC - Neue Resource Records

Wie bereits eingangs erwähnt wurde DNSSEC als rückwärtskompatible Erweiterung des etablierten DNS-Protokollls konzipiert. Das Protokoll wurde mit dem EDNS(0), den "Extension Mechanisms fpr DNS" (RFC 6891) dahin gehend erweitert:

DNSSEC Protocol Bits

BitBezeichnungBedeutung
ADauthenticated data

der Nameserver hat die DNSSEC-Validierung

durchgeführt und als authentisch bestätigt

CDchecking disabled

der Client verlangt, dass die DNSSEC-Validierung

durch den Nameserver nicht durchgeführt werden soll

DODNSSEC ok

Resolver signalisiert, dass er in der Lage ist, DNSSEC

zu verarbeiten


Zu beachten ist, dass sich die Flags AA (Authoritative Answer) und AD (Authenticated Data) gegenseitig ausschließen. Wenn eine DNSSEC-Antwort direkt vom autoritativen Nameserver, ohne einen dazwischen liegenden Resolver, erhält, ist nur das Flag AA gesetzt.

Dies ist insbesondere der Fall, wenn man auf den Workshop-VMs eine Anfrage direkt an localhost (@127.0.0.1) schickt, und vom local laufenden Nameserver, der für seine Workshop-VM Zone (wsXX.ws.dnssec.bayern) autoritativ ist:


dig ws01.ws.dnssec.bayern. @127.0.0.1 +dnssec

; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> ws01.ws.dnssec.bayern. @127.0.0.1 +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54373
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1


Weiter benötigt DNSSEC zusätzliche Resource Records in den Zonendefinitionen, die als "Resource Records for the DNS Security Extensions" (RFC 4034) definiert wurde, um die vorher gehend beschriebene PKI-basierte Authentizität und Integrität einer Zone zu ermöglichen.

Resource RecordBedeutungEinträge
DNSKEYSchlüsselZSK (256) oder KSK (257), (fixed) Protocol (3), Algorithm (z.B. 5), Hash (AQPSK...)
RRSIGSignatur über RRsetaus dem Eintrag UND dem ZSK wird eine eindeutige Signatur errechnet
DSDelegated Signeröffentlicher Teil des KSK der nachfolgenden "Child"-Zone
NSECnächster sicherer Eintragnächster sicherer Eintrag in der Zone (als Ring: der letzte verweist auf den ersten)
NSEC3gehashter nächster sicherer Eintragwie NSEC, nur sind die Namensbezeichner (mehrfach) gehasht


Beispiele

Hier geben wir ein paar Beispieleinträge für die oben aufgelisteten DNSSEC-spezifischen Resource Records:


DNSKEY: Das folgende Beispiel ist ein Zone-Signing Key (da 256 - Bit 15 ist nicht gesetzt)


            300    DNSKEY    256 3 8 (

                    AwEAAc3IHgEHpu5srb3fG1B3YOwNWtP2Sy0z

                    5F8ArvpzOdx4o+/ef03DNon3pZt855P47fcY

                    xX3vIrsd1Jl+au1CIGaxwIAspWBoIyGqKofR

                    i01DhJeTWaZbgeipLoJmz/TjSM8cgJtDmgUO

                    eb9tLv25XNuktrq5q82809QINlSvFc+dr8tI

                    eoLuwBG3uPd/wgVzSLo9an6WDeOr1v6NtYKP

                    QzlTY7Hsyu0mitIz6OAn8z5yaB+KAcNkz6p1

                    cFXX7XJlFE0tnfvIIjjAV2Rrp3gCylDIc2QL

                    CYPqQJCtpYKQ9VH4CKPIBilopRzv2BpRzgTc

                    wKZud8q7SFukpslVKcFLrZc=

                    ) ; ZSK; alg = RSASHA256; key id = 56961


Felder im Detail:

300 (TTL), DNSKEY, 256 (Schlüsseltyp: Zone-Signing Key), 3 (Protocol ist immer 3), 8 (Algorithmus: RSA), (Hash des Schlüssels mit 64Bit-Encodierung über mehrere Zeilen), ";" ermöglicht noch als Kommentar der leichteren Lesbarkeit wegen hinzufügen, dass es sich um einen ZSK, mit RSASHA256 und der Schlüssel-ID=56961 handelt.

Der zweite Schlüssel ist unser Key-Signing Key (da 257 - Bit 7 ist gesetzt)


            300    DNSKEY    257 3 8 (

                    AwEAAfKp1aJHezNZPy3PG17yRmop/P4zm+wB

                    cr9ufKWwlUSvGLsZaO4qxvFbaEFyxlDGSJ1b

                    fSoYoi6fygllGjJT+fQolSxjOWPNg7nHBW3g

                    E72evKyciO5Qw/Pk9Bus5BJJpuDIumdBFCPh

                    5/hNUqwe2RwOVs7+bQSqTovO0eQX2p3J3kue

                    3AAH0vueGjRIik/IStpazr/d/QMuEGI/pmZE

                    0biNpQ67gqUbV6W+bfNvdI2mTuohKZe9JbpO

                    R+uBxSRiEVcqFSAJ5ZJYE6aCMkRtfUfDKI5U

                    c5ez7ztmWo7Fp5i4pMWL5GdT/MgSitbRYBWj

                    Khfq+37QuVMgB2pFbxWNO9c=

                    ) ; KSK; alg = RSASHA256; key id = 64867


Felder im Detail:

Bis auf 257 (Schlüsseltyp: Key-Signing Key), und natürlich einen anderen Schlüssel-Hash sind die Felder die gleichen.


RRSIG: Das Resource Record Set der beiden DNSKEYs (beide vom gleichen Typ) ist ebenfalls mit zwei Signaturen, für jeden Schlüssel (KSK=64867 und ZSK=56961) eine, versehen.

            300    RRSIG    DNSKEY 8 4 300 (
                    20170323111036 20170221111036 56961 ws01.ws.dnssec.bayern.
                    tdHdj5k1z4zUkaGODcOHoYnwopFajjib/C60
                    gJsAOH+dM48+/o3GaaSl+DdYwWz5bXLUuLk1
                    rskOjvF57A5NzlhbWdg612CaudRrd3IZEwsa
                    /eken8h+sRjKzuzEplEB7MrSoZ2Ly8uNBiCU
                    KdfYdqkmwsunMdSMGgyjSy1e2j4APreZoIw7
                    Y7BSQC0OO1zOMYgpFoOSSwdsOZTCrVQj2UI9
                    KOEE6V+fQzed6PZarCIVOH7vQoSFLOYEWkkx
                    r4G1msTJ06SlmuWZdKgChhxoWGbYAHTVgYtc
                    /ux3QLX5PwUM3CPf5G4xojpASsFI8naTJjjd
                    clTES5vXpfjSulexqQ== )
            300    RRSIG    DNSKEY 8 4 300 (
                    20170323111036 20170221111036 64867 ws01.ws.dnssec.bayern.
                    i0LHAyCVZzNh5MFrMt2bHEa+cJfRb3YQyUOD
                    QuLSGaqzHOZGQ4CjT9FhgvlxiVibyx/h0TrI
                    NwwlTXx+DvqhPe1WexRMTKzlEUUXJuyEi4FB
                    t08IwXLz3Mvp+MnE9RinlV8XKvbzRC/7md6i
                    y8Jqjtf+YGIdWXQtJQFFwB1LCZtB69Ww/Q8j
                    42pCrXL+rstXumqBaDDQWycaRNnhvbLC6PZD
                    9/mzmPyQFhjXkFSTsZ78Ws/7DVRWSYeDt/nH
                    w1lgisWpMzsTS1kUN2swlJsTvtZgd0s9Kdv9
                    IkoCgC5tJxHEj6tSvIaMyuD45UOiFtSfCWKw
                    QGa7oFLY8AoagQgitA== )


Felder im Detail:

300 (TTL), RRSIG (Typ ist Signatur), DNSKEY (Typ des RR) 8 (Algorithmus 8: RSA), 4 (Anzahl an Labels) 300 (ursprüngliche TTL des RRSets), 20170322151553 20170220151553 (Expiration- und Inception-Datum der Signatur), 56961 (Schlüssel-ID des Schlüssels, mit dem die Signatur erstellt wurde), ws01.ws.dnssec.bayern. (Zone für die der Schlüssel gilt)


Nun sehen wir uns noch der Vollständigkeit halber die einen gewöhnliches Resource Record Set mit seiner zugehörigen Signatur an.

RRSIG: IPv6 Eintrag (wie gewohnt) und nachfolgend die Signatur RRSIG über diesen Eintrag (selber Typ)


            300    AAAA    2001:4ca0:800:2:250:56ff:fe8f:5584
            300    RRSIG   AAAA 8 5 300 (
                    20170323111036 20170221111036 56961 ws01.ws.dnssec.bayern.
                    mGKSafZixhxwtBD74t8ntKmnBRiifUEr+1Yx
                    vuEtAVrQWyMOAM4Q6VY79oFz7N1/Ep1P4SVv
                    7U236LU9+PUuWFmujoKqDWC25+0b0cwKimKy
                    YaTRXWiXfRTkxtLYJJgi3bRUyrBgnkpXsQbX
                    8KckMjTBAHpkKWE4z4utOy0hWl/qlHc+yeqE
                    uKyUS8DM/vZ1SPktKy0nutK2LD00FqPlDF2d
                    WWqE1pgR/adiozjvwADfdxnIXZiB5tAy0BWj
                    pvEe9WNNweFiG35IpGnNy19ZOlCVWILj/dr3
                    3veYPkeWjP9A/zAQT1gs7GuOH2suqkFXf/A3
                    ar7HWxvRPkAg+vjFNw== )


Felder im Detail:

300 (TTL), AAAA (Typ des Eintrags ist IPv6), 2001:4ca0:800:2:250:56ff:fe8f:5584 (IPv6-Adresse)

300 (TTL der Signatur, sie muss dieselbe sein wie der Eintrag, der signiert wird, selbst hat), RRSIG (Typ Signatur) über einen AAAA (Typ des RRSets, der signiert wird), 8 (Algorithmus mit der die Signatur erstellt wurde: RSASHA256), 5 (Typ des Schlüssels: RSA), 300 (ursprüngliche TTL in Sekunden),  20170323111036 20170221111036 (Expiration- und Inception-Datum/Zeit der Signatur), 56961 (Schlüssel-ID des ZSK mit die Signatur erstellt wurde), ws01.ws.dnssec.bayern. (Zone, für die diese Signatur gültig ist), mGKSafZixhxwtBD74t8ntKmnBRiifUEr+1Yx... (Hash der Signatur)


Signaturen meherer ZSKs

Hat eine Zone mehrer aktive Zone-Signing Keys, d.h. deren Aktivierungsdatum schon vorbei ist, und Deaktivierungsdatum noch nicht erreicht ist, werden für jedes RRSet Signaturen mit jedem aktiven ZSK erstellt. Dies ist unter Umständen bei "Key rollovers" sinnvoll, vergrößert aber den Umfang der Zone.


DS: Delegated Signer

Der DS-Eintrag gibt den öffentlichen Schlüssel des KSK der nachfolgenden "Child"-Zone an, steht aber logischerweise in der signierten Zonendatei der "Parent"-Zone. Der Inhaber der Parentzone (z.B. Registrar, DENIC, o.a.) nimmt den Eintrag mit den DS-Parametern entgegen.


ws01.ws.dnssec.bayern.  300  IN DS 64867 8 1 D5E9D8A3C7B1E897237D2F03EAA521ACC1ACFA5A
ws01.ws.dnssec.bayern.  300  IN DS 64867 8 2 E10A74B7A9841CD46D264CA9B100A033EF17C15DBDEC4143FC3C9091 F7DFA8D4


Die Zone, an die delegiert wird, ws01.ws.dnssec.bayern. , 300 (TTL wie lange der Eintrag gültig sein solll), IN DS (Typ des Eintrags "Internet Delegated Signer"), 64867 (die Key-id des Key-Signing-Key der Zone), 8 (Algorithmus des Schlüssel) und 1 (Hashing-Algorithmus) und D5E9D8A3C7B1E897237D2F03EAA521ACC1ACFA5A (der Schlüsselhash selbst).

Hashing-Algorithmus 1 wird minimal vorausgesetzt. Aufgrund der Systemsbedenken mit RSASHA1 unterstützen alle modernen Nameserver Algorithmus 2 (RSASHA256), die dann gemäß RFC 4509 ("Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)") Algorithmus 1 ignorieren sollten.

Dementsprechend beachtet beispielsweise der LRZ-Nameserver, 10.156.8.23, auf dem die Zone ws.dnssec.bayern. liegt, mit der im Workshop gearbeitet wird, nur den DS Eintrag mit RSASHA256 Digest.


Out-of-band Kommunikation

Da der Eintrag in der Parentzone durch den Inhaber der Parentzone in irgendeiner Form autorisiert sein muss, erfolgt die Kommunikation der Einträge "out-of-band". Entweder gewährt man den "Child"-Zonenbetreiber dynamische Updates mittels nsupdate durch zu führen (wie im Falle des LRZ-Workshops), trägt die Parameter der DS-Einträge über ein Webinterface ein oder kommuniziert diese an den DNS-Admin der Parentzone.


NSEC: Next SECure Entry

Wie auf der Seite zu den "DNSSEC Grundlagen" beschrieben, benötigen wir eine Möglichkeit, um die sichere Nicht-Existenz eines Eintrags mitteilen zu können. Dies ermöglichen die NSEC-Einträge. Die Theorie dahinter haben wir auch auf der DNSSEC-Grundlagen-Wiki-Seite beschrieben.

Hier zeigen wir einen NSEC-Eintrag aus unserer Beispielzone im Detail (gemäß RFC5155). Der Eintrag ws01.ws.dnssec.bayern. besitzt unter anderem seinen SOA, A und AAAA-Eintrag mit der zugehörigen Signatur (siehe auszugsweise in den Beispielen oben):


ws01.ws.dnssec.bayern.

[...|

300    NSEC    dnssec-ws01.ws01.ws.dnssec.bayern. NS SOA MX RRSIG NSEC DNSKEY
300    RRSIG   NSEC 8 4 300 (
                    20170323145752 20170221145752 56961 ws01.ws.dnssec.bayern.
                    pFvpX023lNs4dXE4RkYDAwOS0g2OcAU04hms
                    /TjYJJLlz1cheDE1kVG073/ICa3SN8enc+Fa
                    ZS5nspIvPz9lViSpdDQPqGVIwj/mpfUhQC6d
                    lHnTqgoV8Ajn+Y++urbspfadQxaKx6S8BzmP
                    o9xbaKTRo/o1p7Uj9a7Xb7uPPi565SibgD4I
                    Sv4pS7r59wj6DlF9+r3S8Vcah6hOQzF6EXBc
                    NTnG9olPvt/qATxIMiKvDyPjEzZswYYVAAre
                    NNG5NCcBqtL3W4dIMrAUgBwJul7hi1LWoq/F
                    C+hUsFFfLqy3lYo4hEjd/+QPGK9Qsz8jipIn
                    8iKypMDndSuZO5sVGg== )

Felder im Detail:

300 (TTL), NSEC (Typ des Eintrags), dnssec-ws01.ws01.ws.dnssec.bayern. (nächster sicherer Eintrag in der Zone), NS SOA MX RRSIG NSEC DNSKEY (Einträge, die es für ws01.ws.dnssec.bayern. in der Zone gibt)

300 (TTL), RRSIG (Typ des Eintrags), NSEC (Eintrag für den die RRSIG gilt), 8 (Schlüsselalgorithmus: RSA), 4 (Anzahl an Labels), 300 (ursprüngliche TTL), 20170323145752 20170221145752 (Expiration und Inception Datum/Zeit der Signatur im Format YYYYMMDDhhmmss), 56961 (Key-ID des ZSK), ws01.ws.dnssec.bayern. (Zone, für die diese Signatur gilt), pFvpX023lNs4dXE4RkYDAwOS0g2OcAU04hms.... (Hash der Signatur)


NSEC3: Next (hashed) SECure Entry

Wie ebenfalls auf der Seite zu den "DNSSEC Grundlagen" beschrieben, gibt es die Möglichkeit, die Zone mit gehashten NSEC3-Resource Records zu versehen, um "Zone-Walking" deutlich zu erschweren.

Die Struktur der NSEC3-RRs entspricht denen der NSEC-RRs, ausser dass der "nächste sichere Eintrag" dort nur mehr als Hash und nicht mehr im Klartext auftaucht.


6NLOM6LDNN2OFACIJBLNNR3REUMHG88N.ws01.ws.dnssec.bayern.    300 IN NSEC3 1 0 10 BE49C31925A463DA (
                    LOAMCLU6KJSALPCGQR0T1C2AGLKJHJG2
                    NS SOA MX RRSIG DNSKEY NSEC3PARAM )
 

Felder im Detail:

6NLOM6LDNN2OFACIJBLNNR3REUMHG88N (Hashed Zoneneintrag - Zonenname bleibt natürlich im Klartext), 300 (TTL), IN NSEC3 (Typ: Internet NSEC3), 1 (Hash-Algorithmus: SHA1), 0 (Opt-out disabled) 10 (Hash-Iterations: 10), BE49C31925A463DA ("Hash-Salt"), LOAMCLU6KJSALPCGQR0T1C2AGLKJHJG2 (gehashter nächster sicherer Eintrag), NS SOA MX RRSIG DNSKEY NSEC3PARAM (existierende RR für 6NLOM6LDNN2OFACIJBLNNR3REUMHG88N in der Zone)


Die zugehörige Signatur steht direkt darunter, nur signiert kann dem NSEC-RR vertraut werden.


           300    RRSIG    NSEC3 8 5 300 (
                    20170323180653 20170221180653 56961 ws01.ws.dnssec.bayern.
                    niZbBba6jHG8T+RurkhVe8JDidSVOXEvCdrZ
                    NUeDNNAS7cw5+8bpnf9dXHkZ7RXtX7MZmgk4
                    4qsL/Jc507a0TO9dOxlUQu8ljOnAObEupaod
                    b59iROVVbv2Xc4Du6rwoteED/O/k9U3EnZQ5
                    csqrjhM0IKkPypLBzJtKDJY0TZvOSyWPusrJ
                    ohhV9E2DK25x7JRaArmZ5nn4iK5A166LOQe9
                    NZmciRZBehyn5NxhSNLmVe17ZxjVTMnsskuD
                    A1IMkcNYJN1gPEKZWTS9FpwevQjZw2fqvjuo
                    4uQG5Yu14r/cxsYTfQdkzkmTV5V6YvoltXt/
                    T+wQD1rzwGo2Wvlj9w== )


Felder im Detail (so wie alle Signaturen)

300 (TTL), RRSIG (Typ des Eintrags), NSEC (Eintrag für den die RRSIG gilt), 8 (Schlüsselalgorithmus: RSA), 5 (Anzahl an Labels), 300 (ursprüngliche TTL), 20170323180653 20170221180653 (Expiration und Inception Datum/Zeit der Signatur im Format YYYYMMDDhhmmss), 56961 (Key-ID des ZSK), ws01.ws.dnssec.bayern. (Zone, für die diese Signatur gilt), niZbBba6jHG8T+RurkhVe8JDidSVOXEvCdrZ.... (Hash der Signatur)