Ich muss einige Domains mit Ländercode-Domain-Endungen registrieren, habe jedoch festgestellt, dass diese TLDs (A) IPv6 oder (B) DNSSEC offiziell nicht unterstützen ... Welche Einschränkungen oder Fallstricke sollte ich aufgrund dessen erwarten?

(A) Keine IPv6-Unterstützung für TLD

Ich weiß, dass dies bedeutet, dass ich der Domain keinen AAAA-Eintrag hinzufügen kann. Was bedeutet dies für die Erreichbarkeit / Kompatibilität / Sichtbarkeit von anderen IPv6-fähigen DNS-Servern?

(B) Keine DNSSEC-Unterstützung für TLD

Ich verstehe, dass DNSSEC für die Authentifizierung der DNS-Auflösung irgendwie wichtig ist, habe aber keine Ahnung, ob / wie sich die Implementierung (oder das Fehlen davon) auf mich als Anwendungsentwickler in Bezug auf die Sicherheit auswirkt.

HINWEIS: Bitte verzeihen Sie diese möglicherweise rudimentäre Frage eines verwöhnten LAMP-, MEAN-, Front-End- und nativen mobilen Entwicklers, der selten Entscheidungen zur Netzwerkarchitektur treffen musste, die sich um die oben genannten Punkte drehen. Danke im Voraus!

Wenn die ccTLD keine IPv6-Adressen für ihre Nameserver hat, kann ein Nur-IPv6-Benutzer möglicherweise keine Namen unter dieser TLD auflösen , selbst wenn sich diese Namen in IPv6-kompetenten Zonen befinden. Das Auflösen folgt einer Kette von der Wurzel abwärts, und wenn ein Link nicht funktioniert, schlägt das Ganze fehl.

DNSSEC bietet eine kryptografische Authentifizierung von DNS-Daten. Wie alles in DNS folgt es dem normalen Baum, der in der Stammzone beginnt. Und wieder, wenn ein Glied nicht funktioniert, fällt die gesamte Kette aus. Daher sind alle Namen unter einer ccTLD, die DNSSEC nicht ausführen, anfällig für Spoofing (Hinweis: In diesem Fall gibt es eine Technik zum Umgehen der Kette, die als DLV bezeichnet wird. Sie ist jedoch veraltet und die ICANN-Unterstützung dafür endet im Jahr 2017).

Ich würde eine bessere TLD in Betracht ziehen :-)

AAAA-Datensätze können sowohl von IPv4- als auch von IPv6-Resolvern bereitgestellt werden. Sie können Ihrer Domain IPv6-Adressen hinzufügen, die dann zugestellt werden. Personen mit nur IPv6-Resolvern (von denen ich glaube, dass sie relativ selten sind) können Ihre Domain auf keinen Fall auflösen.

Die Standardumgehung für DNSSEC ist die Verwendung von DLV (DNSSEC Lookaside Validation). Dies wurde lange Zeit verwendet und war die einzige Möglichkeit, eine Reihe von TLDs für eine lange Zeit zu validieren. Wenn TLD-Anbieter DNSSEC-Unterstützung hinzufügen, verschwindet die Anforderung DLV für diese TLDs.

Die allgemeine Akzeptanz von IPv6 und DNSSEC war sehr langsam. Wo ich bin, benötige ich immer noch einen IPv4-Tunnel, um IPv6-Konnektivität zu erhalten.

Wenn die TLD keine AAAAEinträge für die Nameserver-Adressen unterstützt, was nicht bedeutet, dass Sie keine AAAAEinträge für Ihre zugrunde liegenden Dienste haben können, bedeutet dies nur, dass Benutzer IPv6 nicht für das DNS-Protokoll selbst verwenden können, um Ihren Dienst nachzuschlagen Adressen.

Es ist eine völlig normale Konfiguration (siehe BCP 91, auch bekannt als RFC 3901 ), nur IPv4-Nameserver in der Domänenregistrierung aufzulisten, wobei diese Nameserver AAAADatensätze für Einträge in Ihrer Domäne veröffentlichen. An diesem Punkt wird nichts kaputt gehen - eine reine IPv6-Verbindung (ohne NAT64) ist so gut wie unbrauchbar.

Für DNSSEC unterstützen die meisten ccTLDs dies bereits, und von denen, die nicht viele planen oder sich bereits in der Mitte der Implementierung befinden, obwohl Afrika das Hauptanliegen ist. Die neueste ISOC-Karte von vor ein paar Tagen zeigt dies:

Ein bescheidener pragmatischer (aber zugegebenermaßen weniger präziser oder dauerhafter) Leitfaden:

Wenn Sie sich in der oben genannten Situation befinden und aus irgendeinem Grund mit den betreffenden TLDs fortfahren MÜSSEN ...

(A) Keine IPv6-Unterstützung für TLD

Ab diesem Beitrag (Januar / 2016) ist IPv4 alles andere als veraltet, sodass die praktischen Auswirkungen auf die allgemeine Auffindbarkeit minimal sein sollten. Aufgrund der Ungenauigkeit dieser Annahme kann es jedoch immer noch Zeiten geben, in denen die Verwendung einer bestimmten TLD aus Gründen des Brandings oder der Erfassung / Übertragung von TLDs in großen Mengen usw. unvermeidbar ist.

