DNSSEC Workshop @ DE-CIX MeetingCenter (eco)

• Einzelner CSK
  • ECDSAP256SHA256 (Algo 13) mit unbegrenzter Lebensdauer
  • RRSIG Gültigkeit 14 Tage, aufgefrischt 5 Tage vor Ablauf
• NSEC
• Schlüssel-Timings:
  • DNSKEY TTL: 3600, maximale Zonen-TTL: 86400 (1 Tag)
  • Sicherheitszeiten für die Veröffentlichung und das Zurückziehen von Schlüsseln: 3600 (1 Stunde)
  • Ausbreitungsverzögerung: 300 (5 Minuten)
• Zeitvorgaben für die Eltern-Zone
  • DS TTL: 86400 (1 Tag)
  • Ausbreitungsverzögerung: 3600 (1 Stunde)

• Durch die Verwendung einer explizit definierten DNSSEC-Richtlinie anstelle der default Richtlinie verhindert die ungewollte Änderung nach Updates der BIND 9 Software

    dnssec-policy "mypolicy" {
   	  keys {
            ksk lifetime 365d algorithm rsasha256 2560;   // nur Beispiele der Syntax
            zsk lifetime 60d  algorithm rsasha256 1536;   // nicht in Produktion
            csk lifetime P6MT12H3M15S algorithm 13;       // verwenden!
	    };
    };

    zone "example.net" {
	      dnssec-policy "mypolicy";
        [...]
    };

• keys gibt Rollen anstelle von bestimmten Schlüsseln an
• lifetime gibt die Dauer oder unbegrenzt an
• algorithm verwendet Mnemonik oder Zahl

    dnssec-policy "one" {
    	keys {
            ksk lifetime 365d algorithm rsasha256 4096;
            zsk lifetime 60d  algorithm rsasha256 1024;
	    };
	    dnskey-ttl 600;
	    publish-safety PT2H;
	    signatures-refresh 7d;

	    nsec3param iterations 0 optout no salt-length 0;
    };

    dnssec-policy <string> {
	    dnskey-ttl <duration>;
	    keys { ( csk | ksk | zsk ) [ ( key-directory ) ]
            lifetime <duration_or_unlimited> algorithm <string> [ <integer> ]; ...
	    };
	    max-zone-ttl <duration>;
	    nsec3param [ iterations <integer> ] [ optout <boolean> ] [ salt-length <integer> ];
	    parent-ds-ttl <duration>;
	    parent-propagation-delay <duration>;
	    publish-safety <duration>;
	    purge-keys <duration>;
	    retire-safety <duration>;
	    signatures-refresh <duration>;
	    signatures-validity <duration>;
	    signatures-validity-dnskey <duration>;
	    zone-propagation-delay <duration>;
    };

Es gibt mehrere Webseitendienste, die DNS-Administratoren bei der Überprüfung den Zustand eines DNS-Systems helfen

• DNSSEC-Validierungsprobleme werden häufig durch operative Probleme verursacht. (abgelaufene DNSSEC-Signaturen, Inkonsistenzen zwischen DS-Eintrag und DNSKEY KSK etc.)
  • Negative Trust Anchors können verwendet werden, um die DNSSEC-Validierung für fehlerhaft konfigurierte Domains zu deaktivieren
• Negative Trust Anchors sind in RFC 7646 ("Definition and Use von DNSSEC Negative Trust Anchors") definiert.
• Negative Trust Anchors (nta) deaktivieren die DNSSEC-Validierung für eine Domain für einen bestimmten Zeitraum
  • NTAs können von Betreibern verwendet werden, wenn eine fehlerhafte Konfiguration für eine DNSSEC-signierten Zone entdeckt wird. Es sollte darauf geachtet werden dass die fehlgeschlagene DNSSEC-Validierung tatsächlich von einer Fehlkonfiguration ausgelöst wird und nicht durch einen Angriff
• Domänen mit einem NTA werden so behandelt, als gäbe es keinen Vertrauensanker für diese Domain
• NTAs werden gespeichert und bleiben auch nach einem Neustart von BIND 9 erhalten.
• BIND 9 überprüft die Domäne in regelmäßigen Abständen. Sobald die Domäne wieder erfolgreich DNSSEC validiert wurde, wird die NTA für die Domain entfernt.
• NTAs haben eine begrenzte Lebensdauer (maximal eine Woche) und verfallen automatisch.
• Beispiel: Hinzufügen eines NTA (für 60 Sekunden):

  % rndc nta -l 60 fail01.dnssec.works
  Negative trust anchor added: fail01.dnssec.works/_default, expires 18-Aug-2016 13:52:19.000
  % rndc nta -dump
  fail01.dnssec.works: expired 18-Aug-2016 13:52:19.000
  % ls -l /var/named/_default.nta
  -rw-r--r--. 1 root root 44 Aug 18 13:51 /var/named/_default.nta
  % cat /var/named/_default.nta
  fail01.dnssec.works. regular 20160818115219

• Beispiel: einen NTA entfernen

  % rndc nta -l 86400 fail02.dnssec.works  # add a NTA for 1 day
  Negative trust anchor added: fail02.dnssec.works/_default, expires 19-Aug-2016 13:56:22.000

  % rndc nta -dump
  fail02.dnssec.works: expiry 19-Aug-2016 13:56:22.000

  % rndc nta -r fail02.dnssec.works # remove the NTA
  Negative trust anchor removed: fail02.dnssec.works/_default

  % rndc nta -dump    # NTA is now gone

