DNS Zonen mit DNSSEC signieren (mit Bind)

DNS Antworten können signiert werden, damit man überprüfen kann, ob es sich um eine richtige und vertrauenswürdige Antwort handelt. Die DNS Antworten werden vom authoritativen DNS Server signiert. Die Schlüssel, welche die Antworten signieren, werden von dem DNS Server eine Zone höher signiert. Über diese Chain-of-Trust können Anwendungssoftware und DNS Resolver prüfen, ob eine Antwort vertrauenswürdig ist oder nicht. Mit dem DNS Server bind kann man seine Zonen selber signiert anbieten. Ich zeige das am Beispiel der Domain example.org.

NSEC vs. NSEC3

Die Nichtexistenz einer Domain (NXDOMAIN) wird mittels eines NSEC Records (Next SEcure Record) bewiesen. Fragt man einen Nameserver nach einer nicht existierenden Domain, sagt dieser “diese Domain gibt es nicht, aber folgendes ist die nächst gültige…”. So werden alle existierenden Domains in einer Art Linked List verkettet. Damit ist es sehr einfach die ganze Zone durchzugehen und so alle existierenden DNS Einträge zu bekommen. Das geht z. B. mit dem Tool ldns-walk. Bei der neueren Version NSEC3 geht das nicht mehr, da dort der Eintrag mit einem Salt und mehreren Iterationen gehashed werden kann. Ein Angreifer kann mit einer Rainbowtable die Hashes vorberechnen und so offline probieren die Zone zu enumerieren, was sehr aufwändig ist (aber möglich). Deshalb sollte man heutzutage NSEC3 und nicht mehr nur NSEC verwenden.

Key Signing Key (KSK) erstellen

Der Key Signing Key (KSK) benötigt man um sich seinen Zone Signing Key (ZSK) zu signieren. Der eigene KSK wird von einer DNS Zone weiter oben signiert. Alle folgenden Arbeiten werden im Verzeichnis /etc/bind durchgeführt. So erstellt man ein Key Signing Key:

dnssec-keygen -3 -a RSASHA512 -b 4096 -n ZONE -r /dev/urandom -f KSK example.org
  • -3 aktiviert NSEC3
  • -a RSASHA512 Typ der Signatur
  • -b 4096 Blockgrösse

Dabei entstehen folgende Dateien:

  • Kexample.org.+007+28736.key: DNSKEY Record: Öffentlicher Schlüssel.
    Dient zum Verifizieren der ZSK Keys. Wird von der höheren Zone signiert.
  • Kexample.org.+007+28736.private: Privater Schlüssel zum Signieren des
    öffentlichen ZSK.

Der öffentliche Schlüssel beinhaltet einen DNSKEY Record:

# cat Kexample.org.+007+28736.key
; This is a key-signing key, keyid 28736, for example.org.
; Created: 20140902110043 (Tue Sep 2 13:00:43 2014)
; Publish: 20140902110043 (Tue Sep 2 13:00:43 2014)
; Activate: 20140902110043 (Tue Sep 2 13:00:43 2014)
example.org. IN DNSKEY 257 3 10 BQEAAAABwZTL[...]mDR7eaIPPjBTihK7w==

Darin sind folgende Werte zu sehen:

Zone Signing Key (ZSK) erstellen

Der Zone Signing Key (ZSK) Schlüssel wird vom eigenen KSK signiert. Die ganze Zone wird mit diesem Schlüssel signiert. So erstellt man ein Zone Signing Key:

dnssec-keygen -3 -a NSEC3RSASHA1 -b 2048 -n ZONE -r /dev/urandom example.org

Dabei entstehen folgende Dateien:

  • Kexample.org.+007+60310.key: Öffentlicher Schlüssel, DNSKEY Record. Dient zum Verifizieren der DNS Antworten
  • Kexample.org.+007+60310.private: Privater Schlüssel zum Signieren der Ressource Records
# cat Kexample.org.+007+50575.key
; This is a zone-signing key, keyid 50575, for example.org.
; Created: 20140902111305 (Tue Sep 2 13:13:05 2014)
; Publish: 20140902111305 (Tue Sep 2 13:13:05 2014)
; Activate: 20140902111305 (Tue Sep 2 13:13:05 2014)
example.org. IN DNSKEY 256 3 10 BQEAAAAB[...]KttL/MZLnPs=
  • 256: Nur Bit 7 vom flags Feld: Zone Signing Key (ZSK)
  • 3: Fix vom Protokoll definiert.
  • 10: RSASHA512

Zone signieren

Die neuen öffentlichen Schlüssel bindet man im Zonenfile mit der $INCLUDE Direktive ein:

# vi /etc/bind/db.example.org
; DNSSEC
$INCLUDE Kexample.org.+007+28736.key
$INCLUDE Kexample.org.+007+50575.key

Nebenbei ein Tipp für vi Benutzer: Die Dateinamen holt man in vi am einfachsten mit mit :r!ls Kexample.org.*.key.

Jetzt kann man die Zonen signieren. Dabei bekommt man eine neue Zone mit dem Suffix .signed.

# dnssec-signzone -3 `head -c 512 /dev/urandom | sha1sum | cut -b 1-16` \
-H 330 -t -o example.org db.example.org
Verifying the zone using the following algorithms: RSASHA512.
Zone signing complete:
Algorithm: RSASHA512: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
db.motd.ch.signed
Signatures generated:                       42
Signatures retained:                         0
Signatures dropped:                          0
Signatures successfully verified:            0
Signatures unsuccessfully verified:          0
Signing time in seconds:                 1.189
Signatures per second:                  35.296
Runtime in seconds:                      1.289

 

  • -3 aktiviert NSEC3 und benötigt als Parameter einen Salt, welcher aus den ersten 16 Zeichen einer SHA1 gehashten Zufallszahl besteht. Es wird empfohlen bei jedem signieren einen neuen Hash zu generieren.
  • -H gibt an wieviele Iterationen für den Hash gemacht werden müssen. Empfehlungen dazu gibt es im RFC4641 (DNSSEC Operational Practices): http://www.ietf.org/rfc/rfc4641.txt
  • -t zeigt am Schluss eine Statistik an
  • -o gibt die Zone an
  • am Schluss gibt man das das Zonenfile an

Update (25.05.2021): Der im Best Current Practice Draft  “Guidance for NSEC3 parameter settings” empfohlene Wert für die Anzahl Iterationen ist 0 und kein Salt (“-“).

Falls man die Keys in einem anderen Verzeichnis hat, kann man dies mit -K angeben.

Die neue Datei der signierten Zone heisst db.example.org.signed und beinhaltet folgendes:

  • Alle Ressource Records lexographisch (alphabetisch) sortiert.
  • Nach jedem Ressource Record wird ein NSEC3 Record eingefügt, welcher auf den nächsten Ressource Record zeigt (gehashed).
  • Alle Ressource Records (auch die neuen NSEC3 Records) haben ein RRSIG Record bekommen, welches die Signatur vom Record ist. Erstellt wurde diese Signatur mit dem ZSK.

Bei jeder Änderung in der Zone, muss diese neu signiert werden.

Die signierte Zone ist 30 Tage lang gültig und muss danach wieder erneut signiert werden. Mit -e YYYYMMDDHHMMSS kann dnssec-signzone eine eingene Endzeit angegeben werden.

DNSSEC in Bind aktivieren

In Bind kann man dnssec in den globalen Optionen aktivieren:

# vi /etc/bin/named.conf.options
dnssec-enable yes;

Danach aktiviert man für die zu signierende Zone das neue Zonenfile mit dem Suffix .signed:

# vi /etc/bind/named.conf.local
zone "example.org" {
type master;
file "/etc/bind/db.example.org.signed";
allow-transfer { "slaves"; };
notify yes;
};

Key beim Registrar eintragen

Jetzt muss man DNSSEC bei seinem Registrar aktivieren. Dies geschieht zum Beispiel online. Beim Aktivieren wird man nach dem richtigen KSK gefragt, was man gestätigen muss.

Die Zone höher muss die Delegation Signer Ressource Records (DS-RR) für die darunterliegende Zone eintragen. Sind die DS-RR eine Zone höher eingetragen, kann die Zone nun verifiziert werden. Die DS-RR werden zum erstellen der Chain-of-Trust benötigt.

Es dauert es je nach dem eine Weile bis man die DS-RR sieht:

$ dig example.org ds @a.nic.ch +multiline
; <<>> DiG 9.9.2-P2 <<>> example.org ds @a.nic.ch +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58471
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.org. IN DS

;; ANSWER SECTION:
example.org. 3600 IN DS 7127 7 1 (
5D904BEC66E4D793C190B09954C56B592A46C278 )
example.org. 3600 IN DS 7127 7 2 (
3002E43C7AF9CCB31FD1CCD90F9BFD8A6DC5BB0097F8
6A6146D2C57B85145502 )
example.org. 3600 IN DS 7127 7 4 (
AD09B9B7DAB830AA9F6371C7A69A5C122B70501DEAFE
14F13A6D0DE36E8703049C6A4824A28BC6019AD54030
53DB8BD0 )

;; Query time: 13 msec
;; SERVER: 130.59.1.80#53(130.59.1.80)
;; WHEN: Tue Sep 2 16:09:07 2014
;; MSG SIZE rcvd: 191

In den DS Records sieht man den KSK, welcher hier die ID 7127 trägt.

Auch der whois Eintrag zeigt, dass DNSSEC aktiviert ist:

$ whois example.org | grep DNSSEC
DNSSEC:Y