1. Besuchen Sie die Root Zone-Datenbank der IANA (eine ICANN-Abteilung) unter http://www.iana.org/domains/root/db und finden Sie offizielle technische und administrative Kontaktdaten für die entsprechende Sponsoring-Organisation der TLD. Wenden Sie sich an diese, um festzustellen, ob / wann IPv6 wird unterstützt.

(B) Keine DNSSEC-Unterstützung für TLD

Da DNSSEC-fähige Resolver digitale Signaturen prüfen, bevor eine Anfrage in einem zusätzlichen Aufwand (ähnlich wie bei SSL) zur Verhinderung von MITM-Angriffen bearbeitet werden kann, ist es nicht ratsam, sie zu übersehen. Wenn Ihre TLD dies derzeit nicht unterstützt ...

1. Eine vorübergehende Problemumgehung ist eine DLS-Implementierung (DNSSEC Lookaside Validation), die sich in diesem Fall auf einem Resolver oder Caching-Server befinden muss, nicht auf einem autorisierenden Nameserver. Wenn Sie jedoch lediglich eine Site oder eine Anwendung hosten, werden Sie wahrscheinlich nicht derjenige sein, der dies zunächst auf dem fraglichen auflösenden Nameserver tut, und wie @ Calle-Dybedahl vorschlägt, geht diese Option zu Ende ~ 2017. (Siehe offiziellen Sonnenuntergangsplan hier: https://singapore52.icann.org/en/schedule/mon-tech/presentation-dlv-decommissioning-09feb15-en.pdf )

Also, ähnlich wie (A) oben ...

2. Besuchen Sie die Root Zone-Datenbank der IANA (eine ICANN-Abteilung) unter http://www.iana.org/domains/root/db und finden Sie offizielle technische und administrative Kontaktdaten für die entsprechende Sponsoring-Organisation der TLD. Wenden Sie sich an diese, um herauszufinden, ob / wann DNSSEC wird unterstützt.

Ich weiß, dass dies bedeutet, dass ich der Domain keinen AAAA-Eintrag hinzufügen kann.

Das ist falsch. Die Inkompetenz der Domänenregistrierung hat keinen Einfluss auf die Datensatztypen, die Sie verwenden können (es sei denn, sie zwingen Sie, ihre Server als maßgebliche Namensgeber zu verwenden. In diesem Fall würde ich vorschlagen, weit wegzulaufen).

Aber was bedeutet dies für die Erreichbarkeit / Kompatibilität / Sichtbarkeit von anderen IPv6-fähigen DNS-Servern?

Wenn die Zone für das tld nicht über IPv6 verfügbar ist, können nur IPv6-Resolver die Domäne nicht auflösen.

Wenn die Zone für das tld über ipv6 verfügbar ist, Sie jedoch keine IPv6-Kleberaufzeichnungen bereitstellen können, werden die Dinge komplexer. Wenn sich Ihr Nameserver unter der betreffenden Domäne befindet, wird ein IPv6-Klebedatensatz benötigt, um nur IPv6-Resolver zu unterstützen. Wenn sich Ihr Nameserver unter einer anderen Domain befindet, werden für Ihre Domain keine Klebedatensätze benötigt (obwohl sie offensichtlich für eine Domain benötigt werden).

Dual-Stack-Resolver sollten in jedem Fall in Ordnung sein. Es besteht die Möglichkeit, dass die meisten DNS-Resolver auf absehbare Zeit IPv4-fähig sind (entweder Dual Stack oder nur v4).

Ich verstehe, dass DNSSEC für die Authentifizierung der DNS-Auflösung irgendwie wichtig ist, habe aber keine Ahnung, ob / wie sich die Implementierung (oder das Fehlen davon) auf mich als Anwendungsentwickler in Bezug auf die Sicherheit auswirkt.

Dnssec soll einen Mechanismus bereitstellen, um zu überprüfen, ob die von Ihnen empfangenen Datensätze echt sind. jedoch

1. Die überwiegende Mehrheit der Systeme erzwingt dies derzeit nicht.
2. Die Überprüfung der Legitimität der Datensätze ist für A- und AAAA-Datensätze keine große Hilfe. Ein Angreifer, der sich mit DNS anlegen kann, kann sich sehr wahrscheinlich auch mit dem IP-Routing anlegen.

DNSSEC mit DANE ist ein potenzieller zukünftiger Ersatz oder eine Ergänzung zum aktuellen CA-System. Das aktuelle CA-System ist aus Sicherheitsgründen sehr fehlerhaft, da Sie effektiv nur so sicher sind wie die schlechteste CA.

Sie sagen nicht, welche Art von Anwendungen Sie entwickeln. Wenn es sich um eine Client-App handelt, die mit einem Server kommuniziert, den Sie besitzen, sollten Sie Ihre Verbindungen mithilfe von tls mit einer privaten Zertifizierungsstelle sichern.

Für Webapps ist das öffentliche CA-System (so beschissen es ist) wirklich die einzige Option. Möglicherweise möchten Sie HKP in Betracht ziehen, um das Risiko von falsch ausgestellten Zertifikaten zu verringern. Ein funktionierendes DNSSEC / DANE würde eine bessere Sicherheit bieten, aber nur für die wenigen Clients, die es tatsächlich unterstützen.

Wenn Sie ein eigenes Protokoll entwerfen, das die Verwendung von Arbitary-Servern ermöglicht, sollten Sie in Betracht ziehen, ein mit hkp gleichwertiges Protokoll aufzunehmen.