• Stelle sicher, dass der DNSSEC-validierender Resolver DNSSEC NTA (negative trust anchor) unterstützt.
• Testen Sie die Funktion des negativen Vertrauensankers.
• Dokumentieren Sie, wie ein negativer Vertrauensanker hinzugefügt wird.
• Wenn Ihre Software das automatische Entfernen von NTAs nicht unterstützt, implementieren Sie eine Automatisierung (in Verbindung mit der Überwachung Ihres DNS-Resolvers).
• Implementieren Sie keine automatische Hinzufügung von NTAs, die Aktivierung eines NTAs sollte erst nach menschlicher Überprüfung des DNSSEC-Validierungsproblems erfolgen.
• Lesen Sie den Internet-Entwurf Recommendations for DNSSEC Resolvers Operators

• Die DNSSEC-Validierung benötigt eine korrekt Systemzeit.
  • Die DNSSEC-Signaturen haben Ablauf- und Inception-Zeiten (Beginn der Gültigkeit), welche der DNS-Resolver überprüfen muss.
• Ohne eine korrekte Zeitangabe auf dem DNSSEC-Resolver-Rechner kann die DNSSEC Validierung fehlschlagen.
• Empfehlung: Implementieren Sie eine automatische Zeitsynchronisation für den DNSSEC-Resolver (NTP, PTP)
• Stellen Sie sicher, dass die Zeitsynchronisation nicht von (DNSSEC) abhängig ist (keine zirkulären Abhängigkeiten oder Henne-Ei-Problem).

• Der IETF-Entwurf "DNS error reporting" beschreibt eine Möglichkeit für DNS Resolver-Software, um Fehlerzustände bei der DNS-Namensauflösung an den Betreiber der autoritativen DNS-Zone zu melden.
• Diese Funktion ist vergleichbar mit dem DMARC-Reporting bei E-Mails.
• Die gemeldeten Fehler basieren auf "Extended DNS Errors (EDE, RFC 8914)".
• Die Meldung erfolgt innerhalb des DNS-Protokolls.
  • Der autoritative DNS-Server kann mit einer EDNS-Option die erweiterten Fehlercodes anfordern
  • Der autoritative DNS-Server kann wählen, ob er nur Fehlerzustände oder auch positive Rückmeldungen (bei erfolgreicher Namensauflösung) erhalten möchte.
  • Um einen Fehler zu melden, kodiert der meldende Resolver den Fehlerbericht in den QNAME der Anfrage. Der meldende Resolver bildet diesen QNAME durch Verkettung des _er Labels, den erweiterten Fehlercode, den QTYPE und den QNAME, der zu dem Fehler zum Fehler führte, nochmals das _er Label und die Domain des sendenen DNS-Resolvers
  • Der resultierende Domainname (QNAME) wird für die DNS-Anfrage nach einem NULL-Resource-Record verwendet, welcher den Fehler meldet.
  • Die reporting agent domain unterscheidet sich normalerweise von einer Produktionsdomäne. Die reporting agent domain sollte nicht DNSSEC signiert sein, da nur die Anfragen von Nutzen sind und die Antworten nicht gesichert werden müssen.
  • Der autoritative DNS-Server antwortet mit einer NODATA/NXRRSET Antwort, welche vom Resolver zwischengespeichert wird (die negative TTL dieser Antwort bestimmt das Intervall für Fehlerberichte, da neue Fehlerberichte für den gleichen Fehler werden erst nach Ablauf der TTL gesendet werden können).
• Beispiel (aus dem Entwurf des RFC-Draft-Dokuments):
  • Die Domäne broken.test wird auf einer Reihe von vertrauenswürdigen Servern gehostet. Einer dieser Server bietet eine veraltete Version an. Dieser autoritative Server hat den Schweregrad 1 und einen Reporting Agent konfiguriert: a01.reporting-agent.example.
  • Der Reporting Resolver ist nicht in der Lage, die den Resource-Record für broken.test zu validieren, da der RRSIG-Record eine abgelaufene Signatur enthält.
  • Der meldende Resolver konstruiert den QNAME. _er.7.1.broken.test._er.a01.reporting-agent.example und löst ihn auf. Dieser QNAME zeigt an, dass der erweiterte DNS-Fehler 7 aufgetreten ist aufgetreten ist, als versucht wurde, den Typ 1 (A)-Record broken.test zu validieren.
  • Nachdem diese Anfrage bei einem der autoritativen Server für die Domain (a01.reporting-agent.example), stellt der Empfänger des Berichts (der Betreiber des autoritativen Servers für a01.reporting-agent.example), dass der autoritative Server für die Zone broken.test unter einem abgelaufenen abgelaufenen Signatursatz (Extended Error 7) vom Typ A für den Domänennamen broken.test leidet. Der Melder kann den Betreiber von broken.test kontaktieren, um das Problem zu beheben.
• Draft "DNS error reporting" (Ein Draft ist noch kein Standard und wird es vielleicht nie werden): https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/
• Dieser Entwurf wurde noch nicht in produktive DNS-Server-Software implementiert.