DNSSEC Testen

Jetzt können die Nameserver, welche die DNSSEC Validierung aktiviert haben, die Antworten für unsere Zonen validieren.

Die öffentlichen DNS Schlüssel (KSK und ZSK) können so abgerufen werden:

$ dig example.org dnskey +noall +answer +multiline
; <<>> DiG 9.9.2-P2 <<>> example.org dnskey +noall +answer +multiline
;; global options: +cmd
example.org.   86400 IN DNSKEY 256 3 7 (
BQEAAAABv2VU7NB5EcAJxCUWS3Mn7ULEDOejyKhgqg98
oTGO8KmJBwJ2jxz3lkUwp4GfypSon9q1KDYUr/gmOX+9
ukU3BBNUrFYBieuxMCnpGZbLSFF0uSWKiLQUWKtXfbBt
aqw/vJ2pLCPJTOT9ezmJ9MIR8LiVzlSMPL1HCOWufn8K
/oPbTvq+tWINBKQ/Oh+pre31TOvQg47JW/Nel9nBhGo/
tLCOCqQ1McEImYTWp8rpdlHmvAgbJD6s9MDB6pvbxs9B
LsV1Ahwa98ksOAgccZDJxq2NgLZ32F2IjUHsMfMJSni9
TaCgBlPCwz5aSkUpSaicM524pSjFsbwmCkb/c7m+Nw==
) ; ZSK; alg = NSEC3RSASHA1; key id = 6826
example.org.   86400 IN DNSKEY 257 3 7 (
BQEAAAABuUUu5vLyfNru1Et/SV/S3X8Q23qs2tx3HRQb
X0w7Qadevocg2BLRTAQIbOOrPfhvB5F3f73GrnsRBxTy
XBtCbIMfQ8WNMHKzOp6vEVCx2o8FuRa8c1SIiuaYKfAH
38A/wj/8Y52UDaRV0KZrcEUZsv3goq3hSL0dZgHHfbXb
BesHW1jQiBd0kkrDmoe08ls9dw1dRHH3/mos6sEw6bER
++TwmYRXGsm+hv3h2J3zLY8DZOqMpw8IEcgVkL7dux72
XK8zrkgQeTlHCsj36ZDb1w7ApAMLHZkbG0kFTX+U2AT6
2rtvVA7VGEaTCnx7Nuu9zg9BnGkcmwGRhMtOx0QkNjBy
JPy6kSMMfYOtx1LcY4pV2jtlBKoNdxcbrBeG05FFur3O
QqCKJd+I7mnX8zjXgBH6jgHz5zN2jn/I0ZDtcancT09v
T51+ViC4weAs3LZEwMl1at8MhjRdb9uvbS6dS3fMtPp5
2sO3OpZ2WwGy1Bgmi303swqZDgOd9UvMQbMfdGfNuaoF
6kVVKH3JRe7BBY872rcEhrkdbelB60EBINo5edepd8Sq
ZrvtCYdJX0RmtRBrBedOcbahGJ2hq5mylxCdmTkxCU83
lhoiu8N49bjsK2kkxZkxlkITe1XPEvhdDvW94naTSHpZ
XzhGiQ2MFZe3N73g9AhK9EvGOdBsLUU=
) ; KSK; alg = NSEC3RSASHA1; key id = 7127

Zu jedem Record bekommt man jetzt ein RRSIG Record, welcher die Signatur darstellt. Dies kann mit der Option +dnssec in dig aktiviert werden:

$ dig example.org. A +dnssec @ns1.motd.ch +m
; <<>> DiG 9.9.2-P2 <<>> example.org. A +dnssec @ns1.motd.ch +m
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7176
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;example.org. IN A

;; ANSWER SECTION:
example.org. 86400 IN A 5.45.105.71
example.org. 86400 IN RRSIG A 7 2 86400 (
20141002105145 20140902105145 6826 example.org.
DmBi5IbgmlTLfeABOg1sXx7kRzD4D5n07pY/K31rgmYT
Cd5Lq7gy51veKxtd+qNxu8ahxp5wZ3redASjBAVY2sui
m03oczA8ET051G8dmdHKT4nL4h5/Z9RYIoH7i8D+otQP
mMz5mrZkfg6MwUUdd4GCkc/7nf9y31dLZXi/zi4HElOx
2Qt2yCVn4qrtp3f8YgocReOUZaaONYlPaROfenaIHYjT
n3jIMMqCZ4sEMZRh1EMWSziGPomq+S4UHZkJzWc1as32
ad5aNe50m3mOukZCr+IDsVWZW+Bn0YIBNIm8W24NrrZG
ZAonGLx8z3q4zmbBW6dYfFcRejYi1l2LBQ== )
[…]

In Firefox gibt es das Plugin DNSSEC Validator, welches einem den Status von DNSSEC der Domain einer Webseite anzeigt:

dnssec-validator

Es gibt auch Webseiten, welche einem die DNSSEC Konfiguration prüfen. Hier ein Beispiel vom DNSSEC-Debugger von Verisign Labs (http://dnssec-debugger.verisignlabs.com):

verisignlabs

Weitere Schritte/Ideen

  • Einpflegen von SSHFP Records für SSH Public Keys
  • Einfplegen von PGP Key im DNS
  • Einpflegen von TLSA Records für DANE Unterstützung (SSL Fingerprint im DNS)
  • Automatisches Signieren der Zonen bevor sie ungültig werden
  • Resolver nutzen, welche ungültige DNSSEC Antworten ablehnen
  • Automatisches Signieren von Zonen mit Dynamischen Updates
  • Sich Gedanken machen, wie man die Schlüssel am einfachsten wechselt und den ZSK regelmässig wechseln.
  • Signierte Zone in einem Monitoringtool eintragen, damit man bei Problemen benachrichtigt wird

Links, Quellen und weitere Informationen

26 thoughts on “DNS Zonen mit DNSSEC signieren (mit Bind)”

  1. Es gelingt mir einfach nicht, mit

    :/var/lib/named/keys # dnssec-signzone -3 `head -c 512 /dev/urandom | sha1sum | cut -b 1-16` -H 330 -t /var/lib/named/master/mydomain.de.zone
    dnssec-signzone: fatal: No signing keys specified or found.

    Alle Versuche mit unterschiedlichen Konstellationen schlagen fehl. Wie kann man nur ein solches Werkzeug programmieren.

    Reply
    • Du hast eine etwas andere Verzeichnisstruktur als ich.

      Falls du nicht bereits im Verzeichnis mit all den Keys drin bist, gibt dies mit -K /path/to/keydir an.

      Der Dateiname der Keys ist folgendermassen aufgebaut: Kname+algorithm+keyid. Der jeweilige Key muss in der Zone included sein. Dann wird der Key automatisch gefunden.

      Mit der -k keyfile Option, kannst du den Key, mit welcher die Zone signiert werden soll, auch direkt angeben.

      Hat das geholfen?

      GRZ
      Emanuel

      Reply
  2. Hi, danke erstmal für deine ausführliche Ausarbeitung!
    Wofür steht der Operator -e in dem dnssec-keygen-Befehl? Auf der Manpage konnte ich dazu nichts finden.

    Reply
    • Hi.

      Bitte gerngeschehen 🙂

      Wenn ich jetzt mit einer aktuellen Version den Befehl ausführe, erhalte ich folgende Meldung “phased-out option -e (was ‘use (RSA) large exponent)”:

      $ /usr/sbin/dnssec-keygen -3 -a RSASHA512 -b 4096 -n ZONE   -e -r /dev/urandom -f KSK example.org                                                                                                                                                          
      phased-out option -e (was 'use (RSA) large exponent)
      Generating key pair...........................................................................................................................................................................................++ .............................................
      ..........................................................................................................................................................................++
      Kexample.org.+010+27081

      In älteren manpages befindet sich noch die Doku dazu:

      -e
          If generating an RSAMD5/RSASHA1 key, use a large exponent.

      Das ist also eine veraltete Option um den Public Exponent explizit bei grösser zu setzen.

      Bei einer aktuellen Version sieht das so aus:

      $ grep PublicExponent Kexample.org.+010+02832.private
      PublicExponent: AQAB

      Das hat den Hex wert 10001:

      $ base64 -d <<< AQAB | xxd -p
      010001

      Die Keys, welche ich früher generiert habe, haben folgenden Wert:

      $ grep PublicExponent *.private
      Kemanuelduss.ch.+007+06826.private:PublicExponent: AQAAAAE=

      Das ist in Hex:

      $ base64 -d <<< AQAAAAE= | xxd -p
      0100000001

      Das bestätigt die Manpage von früher. Heute wird aber die Option ignoriert.

      Dies hat mit Geschwindigkeit bei den kryptographischen Operationen zutun. Je grösser der Exponent, je länger dauert die verifikation der DNSSEC Signaturen. Grössere Werte, bedeuten aber nicht unbedingt, dass die Signatur stärker ist. Siehe dazu folgenden Post: https://www.imperialviolet.org/2012/03/16/rsae.html

      Merci für die Info, ich hab den Blogpost angepasst und die -e Option entfernt.

      Gruss,
      Emanuel

      Reply
  3. Hallo,

    Ich danke auch erstmals für die gute Erklärung jene von Wikipedia und heise sind fürs nichts. Erst als ich diesen Artikel fand klärten sich sehr viele Fragen. Danke dafür!

    Ich lese im Artikel nie etwas vom RRset. Werden nicht die RRsets signiert und danach mit NEC3 alphabetisch sortiert und anschliessend gehasht? Was ich nicht genau verstehe: Weshalb werde die Domains gehasht bei NEC3, was bringt es einem Angreifer zu wissen, wessen domains im Zonefile existieren. NSEC3 löst ja damit dieses Zone walking Problem welches bei NSEC existierte…

    Liebe Grüsse
    Nicolas

    Reply
    • Hey Nicolas

      Bitte gerngeschehen 🙂

      Bzgl. RRsets: Laut RFC 8499 “DNS Terminology” [1] und RFC 2181 “Clarifications to the DNS Specification” sind RRSet eine Gruppe von DNS Records mit dem selben Label, Class und Type aber unterschiedlichen Daten (damit diese nicht mehrmals vom DNS Server im DNS Paket übertragen werden müssen). Dies ist nicht explizit etwas von DNSSEC.

      Bei DNSSec werden einzelne DNS Records signiert. Bei DNSSEC werden alle DNS Einträge der Reihe nach sortiert und dann für jeden Eintrag ein NSEC bzw. NSEC3 Record generiert. Dies wird so gemacht, damit man pro Domain einen eigenen NXDOMAIN ähnlichen Record hat um die Nichtexistenz eines Records zu signieren (weil wenn nur der NXDOMAIN Record signiert wäre, könnte man diesen in einer Replay Attacke an den Resolver senden und er würde glauben dass es eine bestimmte Domain nicht gibt).

      Wie du korrekt geschrieben hast, kann man somit DNS Zonen enummerieren und mit NSEC3 ist das nicht mehr so einfach möglich (man muss die Hashes knacken um die Einträge rauszubekommen).

      Was bringt das einem Angreifer? Ein Angreifer kann so sehr viel über ein Netzwerk lernen. Welche Hosts es gibt, welche Software eingesetzt wird (Beispiel: confluence.example.com), wann ein neuer Host dazukommnt (indem man das regelmässig macht und den Unterschied vergleicht), etc. Zudem bieten Webserver je nach Hostnamen einen anderen Inhalt an (das wird anhand des Host HTTP Request Headers entschieden). Wenn man im Browser über die IP Adresse zugreift, erhält man vielleicht nur eine Default Seite, mit einem Hostnamen wie splunk.example.com, eine installierte Webapplikation. Ein Angreifer hat somit mehr Infos und die Angriffsfläche ist grösser.

      Natürlich sollte die Sicherheit einer Infrastruktur nicht darin bestehen, indem man Hostnamen geheim hält. Dies nennt man “security through obscurity” und sollte nicht dazu verwendet werden um Systeme sicher zu machen. Man kann damit jedoch die Angriffsfläche etwas reduzieren.

      Angenommen es gibt eine gravierenden Sicherheitslücke in der neusten Splunk Version und über DNS Zone walking findet jemand raus, dass es den Hostnamen splunk-3007-bern.example.com gibt, dann kann dies von Angreifern sehr schnell rausgefunden und ausgenutzt werden. Wenn dies jedoch nicht öffentlich im Internet bekannt ist, dass es diesen Hostnamen gibt, dann ist die Chance kleiner dass das jemand ausnutzt.

      Es gibt jedoch viele weitere Methoden um an Hostnamen zu kommen. Geh mal nach https://crt.sh und suche nach %.example.com: Dann hat man sehr schnell sehr viele Hosts auf der example.com Domain beisammen.

      Ich hoffe das konnte deine Frage klären.

      Beste Grüsse,
      Emanuel

      [1] https://tools.ietf.org/html/rfc8499#section-5
      [2] https://tools.ietf.org/html/rfc2181#section-5

      Reply
      • Hallo,

        Allgemeine Frage vorab zur Grundlage von DNSSEC:

        Ich habe je 2 Files beim KSK und ZKS. Ein File vom KSK beinhaltet ja einen private Key welches den privaten ZKS-Key unterzeichnet das zweite File behinhaltet den Public Key welches als Hash-Wert in die übergeordnete Domain übergeben wird. Der ZKS hat auch einen privaten Key welches später die Signatur der jeweiligen diversen RRSIGs unterscrheibt. Der öffentliche Key vom ZKS wird 1:1 vom File .key ins Zonefile der Kopiert.

        Meine Frage nun, wenn ich einen DNS Resolver von einer beliebigen Domain nach dem DNSKEY befrage und ich 2 öffentliche DNSKEYs vom KSK bekomme, kann dass sein oder nicht? Ich würde mal Nein sagen, weil die übergeordnete Domain würde diesen ja so nicht kennen und diese übergeordentete Zone kennt ja nur einen Key. Beim ZKS hingegen ists glaube ich möglich oder? Der ZSK kann mehrere DNSKEYs in der Zonendatei haben oder und somit mehrere öffentliche Schlüssel (DNSKEYs)?

        Zum 1. Abschnitt:

        Also als Label wird eine Subdomain bezeichnet oder? Also “www.”example.org und “test.”example.org wären also zwei unterschiedliche Label und diese würden daher nicht als RRset gruppiert. Umgekehrt würden alle RR-Typen (z. B A,AAAA,NS…) vom Label “www.”example.org gruppiert werden. Wenn ich also nach A-Typ einen DNS Resolver befrage antwortet er mir ja oft mit einem Additional Records. Sind das diese gruppierten RRSets welche mitgeliefert werden? Ich vermute ich mal ja…? Pro Label existiert also auch nur eine RR-Signatur? Ausser ich möchte nicht, dass meine Signatur / Key aufeinmal verfällt und ich daher auf ein double Keyrollout setzte?

        Zum 2. Abschnitt bezüglich NSEC3:

        Das verstehe ich jetzt gar nicht. Meinst du mit Domain pro Subdomain oder pro Domain wie example.de? Pro Domain wird doch in der Regel ein Zonefile erstellt? Was ich weiss ist nur, dass “NXDOMAIN” soviel heisst wie keine Ahung, ich weiss nichts über diese Zone. Den ServFail gibts auch noch wenn ich mich nicht täusche. NSEC3 verkettet meines wissens Domains zum Beispiel a.example.ch -> b.example.ch / b.example.ch -> c.example.ch / c.example.ch -> a.example.ch dabei verstehe ich nicht wie dadurch verhindert werden soll, dass ein Angreifer die Antwort so manipulieren soll, dass eine Lücke entsteht. Vorallem müsste ja die ganze Liste aller Subdomains von a-c.example.ch übermittelt werden, damit überprüft werden, kann obs eine Lücke gibt oder nicht. Das geschieht ja vermutlich nicht, weil ja nur der angefragte Ressourcen Record und eventuell Additional Records an den Subresolver gesendet werden oder? Weiter wird der NSEC-RR auch signiert wozu wird dann die ganze NSEC-Kette erstellt mit dem nachfolgenden Subdomains? Irgendwie verstehe ich bei NSEC zur Zeit nicht gerade viel…

        Gruss
        Nicolas

        Reply
        • Hey Nicolas

          Bzgl. mehrere KSK.

          Es kann gut sein, dass du mehrere KSK erhältst.

          Beispiel von icann.org:

          $ dig icann.org dnskey +multiline

          ; <<>> DiG 9.14.1 <<>> icann.org dnskey +multiline
          ;; global options: +cmd
          ;; Got answer:
          ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26362
          ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

          ;; OPT PSEUDOSECTION:
          ; EDNS: version: 0, flags:; udp: 512
          ;; QUESTION SECTION:
          ;icann.org.     IN DNSKEY

          ;; ANSWER SECTION:
          icann.org.      3600 IN DNSKEY 256 3 7 (
                          AwEAAa64Dnm1zYNVp3ImBheex+CW6Q8fLbcvCZ+2BNlg
                          A35KR0CV2sqK9PcZ+jv/LA+YHnFYm4lBkI7znbwMekOd
                          ruoYPIhNkSECa9HVbMe8738cabB1DHF0NIOknrd0iVdu
                          pwOBfpr8aEemSWB07GLP7fGpg2s9KTlP98vOHs3jvOHV
                          ) ; ZSK; alg = NSEC3RSASHA1 ; key id = 64452
          icann.org.      3600 IN DNSKEY 257 3 7 (
                          AwEAAaxEcKY6A65zj+LOPz61QMjhiSFTjuw77gmHUtrA
                          H2IZ53i61DdNjh7h5LhujGjVR7+XsL+DzQJhJQUSrIil
                          aNv2sHlzjjDdXKsD4TxaziLCvbog/5J9DIc1piDOp5Bk
                          y5l2YoX25AyQIbm1t4mxiMCkjW6ItXO3FGFdP2W+yQXL
                          zK5b+oC8UmlBViZaR2N8+By1uDtSTT+hPWCUXx7BbK1q
                          UuKrOHYW5wtklzn9zuPYRaT1IAU6nYQeRVAjyqEnllk7
                          ybhT4Jic4yyUIaEJaHxJHQwW2Uu+YLhstrJgkf6XZ+O2
                          XhtFAXRh09peoIaKpB0ldrj602qaXRWahiRQqq8=
                          ) ; KSK; alg = NSEC3RSASHA1 ; key id = 18060
          icann.org.      3600 IN DNSKEY 257 3 7 (
                          AwEAAdKq+ROFFjVRGHeuAMC1vhI2HicoXKy9bGbcWZIc
                          DEA90NynbT08cBeM9Is7Bd88KFWCLaan4mcOKU5tN+ZQ
                          5rE3XT0ieQwf1AuusyQWIoRvg8RsYFHbANAZ/4pu09Gb
                          w/QUe6b6aoCLXTKDwdDBXm8B6H7tyiMUMd5krz2gLZ9N
                          f3qBL3oodJDCDuO9XWglww+YixmoVfqahCOS+brGVrzw
                          0ShbQsO89vE0Q3FRlaERiLF0HTih4G2SlMaSBcZiw1vF
                          DFAs3/RAVl4mYkjPD9TEnZAB4Ocz4GwToH58dO9P4Pr1
                          iah0sSZD/fklVgD5NDA5iWVe23MANlLDoPM/j4s=
                          ) ; KSK; alg = NSEC3RSASHA1 ; key id = 23584
          icann.org.      3600 IN DNSKEY 256 3 7 (
                          AwEAAdU9iH07Nr6i1Z/Qcz4d6iNz6mZ1OjVQcBVwHW8u
                          oF9Q+9gK3uf6O06MemwTWTK6rPNIBTp4ctWp38x/k4sX
                          vRcdCIHSCmaE63AlfWbNUoALva73UHvDUtJb07MpF2Tj
                          dBUz/O8lUTHx+fe2SZH/sQW7JkNiVggr/q2q6A5yeP+z
                          ) ; ZSK; alg = NSEC3RSASHA1 ; key id = 21255
          icann.org.      3600 IN DNSKEY 256 3 7 (
                          AwEAAbl3XPdJwPEGDxwyWkhqcWK+p+Qvgj0W18m54cE4
                          tkQ34hCr8zZjjpzkBAVEYYkTVKpJOVTMp2I4fn481N6z
                          cteS39TK5DcZcFEGs4q7r97S06iruGOscpFeR3RTNIhY
                          kcJt4/BMAIForXnVsqIc5lV7jYCMTy1rnzYWbcMJmmmf
                          ) ; ZSK; alg = NSEC3RSASHA1 ; key id = 36728

          ;; Query time: 26 msec
          ;; SERVER: 192.168.23.1#53(192.168.23.1)
          ;; WHEN: Mon May 13 22:33:16 CEST 2019
          ;; MSG SIZE  rcvd: 1034

          Hier gibt es auch zwei KSK:

          • KSK; alg = NSEC3RSASHA1 ; key id = 18060
          • KSK; alg = NSEC3RSASHA1 ; key id = 23584

          Deshalb ist es auch möglich, dass die übergeordnete Zone mehr als nur 1 KSK kennt:

          $ dig icann.org ds +multiline

          ; <<>> DiG 9.14.1 <<>> icann.org ds +multiline
          ;; global options: +cmd
          ;; Got answer:
          ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21424
          ;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1

          ;; OPT PSEUDOSECTION:
          ; EDNS: version: 0, flags:; udp: 512
          ;; QUESTION SECTION:
          ;icann.org.     IN DS

          ;; ANSWER SECTION:
          icann.org.      86400 IN DS 18060 7 1 (
                          04CF77A76FD328458005D2B35E416F209A3420A0 )
          icann.org.      86400 IN DS 18060 7 2 (
                          6BE021818B9F10ED981A03ACBF74F01E31FB15C58680
                          AD0C4BAA464BF37A7523 )
          icann.org.      86400 IN DS 32134 7 1 (
                          3D54D51109645E8315F59790B920323D361B065F )
          icann.org.      86400 IN DS 32134 7 2 (
                          6C321409786B95BEEE60E6D42F3713ACC3A9B5D18442
                          091A792FBDD1EA8E4655 )
          icann.org.      86400 IN DS 41334 7 1 (
                          49D712CF7A8984B7545FDC7E69D7372782339B3A )
          icann.org.      86400 IN DS 41334 7 2 (
                          C299FAF7D6F9BCB310200ECF2EA216A2E83F7ACB15C8
                          D72D79641FA8DFACF9A9 )
          icann.org.      86400 IN DS 41643 7 1 (
                          93358DB22E956A451EB5AE8D2EC39526CA6A87B9 )
          icann.org.      86400 IN DS 41643 7 2 (
                          B8AB67D895E62087F0C5FC5A1A941C67A18E4B096F6C
                          622AEFAE30DD7B1EA199 )
          icann.org.      86400 IN DS 17248 7 1 (
                          88151C40E4673E7023E6AD1902A8AE055F3DDF61 )
          icann.org.      86400 IN DS 17248 7 2 (
                          885CF8A6CF35FD5C619E1D48B59AFB23063BBA9FEC52
                          FF25F99094CBA10910A2 )

          ;; Query time: 15 msec
          ;; SERVER: 192.168.23.1#53(192.168.23.1)
          ;; WHEN: Mon May 13 22:38:44 CEST 2019
          ;; MSG SIZE  rcvd: 458

          Dies wird beispielsweise so gemacht, wenn der KSK ausgetauscht wird. Weil DNS viele Caching-Mechanismen verwendet, kann man nicht einfach den alten Key löschen und einen neuen anlegen. Dann muss man gleichzeitige den neuen KSK einfügen und anhand der TTL sicherstellen, dass der alte nicht mehr im Cache vorhanden ist. Ein Beispiel ist in einem Report von ICANN beschrieben: https://www.icann.org/en/system/files/files/review-2018-dnssec-ksk-rollover-04mar19-en.pdf.

          Beim ZSK ist es genau dasselbe. Dort kann ich auch mehrere haben um beispielsweise ein Key Rollover durchzuführen.

          Bzgl. den RRSets:

          Wenn du zum Beispiel nach dem MX Record fragst werden diese zusammengefasst (weil gleiche diese dasselbe Label, die Class und den Typ haben. Diese werden deshalb zusammen signiert:

          $ dig icann.org mx +dnssec

          ; <<>> DiG 9.14.1 <<>> icann.org mx +dnssec
          ;; global options: +cmd
          ;; Got answer:
          ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32025
          ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

          ;; OPT PSEUDOSECTION:
          ; EDNS: version: 0, flags: do; udp: 512
          ;; QUESTION SECTION:
          ;icann.org.         IN  MX

          ;; ANSWER SECTION:
          icann.org.      600 IN  MX  10 pechora6.icann.org.
          icann.org.      600 IN  MX  10 pechora8.icann.org.
          icann.org.      600 IN  MX  10 pechora1.icann.org.
          icann.org.      600 IN  MX  10 pechora2.icann.org.
          icann.org.      600 IN  RRSIG   MX 7 2 600 20190603035755 20190512173015 36728 icann.org. SS+h0jx/uGX6wMWkK8C0hUDGoWQXWeogWv1YAZLvu2PPVnpa5J8Hbpfo PV//DnJ9/3Do3PjSdMvVyzUQbLjtJxdYgHFuNW3HUljIYOj0JTUPHMQf oMly3fs2FPIGKbW3dWAc7jXsk3oPMERLRfFw5CwxdnnaM9+7MeIqkVKT WNo=

          ;; Query time: 94 msec
          ;; SERVER: 192.168.23.1#53(192.168.23.1)
          ;; WHEN: Mon May 13 22:47:46 CEST 2019
          ;; MSG SIZE  rcvd: 307

          Dies hab nichts mit der Additional Section zutun. Dies sind jeweils eigenständige zusätzliche Antworten, welche auch wieder separat signiert werden:

          $ dig switch.ch ns +dnssec

          ; <<>> DiG 9.14.1 <<>> switch.ch ns +dnssec
          ;; global options: +cmd
          ;; Got answer:
          ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10730
          ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 9

          ;; OPT PSEUDOSECTION:
          ; EDNS: version: 0, flags: do; udp: 512
          ;; QUESTION SECTION:
          ;switch.ch.         IN  NS

          ;; ANSWER SECTION:
          switch.ch.      86400   IN  NS  ns2.switch.ch.
          switch.ch.      86400   IN  NS  ns3.switch.ch.
          switch.ch.      86400   IN  NS  scsnms.switch.ch.
          switch.ch.      86400   IN  RRSIG   NS 13 2 86400 20190602122025 20190509151955 30131 switch.ch. d4fttzlqhQ0DN0amAMEJgKtHX3MOJVNDK1ZTV2pmPiClPtkLzHuXbmUw fKY1qizEac4VEOD8xUr9EZYsaootZg==

          ;; ADDITIONAL SECTION:
          scsnms.switch.ch.   65482   IN  A   130.59.31.26
          scsnms.switch.ch.   65482   IN  RRSIG   A 13 3 86400 20190530001821 20190501040529 30131 switch.ch. AIURBFsYJMJoUJXeEWce/aQTJ4zAzfFR4TkNbTnGzZXvW+LLYzCgl0hJ 3W4BcTYejCgKhJSar3A7hm2kRXmONA==
          scsnms.switch.ch.   65212   IN  AAAA    2001:620:0:ff::a7
          scsnms.switch.ch.   65212   IN  RRSIG   AAAA 13 3 86400 20190604233153 20190510120550 30131 switch.ch. B7nqlcPzr7MWsGJvCqDp88QpTgeG8RhB+Hmy0dLBUkxmLGILlaSVJG/G uqIzfTfQgPEXkPUSqVNtL7VazKbzNw==
          ns2.switch.ch.      31488   IN  A   130.59.31.29
          ns2.switch.ch.      31488   IN  RRSIG   A 13 3 86400 20190602091521 20190505040528 30131 switch.ch. iSoGsKL6dpS8o44GpXr9T4//NgqEvBWR/8l8gnZJYDApOxfN16DnUa1Z SU/Xm35OchR2sU4FPqYVgjJI7tB+kQ==
          ns2.switch.ch.      46582   IN  AAAA    2001:620:0:ff::2f
          ns2.switch.ch.      46582   IN  RRSIG   AAAA 13 3 86400 20190605041302 20190508040551 30131 switch.ch. 1rVU+wrrb3HNz4NiuquBI8k07Bbb+aDmCBN7XXs4oN/2QyWfGoihHiXB V5Nwnd2x9+3/9fUdx/e1XCT4SsM0JA==

          ;; Query time: 15 msec
          ;; SERVER: 192.168.23.1#53(192.168.23.1)
          ;; WHEN: Mon May 13 22:50:41 CEST 2019
          ;; MSG SIZE  rcvd: 708

          Bzg. den NSEC/NSEC3 Records:

          Genau, eine Zone hat in der Regel ein Zonenfile. NXDOMAIN heisst aber nicht “ich weiss nichts über diese Zone”, sondern “den angefragten DNS Record gibt es nicht”.

          Es gibt z.B. keinen A Record für foobar.switch.ch (→ NXDOMAIN):

          $ dig foobar.switch.ch

          ; <<>> DiG 9.14.1 <<>> foobar.switch.ch
          ;; global options: +cmd
          ;; Got answer:
          ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64659
          ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

          ;; OPT PSEUDOSECTION:
          ; EDNS: version: 0, flags:; udp: 512
          ;; QUESTION SECTION:
          ;foobar.switch.ch.      IN  A

          ;; AUTHORITY SECTION:
          switch.ch.      180 IN  SOA scsnms.switch.ch. dns-operation.switch.ch. 2019051307 900 600 604800 180

          ;; Query time: 17 msec
          ;; SERVER: 192.168.23.1#53(192.168.23.1)
          ;; WHEN: Mon May 13 22:54:02 CEST 2019
          ;; MSG SIZE  rcvd: 102

          Gäbe es eine generische “NXDOMAIN” Antwort, könnte man diese als Angreifer replayen, sprich für jede Anfrage dem Opfer diese Antwort zurücksenden und er würde glabuen, dass es diesen Host nicht gibt. Deshalb wird diese NSEC oder NSEC3 Kette erstellt, welche sagt, welche Hosts existieren. Da diese Kette signiert ist, kann man also beweisen, dass ein Host nicht existiert, wenn man den Host in alphabetischer Reihenfolge vorher und nachher kennt.

          Bei Switch sieht man so z.B. dass der Host foobar.switch.ch nicht existiert (immer noch NXDOMAIN), aber es gibt einen NSEC Record der besagt, dass zwischen dem Host fogo.switch.ch und forano.switch.ch keinen weiteren Host existiert:

          $ dig foobar.switch.ch +dnssec +multiline

          ; <<>> DiG 9.14.1 <<>> foobar.switch.ch +dnssec +multiline
          ;; global options: +cmd
          ;; Got answer:
          ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24338
          ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

          ;; OPT PSEUDOSECTION:
          ; EDNS: version: 0, flags: do; udp: 512
          ;; QUESTION SECTION:
          ;foobar.switch.ch.  IN A

          ;; AUTHORITY SECTION:
          fogo.switch.ch.     180 IN NSEC forano.switch.ch. A AAAA RRSIG NSEC
          fogo.switch.ch.     180 IN RRSIG NSEC 13 3 180 (
                          20190531220120 20190508040551 30131 switch.ch.
                          1HRkyRuANAaCf7Vgzvu8t8FxeEphbEL3N3R//ZL+r4/c
                          3HHnKBhfVqdCKX1vy0aWqaCVVUssDuTf5nspFJnBMw== )
          switch.ch.      180 IN SOA scsnms.switch.ch. dns-operation.switch.ch. (
                          2019051307 ; serial
                          900        ; refresh (15 minutes)
                          600        ; retry (10 minutes)
                          604800     ; expire (1 week)
                          180        ; minimum (3 minutes)
                          )
          switch.ch.      180 IN RRSIG SOA 13 2 86400 (
                          20190530030708 20190513194839 30131 switch.ch.
                          WnD3mQGodR5witedIZ6rCJ+0NQkj33QOvD6Ml4MvOkK9
                          E+5DpepLBmPZxcxyMB2Uoac0xftLDi/zlEqyULNDPQ== )
          switch.ch.      180 IN NSEC 6TO4-RELAY.switch.ch. A NS SOA PTR MX TXT AAAA NAPTR RRSIG NSEC DNSKEY CAA
          switch.ch.      180 IN RRSIG NSEC 13 2 180 (
                          20190531011621 20190513040553 30131 switch.ch.
                          VTthYrx1AsK6ntms+yZ+7jTLl+RSzffBI1s4bCVfVjRn
                          clJ96nR8TVsXOUYo9f6UkuRRjB6nJMTBQ1jVJU0Rzw== )

          ;; Query time: 15 msec
          ;; SERVER: 192.168.23.1#53(192.168.23.1)
          ;; WHEN: Mon May 13 22:55:50 CEST 2019
          ;; MSG SIZE  rcvd: 506

          Dieser NSEC RR ist signiert, damit dieser verifiziert werden kann.

          Diese Verkenntung findet also nicht nur bei NSEC3 sondern auch beim normalen NSEC statt. Ein Angreifer kann dadurch nichts manipulieren.

          Es muss nicht die ganze Liste übermittelt werden, weil es genügt wenn ich den namen vor und nach dem angefragen Host kenne (in alphabetischer Reihenfolge).

          Nochmals. Wenn ich nach dem Host foobar.switch.ch frage, der nicht existiert, kann mir der DNS Server als signierte Antwort sagen: “Es gibt keinen Host zwischen fogo.switch.ch und forano.switch.ch!”. Somit kann der DNS Resolver mit Garantie sagen, dass der Host foobar.switch.ch nicht existiert.

          Da bei NSEC diese Hostnamen aber in Klartext sind, kann man einfach eine Zone enummerieren:

          [...]
          fleves.switch.ch. A AAAA LOC SSHFP RRSIG NSEC·
          floo.switch.ch. A AAAA LOC SSHFP RRSIG NSEC·
          flora.switch.ch. SSHFP RRSIG NSEC·
          fogo.switch.ch. A AAAA RRSIG NSEC·
          forano.switch.ch. SSHFP RRSIG NSEC·
          foreman-eth2.switch.ch. A AAAA LOC RRSIG NSEC·
          foreman-proxy-eth0.switch.ch. A AAAA LOC RRSIG NSEC·
          [...]

          Da dies einem Angreifer je nach dem unnötig viele Informationen preis gibt, wurde mit NSEC3 eine Methode geschaffen, um dies zu erschweren. Dabei werden nur noch Hashes zurückgegeben, die nicht auf gültige DNS Einträge rückschliessen lassen:

          $ dig foobar.nic.ch +dnssec

          ; <<>> DiG 9.14.1 <<>> foobar.nic.ch +dnssec
          ;; global options: +cmd
          ;; Got answer:
          ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17167
          ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

          ;; OPT PSEUDOSECTION:
          ; EDNS: version: 0, flags: do; udp: 512
          ;; QUESTION SECTION:
          ;foobar.nic.ch.         IN  A

          ;; AUTHORITY SECTION:
          ch.         900 IN  SOA a.nic.ch. dns-operation.switch.ch. 2019051323 900 600 1123200 900
          ch.         900 IN  RRSIG   SOA 13 1 900 20190612205457 20190513200149 2668 ch. Dj0THjv7ZXzIK474y4VOAxsbGs/19QWNmQASU2sVJsuF6m66ca8mIq/Z Vltxsdyw7VlpGvx3RLMnvFCajGOfBw==
          ui1m64qfm968njapla3sd1i702jl444c.ch. 900 IN NSEC3 1 1 2 96A895CD UI1UTRA7V0CN5H0O5BJ0C822FOI3KKQF A MX TXT AAAA RRSIG CAA
          ui1m64qfm968njapla3sd1i702jl444c.ch. 900 IN RRSIG NSEC3 13 2 900 20190530083232 20190430080146 2668 ch. lskwcvcHAzz7CR4ofo+Pko6y422/3wmPA8CraiDESR6quwjCm82iIEau kKYVfGyQEN0JZVRH7Nf1HpvNjqjrwA==
          fkcm3evmgalkvc47spmf9d111fgunade.ch. 900 IN NSEC3 1 1 2 96A895CD FKD5FJN5GUF0UF83SU215I9RQHUOJD2D NS DS RRSIG
          fkcm3evmgalkvc47spmf9d111fgunade.ch. 900 IN RRSIG NSEC3 13 2 900 20190530230246 20190430230146 2668 ch. KXxEOPwxxLAnmvANN0+etjfg7zXxuUaEY7hcA8JzgFIH6n/KRhQ+smAm l2hwxFQs3aZ3RvIAsW5t1M14O3NSKw==
          1kuo2tq4nik4c4e32laibgaredef2m6s.ch. 900 IN NSEC3 1 1 2 96A895CD 1KVL1O5V5VMTENKS4D5EGJVEMJPR3AJ5 NS DS RRSIG
          1kuo2tq4nik4c4e32laibgaredef2m6s.ch. 900 IN RRSIG NSEC3 13 2 900 20190610213355 20190511210146 2668 ch. xQecC0P+nQb4mIUYhdGPbzbWau0WjM+uuxnuGrgz3mPdkLHIizIpVQX3 byfOohYJKOMWxw5T7NQRILdjPVoxxQ==

          ;; Query time: 14 msec
          ;; SERVER: 192.168.23.1#53(192.168.23.1)
          ;; WHEN: Mon May 13 23:06:56 CEST 2019
          ;; MSG SIZE  rcvd: 745

          Um dort an die Hostnamen zu kommen, müsste man diese cracken. Hashcat bietet beispielsweise auch NSEC3 als Algorithmus an: https://hashcat.net/wiki/doku.php?id=example_hashes → NSEC3.

          Hier findest du übrigens ein super Tool um DNSSEC zu visualisieren: http://dnsviz.net/d/icann.org/dnssec/

          Reply
  4. Danke für deine Antwort. 🙂

    Zum Thema NSEC3 und NXDOMAIN:

    Ich war so der festen Ueberzeugung, das Nxdomain soviel heisst wie “Zone nicht gefunden”, dass ich mir nochmals den Wikipedia Artikel durchlas (https://de.wikipedia.org/wiki/Zonendatei):

    “Ein Syntax-Fehler führt meist dazu, dass die gesamte Zonendatei als unbrauchbar angesehen wird. Der Nameserver verhält sich dann ähnlich, als wäre diese Zone gar nicht vorhanden. Auf DNS-Anfragen reagiert er mit einer SERVFAIL-Fehlermeldung (wenn die Zone tatsächlich nicht vorhanden ist, reagiert er mit NXDOMAIN).

    Verstehe ich das jetzt falsch? Irrst vielleicht du dich? Interpretiere ich das falsch?

    Zu meiner grösseren Baustelle NSEC/NSEC3 :-):

    Also durch NSEC3 werden u.a Replay-Angriff verhindert, indem man dem Client sagt, es gibt den entsprechenden “A-Record für foobar.switch.ch” nicht, jedoch nach dem Alphabet ist das nächstfolgende Label “foogo”.switch.ch. Also kann ein Resolver überprüfen, ob das Alphabet eingehalten wird und niemand etwas dazwischenschiebt?

    Die RRSIG-Signatur schützt demfall nicht vor Replay angriffe, deswegen gibts u.a also den NSEC?

    Dein Beispiel ist ziemlich verständlich, trotzdem verstehe ich nicht, den Zweck eines Replay-Angriffs: Was bringt ein Replay-Angriff auf einen Hostname welchen es nicht gibt? Was sollte das Ziel davon sein? Nur um die Kommunikation zu stören? Die Integrität der Antwort ist ja durch die RRSIG garantiert. Wie also soll da die Antwort auf dem Transport-Weg geändert werden.

    Wozu muss ich beim NSEC angeben werden, welche Typen ein gewisses Label hat. In deinem Beispiel vom Label “fogo”.switch.ch (A AAAA RRSIG NSEC). Sind nur diese Records durch Replay-angriffe geschützt? Ist es normal, dass die NSEC-Kette unvollständig ist in dem Beispiel? Es zeigt nur von fogo NSEC forano und danach weiter unten von switch.ch. NSEC 6TO4-RELAY.switch.ch.

    Bezüglich Thema Zone Walking:

    Wie hast du diese Liste bekommen …fleves.switch.ch. A AAAA LOC SSHFP RRSIG NSEC·….? NSEC3 generiert doch nur die Hashes beim Record-Typen NSEC3. Alle anderen Record-Typen wie z. B “A,CNAME,NS” kann ich weiterhin einsehen und verwenden um einen Angriffen durchzuführen… Daher verstehe ich nicht den Sinn im “verstecken” (durch Hashes) dieser NSEC-Records.

    Danke für die Verweise zu Hashcat, mein Ziel ist es jedoch nicht zu hacken oder cracken… 🙂 Sind das also eine Art Rainbow Tables dieses Hashcat wenn ich das nicht falsch verstehe.

    Reply
    • Hey Nicolas

      Bitte 🙂

      Du erhälst NXDOMAIN wenn eine Zone gar nicht existiert:

      $ dig diesezonegibtesnicht.com

      ; <<>> DiG 9.14.1 <<>> diesezonegibtesnicht.com
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 125
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 512
      ;; QUESTION SECTION:
      ;diesezonegibtesnicht.com.  IN  A

      ;; AUTHORITY SECTION:
      com.            900 IN  SOA a.gtld-servers.net. nstld.verisign-grs.com. 1558903715 1800 900 604800 86400

      ;; Query time: 22 msec
      ;; SERVER: 192.168.23.1#53(192.168.23.1)
      ;; WHEN: Sun May 26 22:49:07 CEST 2019
      ;; MSG SIZE  rcvd: 126

      Jedoch auch wenn es den Host nicht gibt (die Zone switch.ch gibt es jedoch, dies ist auch am SOA Record zu sehen):

      $ dig dieserhostgibtesnicht.switch.ch

      ; <<>> DiG 9.14.1 <<>> dieserhostgibtesnicht.switch.ch
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55857
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags:; udp: 512
      ;; QUESTION SECTION:
      ;dieserhostgibtesnicht.switch.ch. IN    A

      ;; AUTHORITY SECTION:
      switch.ch.      180 IN  SOA scsnms.switch.ch. dns-operation.switch.ch. 2019052601 900 600 604800 180

      ;; Query time: 19 msec
      ;; SERVER: 192.168.23.1#53(192.168.23.1)
      ;; WHEN: Sun May 26 22:49:43 CEST 2019
      ;; MSG SIZE  rcvd: 117

      Bzgl. NSEC:

      Der Resolver muss nicht überprüfen, ob die Reihenfolge eingehalten wird, sondern muss anhand der Antwort glauben (und nicht nur glauben sondern dies ist mit den Signaturen auch bewiesen), dass die Reihenfolge eingehalten wird.

      Wenn der Resolver fragt, wie der A Record von c.example.com ist, dann bekommt er als Antwort: “Zwischen a.example.com und m.example.com existiert kein Record.”. Da diese Antwort signiert ist, weiss der Resolver dass es den Host c.example.com nicht gibt (und dass es die zwei hosts a.example.com und m.example.com gibt).

      Beispiel:

      $ dig gugustest.switch.ch +dnssec

      ; <<>> DiG 9.14.1 <<>> gugustest.switch.ch +dnssec
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35670
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

      ;; OPT PSEUDOSECTION:
      ; EDNS: version: 0, flags: do; udp: 512
      ;; QUESTION SECTION:
      ;gugustest.switch.ch.       IN  A

      ;; AUTHORITY SECTION:
      switch.ch.      180 IN  SOA scsnms.switch.ch. dns-operation.switch.ch. 2019052601 900 600 604800 180
      switch.ch.      180 IN  RRSIG   SOA 13 2 86400 20190611151653 20190526120554 30131 switch.ch. 6yjT9ho6Xb3eUCc3wkYRw+lilq65fcIaLOORB5DZNhy/YkHunowfknOG yNCsQvSr7ZMVP4rG4TDRM6/2yos0Yg==
      switch.ch.      180 IN  NSEC    6TO4-RELAY.switch.ch. A NS SOA PTR MX TXT AAAA NAPTR RRSIG NSEC DNSKEY CAA
      switch.ch.      180 IN  RRSIG   NSEC 13 2 180 20190614084711 20190520040552 30131 switch.ch. bZGZxuTnULmawmFR50yoyji4qAIRFoKGOxGu4pq54aJqjS+od8UmW4sI qsblPc5ZFQ2hz2rh4q3TE7MmOriVKA==
      groovy.switch.ch.   180 IN  NSEC    guinan.switch.ch. A AAAA LOC SSHFP RRSIG NSEC
      groovy.switch.ch.   180 IN  RRSIG   NSEC 13 3 180 20190615092316 20190523084255 30131 switch.ch. QdgFj/7ciyiWHB9rNRP502qPnXEnnrpZ1UdmkYnxHGkYq/LNrzS96eXP R5Hbifp22Z3SKE5iNsMyCNsDQRuiog==

      ;; Query time: 17 msec
      ;; SERVER: 192.168.23.1#53(192.168.23.1)
      ;; WHEN: Sun May 26 23:17:35 CEST 2019
      ;; MSG SIZE  rcvd: 511

      Ich fragte ob “gugustest.switch.ch” existiert. Als Antwort (in der 5. Zeile der Authority Section) erhalte ich, dass zwischen dem Hostname groovy.switch.ch. und guinan.switch.ch. keine weiteren Hosts existieren.

      Wenn es nur eine Antwort geben würde für “Dieser Host existiert nicht”, kann der Resolver nicht wissen, ob diese Antwort wirklich vom angefragten Nameserver stammt, oder ob diese Antwort von einem Angreifer stammt.

      Das Ziel von solch einem Angriff könnte sein, dass der Angreifer die Verfügbarkeit eines Systems beeinträchtigen will. Angenommen du willst auf webmail.example.com zugreifen, und der Angreifer jubelt dir eine falsche Meldung unter, dass es diesen Host gar nicht gibt. Dann kannst du nicht auf dein Webmail zugreifen.

      Die Liste habe ich erhalten, weil switch.ch nur NSEC und kein NSEC3 verwendet. Deshalb kann man direkt alle Hostnamen rauslesen. Dies sollte einfach als Beispiel dienen. Die Domain ietf.org macht das Beispielsweise auch so. Mit NSEC3 wäre dies so nicht direkt möglich.

      Reply
      • Heey Emanuel,

        Ach ok verstehe, also NXDOMAIN kann auch soviel heissen wie Domain (Zone) meinetld.ch gibts. Jedoch dessen Host matrix.meinetld.ch nicht… und da der Host matrix nicht existiert gibts dazu auch keinen passenden A-Record. 🙂

        NSEC/3:

        Also kann bestätigt werden kann das es einen Hostnamen nicht gibt, indem zurückgegeben wird, welches vom angefragten Label das nächste und vorherige ist. Dadurch kann geprüft werden ob es den angefrangten Host auch wirklich nicht gibt und nicht etwa verfälscht wurde, indem man einfach sagt “NXDOMAIN” für einen Host den es eigentlich geben würde? Das macht Sinn und hört sich logisch an. 🙂

        Wozu werden beim NSEC die ganzen Resourcen Records noch hinzugefügt, was soll das bringen? Im Beispiel von gugustest.switch.ch: “A AAAA LOC SSHFP RRSIG NSE”. Soll damit einfach nur dem anfragenden Client mitgeteilt werden, dass diese beiden Labels groovy.switch.ch und guinan.switch.ch die genannten Resourcen Records benutzten? Also die Subdomain gugustest.switch.ch besitzt anderweitig noch die Records: A,AAAA,LOC…? Verhindert man dem Angreifer so, dass die Records manipuliert werden können?

        Du hast demfall die Zone (switch.ch) enumeriert indem du einfach alles durchgegangen bist. Also als Beispiel: dig +dnssec abakus.switch.ch / liefert die nächstfolgende Einträge als NSEC. Dieses nächste Label hast du dann für weitere Anfragen verwendet bis du alle Einträge mit dem Label “f”.switch.ch hast? Fa.switch.ch, Fb.switch.ch, Fc.switch.ch etc.?

        Reply
        • Bzgl:

          $ dig gugustest.switch.ch +dnssec | grep guinan
          groovy.switch.ch.   94  IN  NSEC    guinan.switch.ch. A AAAA LOC SSHFP RRSIG NSEC

          Damit wird eine Liste aller Typen für dieses Label mitgegeben:

          $ for i in A AAAA LOC SSHFP RRSIG NSEC; do echo "Typ: $i"; dig groovy.switch.ch. $i +noall +short; done
          Typ: A
          130.59.117.92
          Typ: AAAA
          2001:620:0:1005:21a:4aff:fede:ee18
          Typ: LOC
          47 22 39.000 N 8 32 47.000 E 434.00m 1m 10000m 10m
          Typ: SSHFP
          1 2 E3B8CEA965BCB8181C9CD02DAC985B08FD168C54AAE8DA41BA740665 5375AED7
          3 2 DED1906DA65A42D39C9BD85F87A88E949F211BBA44D3FB03EF835961 5AEDF771
          3 1 652368AE42014343B4D60BFF116169E14B3D8C2C
          1 1 C8CEA47E6C967CFD724050EBB77EE7BED24A1C22
          Typ: RRSIG
          SSHFP 13 3 86400 20190706162239 20190609040539 33964 switch.ch. JtNDnpp89tf/cacAASMw+n0BncHm1IPUh/n235jxuGCoxSHt/zjiYnGC 0PMqtYMyC6Pg31D2kU5wFmWNgJLb9g==
          LOC 13 3 86400 20190630041121 20190607120538 33964 switch.ch. tjyB+HzlZDLzt9vLf4ez4alRtW+v++WKeiGvCwcpHa5Ge5giAYG5HMYv fIRkukYTOtpkkXR1y2Wpri4fisX4IA==
          AAAA 13 3 86400 20190627234232 20190603030548 33964 switch.ch. MjYXDxMc5rhpzyvQQVV4Uclb/QFo34X19PgXGA2cAGiy9Mtf8PZeSYln qwbsNjRfFbAGJp16hYuKjiZ9sYTr3w==
          A 13 3 86400 20190701044640 20190601120539 33964 switch.ch. SlXTJdZpAM/yDTovMzbZ3Z1SPQQyY5XmWsU8ry+RLJmMER1shxsnolNO 18l5PFNpeDv0XhGOvND4nVbBS+tmTw==
          NSEC 13 3 180 20190701195811 20190604040539 33964 switch.ch. teoOL9WVz0J/ej8eNoN9G/T1kNQXPew4OnrXuJwRCvXue4GX1hHH8901 1dK476ZwuYDfVjdjrs6LfCIq3cfqBQ==
          Typ: NSEC
          guinan.switch.ch. A AAAA LOC SSHFP RRSIG NSEC

          Somit sieht man auch, wenn ein bestimmter RR Typ nicht existiert:

          $ dig groovy.switch.ch. NS +dnssec

          ; <<>> DiG 9.14.2 <<>> groovy.switch.ch. NS +dnssec
          ;; global options: +cmd
          ;; Got answer:
          ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20441
          ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

          ;; OPT PSEUDOSECTION:
          ; EDNS: version: 0, flags: do; udp: 4096
          ;; QUESTION SECTION:
          ;groovy.switch.ch.      IN  NS

          ;; AUTHORITY SECTION:
          groovy.switch.ch.   180 IN  RRSIG   NSEC 13 3 180 20190701195811 20190604040539 33964 switch.ch. teoOL9WVz0J/ej8eNoN9G/T1kNQXPew4OnrXuJwRCvXue4GX1hHH8901 1dK476ZwuYDfVjdjrs6LfCIq3cfqBQ==
          groovy.switch.ch.   180 IN  NSEC    guinan.switch.ch. A AAAA LOC SSHFP RRSIG NSEC
          switch.ch.      180 IN  SOA scsnms.switch.ch. dns-operation.switch.ch. 2019060901 900 600 604800 180
          switch.ch.      180 IN  RRSIG   SOA 13 2 86400 20190707193503 20190609120538 33964 switch.ch. w5v2+PxglvvGwmGSDYNEXH2sUKYZqY6gNnG6c7EmZRDAnE2L4LFK8j0t L7oNRrssSjTu58ckCy294OZL6ZaoTQ==

          ;; Query time: 40 msec
          ;; SERVER: 46.182.19.48#53(46.182.19.48)
          ;; WHEN: Sun Jun 09 15:17:57 CEST 2019
          ;; MSG SIZE  rcvd: 350

          Dann weiss der Resolver, dass der NS RR nicht existiert, jedoch andere Typen.

          Das kann man entweder manuell mit dig machen und dann jeweils der nächst gültige und irgend ein Postfix anhängen:

          aaaaa.switch.ch -> NSEC _sip._udp.switch.ch. / aai.switch.ch.
          aaia.switch.ch -> NSC aai-viewer.switch.ch. / abelia.switch.ch.
          abeliaaaa.switch.ch. -> NSEC abelia-nfs.switch.ch. / absynthe.switch.ch.

          Und so weiter…

          Aber es gibt natürlich auch Tools dazu, die das automatisieren:

          $ ldns-walk switch.ch | tee switch.ch.out
          switch.ch.  switch.ch. A NS SOA PTR MX TXT AAAA NAPTR RRSIG NSEC DNSKEY CAA
          6TO4-RELAY.switch.ch. A TXT RRSIG NSEC
          6VS.switch.ch. CNAME RRSIG NSEC
          zendesk1._domainkey.switch.ch. CNAME RRSIG NSEC
          zendesk2._domainkey.switch.ch. CNAME RRSIG NSEC
          _netblock1.switch.ch. TXT RRSIG NSEC
          _netblock2.switch.ch. TXT RRSIG NSEC
          _netblock3.switch.ch. TXT RRSIG NSEC
          _netblock4.switch.ch. TXT RRSIG NSEC
          _autodiscover._tcp.switch.ch. SRV RRSIG NSEC
          _cisco-uds._tcp.switch.ch. SRV RRSIG NSEC
          _sip._tcp.switch.ch. SRV RRSIG NSEC
          _sips._tcp.switch.ch. SRV RRSIG NSEC
          _sip._udp.switch.ch. SRV RRSIG NSEC
          webdav-demo.aai.switch.ch. CNAME RRSIG NSEC
          aai-demo.switch.ch. CNAME RRSIG NSEC
          aai-demo-idp.switch.ch. CNAME RRSIG NSEC
          aai-dev.switch.ch. CNAME RRSIG NSEC
          [...]

          Das gibt dann 6452 Einträge:

          $ wc -l switch.ch.out
          6452 switch.ch.out
          Reply
  5. Hallo

    Mir kam da noch eine zusätzliche Frage in den Sinn und zwar suchte ich erstmals im Internet und Google books nach Infos fand jedoch nicht die passende Antwort auf meine Frage.

    Könntest du mir bitte noch das Prinzip vom SEP (Secure Entry Point) erklären? Was ich gefunden habe ist folgendes: SEP dient dazu, dass nur der DNSKEY der Root (.ch / .de ) propagiert werden muss um zu verhindern das mehrere Tausende von DNSKEYs den Resolvern bekannt gegeben werden müssen.

    Was ich nicht verstehe:

    – Was ist dieses SEP, ein Code? Ein Schlüssel wie der DNSKEY? Leider konnte ich diese Info nicht finden.
    – Wo befindet sich dieser SEP nur auf der Root (.ch)? Wenn ich mich nicht täusche, kann auch meine Zone z. B example.org ein SEP haben.

    Schönen Tag noch. 🙂

    Reply
    • Hey zum zweiten 🙂

      Von SEP habe ich zuvor noch nie gehört. Ich verstehe das RFC (https://www.ietf.org/rfc/rfc3757.txt) aber so, dass dieses Bit dazu gedacht ist, anzugeben, welcher Key für eine unterliegende Zone zuständig ist.

      Aus dem RFC:

         With the definition of the Delegation Signer Resource Record (DS RR)
         [5], it has become important to differentiate between the keys in the
         DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
         other keys in the DNSKEY RR set.  We refer to these public keys as
         Secure Entry Point (SEP) keys.  A SEP key either used to generate a
         DS RR or is distributed to resolvers that use the key as the root of
         a trusted subtree [3].

      [...]
         It should be noted that division of keys pairs into KSK's and ZSK's
         is not mandatory in any definition of DNSSEC, not even with the
         introduction of the DS RR.  But, in testing, this distinction has
         been helpful when designing key roll over (key super-cession)
         schemes.  Given that the distinction has proven helpful, the labels
         KSK and ZSK have begun to stick.

         There is a need to differentiate the public keys for the key pairs
         that are used for key signing from keys that are not used key signing
         (KSKs vs ZSKs).  This need is driven by knowing which DNSKEYs are to
         be sent for generating DS RRs, which DNSKEYs are to be distributed to
         resolvers, and which keys are fed to the signer application at the
         appropriate time.

      Das heisst übersetzt:

      – Laut Standard muss man nicht zwingend für KSKs und ZSKs unterschiedliche Keys verwenden.
      – Um zu unterscheiden, welche Keys im DS RR der Parent Zone referenziert werden dürfen, wurde das SEP Bit eingeführt.
      – Das ist also typischerweise der KSK.

      Das sieht man auch in der ch Zone:

      SEP in der CH Zone

      Bei Flags muss das letzte (15. Bit) auf 1 gesetzt sein. Dann wird dieser Key von der überliegenden Zone im DS Record verwiesen.

      Reply
      • Heey 🙂

        Also kann ich in meiner Zone selber entscheiden anhand des SEPs, ob der DS-RR von meinem öffentlichen KSK-Schlüssel referenziert wird in der überliegenden Zone oder jener der Root? Wenn ich in meiner eigenen Zone den public-Key der Root referenziere, wird dem Resolver nur der public key der Root propagiert um meine Zone zu verifizieren und sollte ich mich dafür entscheiden, meinen eigenen öffentlichen Zonenschlüssel (public Key) zu verwenden werden die Resolver auch meinen öffentlichen Zonenschlüssel kennen lernen müssen? Das bestimme ich also mit dem SEP?

        Vermutlich ist ersteres viel sinnvoller Wahl, da ja sonst die Resolver meherere Millionen von öffentlichen Schlüssen kennen lernen müssten…

        Reply
  6. Ich verstehe ehrlich gesagt nicht was du meinst.

    In deiner Zone musst du nichts von der Root Zone referenzieren. Lediglich die überliegende Zone mus ein DS Record erstellen, welcher ein Hash deines KSKs erhält. So entsteht die Kette:

    – Root Nameserver enthält DS Record für die Zone .ch. Das ist ein Hash des KSK von der .ch Zone.
    – .CH Nameserver enthält DS Record für die Zone switch.ch. Das ist ein Hash des KSK von der switch.ch Zone.
    – Und so weiter.

    Hier gibt es ein cooles online Tool um dies zu visualisieren: http://dnsviz.net/d/switch.ch/dnssec/.

    Reply
    • Ich war in den Ferien und hatte wenig Zeit zum Antworten sorry für die späte Antwort. 🙂

      Das habe ich verstanden. Meine Frage bezog sich mehr auf den SEP. Man kann ja entweder nur den DNSKEY der Root an die Resolver propagieren oder eben jeden einzelnen DNSKEY jeder Zone also ., .ch, .switch.ch. etc. Da es wenig Sinn macht den DNSKEY jeder einzelnen Zone zu propagieren setzt man ja den SEP ein, sodass nur noch der DNSKEY der Root propagiert wird. Meine Frage bezog sich mehr darauf, vorallem wie das konfiguriert. Wie es funktioniert und was eingestellt werden muss in meiner eigenen Zone würde mich interessieren. Aber du kennst SEP eher weniger oder?

      Sagt das SEP Bit in meiner eigenen Zone nur aus, dass der DNSKEY der Root verwendet werden soll mehr nicht? Wird da mehr nicht ausgetauscht?

      Reply
  7. Hoi Nicolas

    Bei einem Resolver müssen die Keys der Root Zone hinterlegt sein. Dies passiert mit der Installtion des Resolvers. Die Keys der weiteren Zonen kann dann über die DS Records heruntergeladen und anhand dessen Signatur mit der Keys der Root Zonen verifiziert werden.

    Wenn du eine Zone signieren willst, erstellst du zwei Keys: den Key Signing Key (KSK) und den Zone Signing Key (ZSK). So generierst du z.B. diese Schlüsselpaare für example.net. Den Hash des KSKs legst gibst du den DNS Administratoren von der Domain .net. Diese packen diesen Hash in den DS Record auf der .net Zone. Diese Schritte sind oben im Blogbeitrag so beschrieben. Du kannst auch einen CDS Record in der Zone example.net publizieren und wenn die .net Zone das untersützt, werden die so einen DS Record anlegen.

    Ein DS Record in der Zone example.net darf nur auf einen DNSKEY zeigen, welcher das SEP Bit gesetzt hat. Mit den Keys aus der Root Zone hat das nichts zutun und es wird mit der Root Zone auch nichts ausgetauscht. Nur zwischen dir und der darüberliegenden Zone.

    Also kurz gesagt:

    – Du generierst ein ZSK und ein KSK. Der KSK hat das SEP Bit gesetzt.
    – Mit dem KSK signierst du den ZSK.
    – Mit dem ZSK signierst du deine Zone.
    – Du machst ein Hash vom KSK und gibst der der darüberliegenden Zone (z.B. via ein Webformular oder bequemer via CDS)
    – Danach erstellt der Admin in der darüberliegenden Zone ein DS Record mit dem Hash vom KSK
    – Jetzt ist alles fertig. Die Resolver können jetzt die DNS Antworten korrekt validieren, da sie die Root Keys hinterlegt haben und über die DS Records immer an die KSKs der darunterliegenden Zonen kommen.

    Beste Grüsse,
    Emanuel

    Reply
  8. Hallo Emanuel

    Erster Absatz:
    So ganz kann ich mir das nicht vorstellen. Welche weiteren Zonen ich über den DS-Record herunterladen kann und wie ich die Signatur davon prüfe. Eventuell fehlt es mir auch nur an praktischer Erfahrung… Logisch und verständlich ist natürlich, dass mein eigener Resolver die Root-Zonen und Keys kennen muss!

    Zweiter Absatz:
    Das mit dem CDS kannte ich bisher gar nicht. Laut Wikipedia ist es ein “Child” Delegations Signer, wozu dient dieser. Ich verstehe nicht ganz wieso von einem DS noch ein Child davon existieren kann / muss.

    Das SEP bit dient ja dazu dem Resolver zu sagen ob der DNSKEY von der Root-Zone benutzt werden soll um den DNSKEY von example.org zu validieren oder eben sollte kein SEP Bit gesetzt sein, muss jeder weltweit genutzt Resolver eine Menge mehr an DNSKEYs kennen statt nur jene der Root-Ebene. Das steuert man ja via SEP Bit, ist es gesetzt wird via der Root-Zone den DNSKEY ermittelt wenn das SEP Bit nicht gesetzt ist muss der DNS-Server seine Zone weltweit allen Resolver propagieren was eine Menge mehr an traffic macht… Das habe ich schon richtig verstanden oder? Das war ja noch meine Frage…

    Reply
    • CDS: Statt dass du dem Provider den DS Record über eine Webseite zur Verfügung stellst, schreibst du es in deine DNS Zone. So kann man automatisiert DS Records verteilen.

      Das SEP Bit hat nichts mit der Root Zone zutun. Das SEP Bit ist beim KSK gesetzt und sagt dass dieser Key für die jeweilige Zone signieren darf (z. B. einen ZSK). Sonst ist es so, wie du unten geschrieben hast.

      Reply
  9. Ich habe da noch bei Google Books interessantes zum Thema SEP gefunden:

    https://books.google.ch/books?id=osrpBQAAQBAJ&pg=PA194&lpg=PA194&dq=secure+entry+point&source=bl&ots=aVHmmB9UY6&sig=ACfU3U2KrNIubv2x8xVNQr0awLVZ0cV5tA&hl=de&sa=X&ved=2ahUKEwjB7pzI2ZbkAhWnk4sKHavYBPQQ6AEwCXoECAkQAQ#v=onepage&q=secure%20entry%20point&f=false
    Ab Seite 193.

    Leider irritiert mich das nochmehr. Bei Wikipedia steht der der folgende Satz:

    Die Grundidee ist, alle beteiligten Zonen zu verketten und nur noch die oberste als Secure Entry Point zu verwenden. Nur für diese eine Zone ist die Propagierung des öffentlichen Keys erforderlich.
    https://de.wikipedia.org/wiki/DS_Resource_Record#Hintergrund / Die beiden letzten Sätze vom Hintergrund.

    Nun bei Google Books auf Seite 194 beim ersten Satz steht geschrieben, dass der SEP als KSK fungiert und dazu dient validationen durchzuführen. Irgendwie habe ich jetzt immer mehr ein durcheinander mit DS, SEP, DNSKEY etc…
    Dabei ist mit folgendes eigentlich klar:
    DS = Delegations Signer welcher in der übergeordneten Zone (.ch) als Hash Wert abgespeichert wird. Der DS besteht auf einem Hash-Wert vom DNSKEY dessen KSK ist.
    SEP = Wird eingesetzt damit nur der DNSKEY (KSK) den Resolvern propagiert werden muss.
    DNSKEY: öffentlicher Schlüssel bei einem KSK und ZKS

    Gruss
    Nicolas

    Reply

Leave a Reply to Emanuel Duss Cancel reply