Markieren Sie das Kontrollkästchen Englisch, um die englische Version dieses Artikels anzuzeigen. Sie können den englischen Text auch in einem Popup-Fenster einblenden, indem Sie den Mauszeiger über den Text bewegen.
Übersetzung
Englisch

Übersicht über DNSSEC

 

Betrifft: Windows Server 2012 R2, Windows Server 2012

DNSSEC (Domain Name System Security Extensions) ist eine Sammlung von Erweiterungen zur Erhöhung der Sicherheit des DNS-Protokolls durch die Überprüfung von DNS-Antworten. Insbesondere stellt DNSSEC Ursprungsautorität, Datenintegrität und authentifizierte Bestätigung der Abwesenheit bereit. Mit DNSSEC ist das DNS-Protokoll weniger anfällig für bestimmte Angriffsformen, insbesondere DNS-Spoofingangriffe.

Die wichtigsten DNSSEC-Erweiterungen werden in den folgenden RFCs (Request for Comments) erläutert. Zusätzliche RFCs enthalten weitere hilfreiche Informationen.

  • RFC 4033: DNS-Sicherheit – Einführung und Anforderungen

  • RFC 4034: Ressourceneinträge für die DNS-Sicherheitserweiterungen

  • RFC 4035: Protokolländerungen für die DNS-Sicherheitserweiterungen

Wenn dies von einem autorisierenden DNS-Server unterstützt wird, kann eine DNS-Zone mittels eines Prozesses namens Zonensignatur mit DNSSEC gesichert werden. Die Zonensignatur mit DNSSEC fügt einer Zone Überprüfung hinzu, ohne dass der grundlegende Mechanismus von DNS-Abfragen und -Antworten geändert werden muss.

Die Überprüfung von DNS-Antworten erfolgt durch die Verwendung digitaler Signaturen, die in DNS-Antworten enthalten sind. Diese digitalen Signaturen sind in neuen DNSSEC-Ressourceneinträge enthalten, die erzeugt und bei der Zonensignatur zur Zone hinzugefügt werden.

Die folgende Abbildung zeigt die DNS-Ressourceneinträge in der Zone „contoso.com“ vor und nach dem Signieren der Zone.

Zone Signing

Weitere Informationen zu diesen Ressourceneinträgen finden Sie im folgenden Abschnitt DNSSEC-bezogene Ressourceneinträge.

Wenn ein DNSSEC-fähiger, rekursiver oder weiterleitender DNS-Server eine Abfrage für eine DNSSEC-signierte Zone von einem DNS-Client erhält, fordert dieser, dass der autorisierende DNS-Server auch DNSSEC-Einträge sendet, und versucht dann, die DNS-Antwort unter Verwendung dieser Datensätze zu überprüfen. Ein rekursiver oder weiterleitender DNS-Server erkennt, dass die Zone DNSSEC unterstützt, wenn sie über einen DNSKEY (auch Vertrauensanker genannt) für diese Zone verfügt.

System_CAPS_noteHinweis

Ein nicht autorisierender DNS-Server kann Rekursion oder Weiterleitung zum Auflösen einer DNS-Abfrage verwenden. Dieses Thema bezieht sich auf den nicht autoritativen Server als rekursiven DNS-Server. Wenn der Server jedoch Weiterleitung verwendet, ist das Verfahren für die DNSSEC-Überprüfung der DNS-Antworten identisch.

DNSSEC-Überprüfung

Ein rekursiver DNS-Server verwendet den DNSKEY-Ressourcendatensatz zur Überprüfung von Antworten vom autorisierenden DNS-Server, indem er digitale Signaturen entschlüsselt, die in DNSSEC-bezogenen Ressourceneinträgen enthalten sind, und anschließend Hashwerte berechnet und vergleicht. Wenn die Hashwerte identisch sind, stellt er dem DNS-Client eine Antwort mit DNS-Daten bereit, die dieser angefordert hat, wie z. B. einen Hostressourcendatensatz (A). Wenn die Hashwerte nicht übereinstimmen, antwortet er mit einer SERVFAIL-Meldung. Auf diese Weise schützt ein DNSSEC-fähiger, auflösender DNS-Server mit einem installierten gültigen Vertrauensanker unabhängig davon, ob die DNS-Clients DNSSEC-fähig sind oder nicht, vor DNS-Spoofingangriffen.

Darüber hinaus können DNSSEC-fähige DNS-Clients so konfiguriert werden, dass der DNS-Server DNSSEC-Überprüfung erfordert.

In der folgenden Abbildung wird dieser Vorgang dargestellt.

DNSSEC Validation

DNSKEYs werden zum Berechnen von Hashwerten und zum Entschlüsseln von RRSIG-Datensätzen verwendet. Die Abbildung zeigt nicht alle ausgeführten Überprüfungsverfahren. Es werden auch zusätzliche Überprüfungen durchgeführt, um sicherzustellen, dass die DNSKEYs und DS-Datensätze gültig sind, sofern diese vorhanden sind (nicht oben gezeigt).

Weitere Informationen dazu, wie DNSSEC-Daten zum DNS-Abfrage- und -Antwortprozess hinzugefügt werden können, finden Sie im folgenden Abschnitt Überprüfen von DNS-Antworten.

Die folgende Tabelle zeigt die neuen Ressourcendatensatztypen, die mit DNSSEC verwendet werden.

Typ des Ressourcendatensatzes

Beschreibung

Ressourcendatensatzsignatur (RRSIG)

Signaturen, die mit DNSSEC generiert wurden, sind in den RRSIG-Datensätzen enthalten. Jeder RRSIG-Datensatz wird mit einem anderen Datensatz in der Zone verglichen, für den er eine digitale Signatur bereitstellt.

Wenn von einem Resolver eine Abfrage für einen Namen ausgegeben wird, wird in der Antwort mindestens ein RRSIG-Datensatz zurückgegeben.

Next Secure (NSEC)

Ein NSEC-Datensatz wird zum Nachweisen von fehlenden DNS-Namen verwendet. NSEC-Datensätze verhindern Spoofingangriffe, bei denen einem DNS-Client vorgetäuscht wird, dass ein DNS-Name nicht vorhanden ist.

Next Secure 3 (NSEC3)

NSEC3 ist ein Ersatz für oder eine Alternative zu NSEC und weist den zusätzlichen Vorteil auf, dass „Zone Walking“ verhindert wird. Dabei handelt es sich um wiederholte NSEC-Abfragen, um alle Namen in einer Zone abzurufen. Einen DNS-Server mit Windows Server 2012 oder einem neueren Betriebssystem unterstützt NSEC und NSEC3. Eine Zone kann mit NSEC oder NSEC3 signiert werden, jedoch nicht mit beiden.

Next Secure 3-Parameter (NSEC3PARAM)

Der NSEC3PARAM-Datensatz wird verwendet, um festzustellen, welche NSEC3-Datensätze in Antworten auf nicht vorhandene DNS-Namen enthalten sein sollen.

DNS-Schlüssel (DNSKEY)

In einem DNSKEY-Ressourcendatensatz wird ein öffentlicher Kryptografieschlüssel gespeichert, der zum Überprüfen einer Signatur verwendet wird. Der DNSKEY-Datensatz wird im Rahmen der Überprüfung von einem DNS-Server verwendet.

DNSKEY-Datensätze können öffentliche Schlüssel für einen Zonensignaturschlüssel (ZSK) oder einen Schlüsselsignaturschlüssel (KSK) speichern.

Delegierungssignaturgeber (DS)

Ein DS-Datensatz ist ein DNSSEC-Datensatz, der verwendet wird, um eine Delegierung zu sichern. DS-Datensätze werden verwendet, um Authentifizierungsketten mit untergeordneten Zonen zu erstellen.

Zusatz von DNSSEC-bezogenen Ressourceneinträgen

Mit Ausnahme des DS-Datensatzes werden alle diese Datensätze automatisch einer Zone hinzugefügt, wenn diese mit DNSSEC signiert wird. Der DS-Datensatz ist ein spezieller Datensatz, der manuell einer übergeordneten Zone hinzugefügt werden kann, um eine sichere Delegierung für eine untergeordnete Zone zu erstellen. Beispielsweise kann die Zone „contoso.com“ einen DS-Datensatz für „secure.contoso.com“ enthalten. Dieser Datensatz muss jedoch entweder in der übergeordneten Zone oder in einer untergeordneten Zone erstellt und dann an die übergeordnete Zone weitergegeben werden. Der DS-Datensatz wird nicht automatisch erstellt, wenn Sie eine Zone signieren.

NSEC- oder NSEC3-Datensätze werden einer Zone automatisch während der Zonensignatur hinzugefügt. Allerdings kann eine signierte Zone nicht gleichzeitig über NSEC- und NSEC3-Datensätze verfügen. Der hinzugefügte Datensatztyp (NSEC oder NSEC3) hängt von der Konfiguration der Zonensignatur ab. Im vorherigen Beispiel ist die Zone mit NSEC3 signiert.

Vertrauensanker

DNSKEY- und DS-Ressourcendatensätze werden auch Vertrauensanker oder Vertrauenspunkte genannt. Ein Vertrauensanker muss an alle nicht autoritativen DNS-Server verteilt werden, die DNSSEC-Überprüfung der DNS-Antworten für eine signierte Zone ausführen. Wenn der DNS-Server auf einem Domänencontroller ausgeführt wird, werden die Vertrauensanker in der Verzeichnispartition der Gesamtstruktur in Active Directory-Domänendienste (Active Directory Domain Services, AD DS) gespeichert und können auf allen Domänencontrollern in der Gesamtstruktur repliziert werden. Auf eigenständigen DNS-Servern werden die Vertrauensanker in einer Datei namens TrustAnchors.dns gespeichert. Auf einem DNS-Server unter Windows Server 2012 oder einem neueren Betriebssystem werden konfigurierte Vertrauensanker auch in der DNS-Manager-Konsolenstruktur im Container Vertrauenspunkte angezeigt. Sie können auch Windows PowerShell oder „dnscmd.exe“ verwenden, um Vertrauensanker anzuzeigen. (Hinweis: „dnscmd.exe“ ist veraltet und kann in einer zukünftigen Version von Windows Server entfernt werden.)

Im folgenden Beispiel ist das Windows PowerShell-Cmdlet Get-DnsServerTrustAnchor dargestellt.

PS C:\> Get-DnsServerTrustAnchor -Name secure.contoso.com

TrustAnchorName                TrustAnchorType      TrustAnchorState     TrustAnchorData
---------------                ---------------      ----------------     ---------------
secure.contoso.com.            DNSKEY               Valid                [15952][DnsSec][RsaSha256][AwEAAe3JOsLYe17k...
secure.contoso.com.            DNSKEY               Valid                [38431][DnsSec][RsaSha256][AwEAAdsXYyqxjwBc...

Zum Anzeigen der aktuellen Vertrauenspunkte auf einem Server können Sie das Cmdlet Get-DnsServerTrustPoint verwenden.

PS C:\> Get-DnsServerTrustPoint

TrustPointName                           TrustPointState      LastActiveRefreshTime     NextActiveRefreshTime
--------------                           ---------------      ---------------------     ---------------------
secure.contoso.com.                      Active               10/11/2013 4:44:21 PM     10/15/2013 11:22:27 AM

Informationen darüber, wie DNSSEC diese neuen Ressourceneinträge verwendet, um DNS-Antworten zu überprüfen und abzusichern, finden Sie im folgenden Abschnitt.

In der folgenden Abbildung und Tabelle finden Sie eine vereinfachte Darstellung der Integration von DNSSEC in die DNS-Abfrage- und -Antwortprozesse zum Zwecke der Validierung.

Im Beispiel fragt ein DNS-Clientcomputer einen rekursiven (zwischenspeichernden) DNS-Server ab, der wiederum den autorisierenden DNS-Server abfragt, bevor er eine Antwort zurückgibt. In diesem Beispiel wird davon ausgegangen, dass die DNS-Daten auf dem Client oder Server noch nicht zwischengespeichert wurden. Wenn eine Zone mit DNSSEC signiert ist und DNS-Server und -Clients DNSSEC-fähig sind, können DNSSEC-Daten verwendet werden, um sicherzustellen, dass die DNS-Antworten echt sind.

Die folgende Abbildung zeigt den rekursiven DNS-Abfrageprozess.

DNS Query

Die folgende Tabelle zeigt die Schritte in einer DNS-Abfrage und -Antwort mit den optionalen DNSSEC-Daten.

Schritt

Antwort zur Abfrage

Optionale DNSSEC-Daten

1

Ein DNS-Client sendet eine DNS-Abfrage an einen rekursiven DNS-Server.

Der DNS-Client kann angeben, dass er DNSSEC-fähig ist (DO=1).

2

Der rekursive DNS-Server sendet eine DNS-Abfrage an die Stamm-DNS-Server und die DNS-Server in der Domäne der obersten Ebene (TLD).

Der rekursive DNS-Server kann angeben, dass er DNSSEC-fähig ist (DO=1).

3

Die Stamm- und TLD-Server geben eine DNS-Antwort an den rekursiven DNS-Server zurück, in der die IP-Adresse des autorisierenden DNS-Servers für die Zone bereitgestellt wird.

Die autorisierenden Server der übergeordneten Zone können angeben, dass die untergeordnete Zone mit DNSSEC signiert ist und eine sichere Delegierung (DS-Datensatz) enthält.

4

Der rekursive DNS-Server sendet eine DNS-Abfrage an den autorisierenden DNS-Server für die Zone.

Der rekursive DNS-Server kann angeben, dass er DNSSEC-fähig (DO=1) und in der Lage ist, signierte Ressourceneinträge (CD=1) zu überprüfen, die in der Antwort gesendet werden.

5

Der autorisierende DNS-Server gibt eine DNS-Antwort an den rekursiven DNS-Server zurück, in der die Daten des Ressourcendatensatzes bereitgestellt werden.

Der autoritative DNS-Server kann die DNSSEC-Signaturen in Form von RRSIG-Datensätzen in der DNS-Antwort zur Verwendung bei der Validierung enthalten.

6

Der rekursive DNS-Server gibt eine DNS-Antwort an den DNS-Client zurück, in der die Daten des Ressourcendatensatzes bereitgestellt werden.

Der rekursive DNS-Server kann angeben, ob die DNS-Antwort unter Verwendung von DNSSEC überprüft wurde (AD=1).

Einbeziehen von DNSSEC-Daten:

In einer DNS-Abfrage und -Antwort werden die drei in der vorherigen Tabelle aufgeführten und im folgenden Abschnitt beschriebenen wichtigen DNSSEC-bezogenen Flags (Bits) verwendet, um zu bestimmen, ob die DNSSEC-Daten enthalten sind und ob die Überprüfung durchgeführt wurde. Diese Flags werden festgelegt, indem die erweiterten Datenbits im DNS-Paketheader aktiviert oder deaktiviert werden. Wenn diese Flags aktiviert werden, wird dies als Festlegen des Bits bezeichnet, was dem Wert 1 entspricht. Das Deaktivieren eines Flags wird als Löschen des Bits bezeichnet, was einem Wert von 0 entspricht.

  • DO: Das DO-Bit ist in einer DNS-Abfrage enthalten und stellt eine Abkürzung für „DNSSEC OK“ dar. Wenn das DO-Bit festgelegt ist (DO=1), ist der Client DNSSEC-fähig, und der DNS-Server kann DNSSEC-Daten in einer Antwort zurückgeben. Wenn das DO-Bit nicht festgelegt ist (DO=0), ist der Client nicht DNSSEC-fähig, und der DNS-Server darf keine DNSSEC-Daten in einer Antwort zurückgeben. DNS-Clients können auch durch DNSSEC geschützt werden, wenn sie nicht DNSSEC-fähig sind. In diesem Kontext ist ein DNS-Client ein beliebiger Computer, der eine DNS-Abfrage sendet. Wenn ein rekursiver DNS-Server eine Abfrage an den autorisierenden DNS-Server sendet, muss der rekursive DNS-Server angeben, dass er DNSSEC-fähig ist, damit der autorisierende DNS-Server DNSSEC-Daten in der Antwort sendet.

  • AD: Das AD-Bit ist in einer DNS-Antwort enthalten und stellt eine Abkürzung für „authentifizierte Daten“ dar. Wenn das AD-Bit festgelegt ist (AD=1), bedeutet dies, dass die DNS-Antwort authentifiziert ist, da sie unter Verwendung von DNSSEC überprüft wurde. Ein nicht überprüfender DNSSEC-fähiger Computer, wie z. B. ein Computer, auf dem Windows 8 ausgeführt wird, führt keine DNSSEC-Überprüfung durch, kann jedoch so konfiguriert werden, dass authentische DNS-Antworten erforderlich sind. Wenn das AD-Bit nicht festgelegt ist (AD=0), wurde die DNS-Antwort nicht überprüft, da entweder keine Überprüfung versucht wurde oder ein Fehler dabei aufgetreten ist.

  • CD: Das CD-Bit ist in einer DNS-Abfrage enthalten und stellt eine Abkürzung für „Checking Disabled“ (Überprüfung deaktiviert) dar. Wenn das CD-Bit in einer Abfrage festgelegt ist (CD=1), bedeutet dies, dass eine DNS-Antwort gesendet werden soll, unabhängig davon, ob die Überprüfung erfolgreich ausgeführt wurde. Wenn das CD-Bit nicht festgelegt ist (CD=0), wird keine DNS-Antwort gesendet, wenn die Validierung erforderlich war und ein Fehler dabei aufgetreten ist. Wenn das CD-Bit deaktiviert ist (CD=0), bedeutet dies im Wesentlichen, dass die „Überprüfung aktiviert“ ist und eine DNSSEC-Überprüfung ausgeführt werden kann. Das CD-Bit kann in einer Abfrage aktiviert werden (CD=1), da der Host DNSSEC-Überprüfung ausführen kann, wie z. B. bei einem rekursiven DNS-Server mit Windows Server 2012. Ein nicht überprüfender Stubresolver, z. B. ein Computer mit Windows 8, legt immer CD=0 fest.

Ein viertes wichtiges Flag (Bit), das in einem DNS-Paket-Header vorhanden sein kann, ist das AA-Bit. Dieses Flag ist nicht neu bei DNSSEC, aber es kann verwendet werden, wenn DNSSEC bereitgestellt wird:

  • AA: Das AA-Bit ist in einer DNS-Antwort enthalten und stellt eine Abkürzung für „autoritative Antwort“ dar. Wenn das AA-Bit festgelegt ist, bedeutet dies, dass die DNS-Antwort authentisch ist, da sie direkt von einem autorisierenden DNS-Server stammt. Ein Client, der DNSSEC-Überprüfung (AD=1) erfordert, kann alternativ das AA-Bit (AA=1, AD=0) akzeptieren, wenn der Client direkt eine Anfrage an den autoritativen Server sendet, da die autoritativen Antworten nicht auf Gültigkeit überprüft werden müssen. Das Überprüfen der eigenen Antwort eines autorisierenden Servers wäre redundant.

Die folgenden Beispiele zeigen die DNS-Abfrageergebnisse, die von einem ausführenden DNS-Clientcomputer mit Windows 8.1 mit dem Cmdlet Resolve-DnsName durchgeführt werden. Das Cmdlet Resolve-DnsName wurde in Windows Server 2012 und Windows 8 eingeführt und kann zur Anzeige von DNS-Abfragen mit DNSSEC-Daten verwendet werden.

System_CAPS_importantWichtig

Verwenden Sie nicht das Befehlszeilenprogramm nslookup, um die DNSSEC-Unterstützung für eine Zone zu testen. Das Tool nslookup verwendet einen internen DNS-Client, der nicht DNSSEC-fähig ist.

Beispiel 1: Im folgenden Beispiel wird eine Abfrage an einen rekursiven DNS-Server für einen Adressdatensatz (A) in der signierten Zone secure.contoso.com mit DO=0 gesendet.

PS C:\> Resolve-DnsName finance.secure.contoso.com –type A -server dns1.contoso.com

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
finance.secure.contoso.com                     A      2848  Answer     192.168.0.200

In diesem Beispiel wurde das DO-Bit nicht festgelegt, da der dnssecok-Parameter nicht enthalten war.

Beispiel 2: Im folgenden Beispiel wird das Flag „DO=1“ durch Hinzufügen des dnssecok-Parameters festgelegt.

PS C:\> resolve-dnsname -name finance.secure.contoso.com -type A -server dns1.contoso.com -dnssecok

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
finance.secure.contoso.com                     A      2848  Answer     192.168.0.200

Name        : finance.secure.contoso.com
QueryType   : RRSIG
TTL         : 2848
Section     : Answer
TypeCovered : A
Algorithm   : 8
LabelCount  : 4
OriginalTtl : 3600
Expiration  : 10/18/2013 8:23:41 PM
Signed      : 10/8/2013 7:23:41 PM
Signer      : secure.contoso.com
Signature   : {86, 229, 217, 39...}

Name      : .
QueryType : OPT
TTL       : 32768
Section   : Additional
Data      : {}

Wenn DO=0 festgelegt ist, sendet der DNS-Server keine DNSSEC-Daten in der DNS-Antwort. Wenn DO=1 festgelegt ist, gibt der Client an, dass er DNSSEC-Daten empfangen kann, sofern diese verfügbar sind. Da die Zone „secure.contoso.com“ signiert ist, wurde ein RRSIG-Ressourcendatensatz in die DNS-Antwort eingefügt, wenn DO=1 festgelegt ist.

In den Beispielen 1 und 2 ist keine Überprüfung für die Zone „secure.contoso.com“ erforderlich, da die Richtlinientabelle für die Namensauflösung (Name Resolution Policy Table, NRPT) dementsprechend konfiguriert wurde.

Sie können das Cmdlet Get-DnsClientNrptPolicy zum Anzeigen der aktuellen NRPT-Regeln verwenden. Weitere Informationen finden Sie unter Get-DnsClientNrptPolicy.

Beispiel 3: Im folgenden Beispiel wird eine NRPT-Regel für „secure.contoso.com“ angezeigt.

PS C:\> Get-DnsClientNrptPolicy

Namespace                        : .secure.contoso.com
QueryPolicy                      :
SecureNameQueryFallback          :
DirectAccessIPsecCARestriction   :
DirectAccessProxyName            :
DirectAccessDnsServers           :
DirectAccessEnabled              :
DirectAccessProxyType            : NoProxy
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired   : False
NameServers                      :
DnsSecIPsecCARestriction         :
DnsSecQueryIPsecEncryption       :
DnsSecQueryIPsecRequired         : False
DnsSecValidationRequired         : False
NameEncoding                     : Utf8WithoutMapping

In diesem Beispiel wird der Wert für DnsSecValidationRequired auf False festgelegt. Dies bedeutet, dass die DNSSEC-Überprüfung nicht erforderlich ist.

Beispiel 4: Nach Aktivierung der DNSSEC-Überprüfung für „secure.contoso.com“ zeigt die NRPT True für DnsSecValidationRequired an. In diesem Beispiel werden nur der „secure.contoso.com“-Namespace und der DnsSecValidationRequired-Parameter angezeigt.

PS C:\> (Get-DnsClientNrptPolicy -NameSpace secure.contoso.com).DnsSecValidationRequired
True

Wenn der Wert von DnsSecValidationRequired auf True festgelegt ist, senden DNSSEC-fähige Clientcomputer immer Abfragen mit DO=1, selbst wenn der dnssecok-Parameter nicht enthalten ist.

Beispiel 5: Wenn eine DNSSEC-Überprüfung durch die Richtlinientabelle für die Namensauflösung erforderlich ist, wird automatisch das DNSSEC OK-Bit (DO=1) für DNSSEC-fähige Clients festgelegt.

PS C:\> resolve-dnsname -name finance.secure.contoso.com -type A -server dns1.contoso.com

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
finance.secure.contoso.com                     A      2848  Answer     192.168.0.200

Name        : finance.secure.contoso.com
QueryType   : RRSIG
TTL         : 2848
Section     : Answer
TypeCovered : A
Algorithm   : 8
LabelCount  : 4
OriginalTtl : 3600
Expiration  : 10/18/2013 8:23:41 PM
Signed      : 10/8/2013 7:23:41 PM
Signer      : secure.contoso.com
Signature   : {86, 229, 217, 39...}

Name      : .
QueryType : OPT
TTL       : 32768
Section   : Additional
Data      : {}

In diesem Beispiel wird ein RRSIG-Datensatz in der DNS-Antwort gesendet, um die Prüfungsanforderungen für „secure.contoso.com“ zu erfüllen. Für den rekursiven DNS-Server („dns1.contoso.com“) ist auch ein gültiger Vertrauensanker konfiguriert.

Wenn ein DNS-Client nicht DNSSEC-fähig ist, wird die NRPT-Regel nicht angewendet und Abfragen werden mit DO=0 gesendet, selbst wenn eine NRPT-Regel vorhanden ist, die DNSSEC-Überprüfung erforderlich macht.

Beispiel 6: Im folgenden Beispiel wird die gleiche Abfrage wie in Beispiel 5 ausgeführt, ohne dass jedoch ein gültiger Vertrauensanker für „dns1.contoso.com“ konfiguriert wurde.

PS C:\> resolve-dnsname -name finance.secure.contoso.com -type A -server dns1.contoso.com
resolve-dnsname : finance.secure.contoso.com : Unsecured DNS packet
At line:1 char:1
+ resolve-dnsname -name finance.secure.contoso.com -type A -server dns1.contoso.co ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (finance.secure.contoso.com:String) [Resolve-DnsName], Win32Excepti
   on
    + FullyQualifiedErrorId : DNS_ERROR_UNSECURE_PACKET,Microsoft.DnsClient.Commands.ResolveDnsName

In diesem Beispiel schlägt die DNS-Auflösung mit der Meldung DNS_ERROR_UNSECURE_PACKET fehl, da die Überprüfung durch NRPT erforderlich ist. Sie kann jedoch aufgrund eines fehlenden gültigen Vertrauensankers für die Zone „secure.contoso.com“ nicht ausgeführt werden. Das Cmdlet Resolve-DnsName meldet ausführliche Ergebnisse für den aufgetretenen Fehlertyp. Wenn der DNS-Client versucht, „finance.secure.contoso.com“ aufzulösen, um eine Verbindung mit diesem Host herzustellen, um z. B. eine Datei freizugeben, schlägt diese fehl.

Da DNSSEC in vielen unterschiedlichen Umgebungen mit eindeutigen Server- und Clienteinstellungen bereitgestellt werden kann, ist es wichtig, zu verstehen, wie DNS-Abfragen und -Antworten betroffen sind.

Berücksichtigen Sie die folgenden vier DNSSEC-bezogenen Aussagen. Jede Aussage beeinflusst die Funktionsweise von DNSSEC in einem bestimmten Szenario:

  1. Der Ressourcendatensatz „finance.secure.contoso.com“ ist ordnungsgemäß mit DNSSEC signiert.

  2. Ein rekursiver DNS-Server kann Antworten auf eine Abfrage für „finance.secure.contoso.com“ überprüfen.

  3. Ein DNS-Client ist DNSSEC-fähig.

  4. Ein DNS-Client ist so konfiguriert, dass für alle Abfragen im Namespace „secure.contoso.com“ eine Überprüfung erforderlich ist.

Betrachten wir die einzelnen Bedingungen und deren Konsequenzen genauer:

  1. DNSSEC-Signaturstatus: Da DNSSEC alle Datensätze in der Zone signiert, bezieht sich dieser Zustand auf die Zone „secure.contoso.com“ und nicht nur auf den Ressourcendatensatz „finance.secure.contoso.com“. Es ist nicht möglich, einige Datensätze zu signieren und andere Datensätze nicht. Daher hängt der DNSSEC-Status von „finance.secure.contoso.com“ vom DNSSEC-Status von „secure.contoso.com“ ab.

    • Ordnungsgemäß signiert: Die Zone „secure.contoso.com“ kann auf ordnungsgemäße Weise signiert werden, wodurch „finance.secure.contoso.com“ als gültig erklärt werden kann. Um gültig zu sein, muss die Zone mit gültigen, nicht abgelaufenen Schlüsseln signiert werden, und alle erforderlichen DNSSEC-bezogenen Ressourceneinträge müssen vorhanden sein.

    • Nicht signiert: Die Zone „secure.contoso.com“ kann möglicherweise nicht signiert werden. In diesem Fall ist kein RRSIG-Datensatz mit „finance.secure.contoso.com“ verknüpft, und DNS-Antworten auf Abfragen an „finance.secure.contoso.com“ können nicht überprüft werden. Wenn ein Client in diesem Szenario eine Überprüfung (Bedingung 4 unten) erfordert, schlägt eine DNS-Abfrage fehl, die an einen rekursiven DNS-Server gesendet wird, da der DNS-Client eine nicht geprüfte Antwort nicht akzeptiert. Hinweis: Wenn ein Client einen autoritativen Server direkt abfragt, wird kein Überprüfungsfehler ausgegeben, da die Antwort als bereits authentifiziert betrachtet wird.

    • Nicht ordnungsgemäß signiert: Die Zone „secure.contoso.com“ kann signiert werden, jedoch nicht auf gültige Weise. Beispielsweise können ein oder mehrere DNSSEC-Signaturschlüssel abgelaufen sein. Nach dem ersten Signieren einer Zone muss die Zone in regelmäßigen Abständen vor Ablauf der Schlüsselgültigkeitsdauer mit neuen Schlüsseln erneut signiert werden, um einen sicheren DNSSEC-Betriebsstatus zu gewährleisten. Der Gültigkeitszeitraum für DNSSEC-Signaturschlüssel sollte kurz genug für die Aufrechterhaltung der Sicherheit sein, jedoch lang genug, um eine einfache Verwaltung zu ermöglichen. DNSSEC unterstützt unter Windows Server 2012 und Windows Server 2012 R2 automatische Schlüsselrollover, wodurch sowohl die Sicherheit als auch eine einfache Verwaltung für die DNSSEC-signierten Zonen gewährleistet sind.

  2. Überprüfungszustand: Ein rekursiver DNS-Server mit einem gültigen Vertrauensanker (öffentlicher Kryptografieschlüssel) für die Zone „secure.contoso.com“ kann eine DNS-Antwort für den Ressourcendatensatz „finance.secure.contoso.com“ überprüfen. Ein rekursiver DNS-Server muss außerdem die DNSSEC-Standards und -Algorithmen unterstützen, die zum Signieren der Zone verwendet werden.

    • Überprüfung möglich: Wenn der rekursive DNS-Server alle Kryptografiealgorithmen unterstützt, die zum Signieren der Zone „secure.contoso.com“ verwendet werden, und er weiterhin über einen gültigen Vertrauensanker verfügt, mit dem er die dem signierten Ressourcendatensatz zugeordnete DNSSEC-Signatur entschlüsseln kann, kann er den Ressourcendatensatz „finance.secure.contoso.com“ als echt validieren.

    • Überprüfung nicht möglich: Ein nicht DNSSEC-fähiger DNS-Server kann keine Überprüfung auf Gültigkeit durchführen. Dementsprechend kann ein DNS-Server, der derzeit nicht über einen gültigen Vertrauensanker für die Zone „secure.contoso.com“ verfügt, keine DNS-Antwort für „finance.secure.contoso.com“ überprüfen. Vertrauensanker müssen aktualisiert werden, wenn eine Zone neu signiert wird, z. B. während eines Schlüsselrollovers. DNSSEC unterstützt unter Windows Server 2012 und Windows Server 2012 R2 automatische Aktualisierung von Vertrauensankern bei Schlüsselrollovern per RFC 5011, „Automatische Updates von Vertrauensankern für DNS-Sicherheit (DNSSEC)“.

  3. DNSSEC-Fähigkeitsstatus: Der Status zur DNSSEC-Fähigkeit eines DNS-Clients hängt vom ausgeführten Betriebssystem ab. Hinweis: Der Windows-DNS-Clientdienst in Windows 7 oder Windows Server 2008 R2 und neueren Betriebssystemen bietet DNSSEC-Unterstützung sowie nicht überprüfende Stubresolver. Frühere Windows-Betriebssysteme sind nicht DNSSEC-fähig. Der DNS-Client informiert einen DNS-Server beim Senden einer DNS-Abfrage darüber, ob er DNSSEC-fähig ist.

    • Sowohl Client als auch Server sind DNSSEC-fähig: Wenn sowohl der Client als auch der Server DNSSEC-fähig sind, enthält die DNS-Antwort vom Server an den Client die von DNSSEC authentifizierten Daten (AD-Flag). Wird die DNS-Antwort mit DNSSEC überprüft, wird AD=1 gesendet. Wenn die DNS-Antwort nicht überprüft wird, wird AD=0 gesendet.

    • Der DNS-Server ist nicht DNSSEC-fähig: Wenn der DNS-Server nicht DNSSEC-fähig ist, wird keine Überprüfung auf Gültigkeit ausgeführt, und das AD-Flag wird nicht festgelegt (AD=0), unabhängig davon, ob der DNS-Clientdienst DNSSEC-fähig ist.

    • Der DNS-Client ist nicht DNSSEC-fähig: Wenn der DNS-Client nicht DNSSEC-fähig ist, legt der DNS-Server nicht das AD-Flag in der Antwort an den Client fest, selbst wenn er DNSSEC versteht. Wenn der DNS-Server allerdings DNSSEC-fähig ist und über einen Vertrauensanker für die Zone verfügt, versucht der Server, die Antwort vom autorisierenden Server zu überprüfen. Wenn die Validierung misslingt, wird ein DNS-Serverfehler an den DNS-Client zurückgegeben. Wenn die Überprüfung erfolgreich ist, wird das Abfrageergebnis an den Client zurückgegeben. Auf diese Weise kann der DNSSEC-fähige rekursive DNS-Server DNS-Clients ohne DNSSEC-Unterstützung schützen. Wenn die Zone in diesem Szenario nicht signiert ist, wird keine Überprüfung versucht, und die Antwort wird normal an den Client zurückgegeben.

  4. Überprüfungsanforderung: Diese Einstellung bestimmt die Anforderungen eines DNSSEC-fähigen DNS-Clients an DNSSEC-Daten (das AD-Flag) in einer Antwort von einem DNS-Server. Hinweis: Der DNS-Client muss DNSSEC-fähig sein, um eine Überprüfung auf Gültigkeit anzufordern. DNS-Clients ohne DNSSEC-Unterstützung können keine DNSSEC-Überprüfung erzwingen. Wenn der DNS-Client direkt einen autorisierenden DNS-Server abfragt, wird die Antwort immer als überprüft angezeigt, selbst wenn die Zone nicht signiert ist. Dies liegt daran, dass autorisierende DNS-Server immer authentifizierte Antworten zurückgeben.

    • Überprüfung auf Gültigkeit erforderlich: Wenn eine Überprüfung auf Gültigkeit erforderlich ist, muss der Client AD=1 (Überprüfung erfolgreich) empfangen, oder er weist die DNS-Antwort zurück. Wenn die Überprüfung nicht erfolgreich war oder kein Versuch stattfand (AD=0), schlägt die DNS-Auflösung fehl. Dies gilt auch, wenn die Zone nicht signiert ist. Hinweis: Dies gilt nur für Abfragen an einen rekursiven, nicht autoritativen DNS-Server.

    • Überprüfung auf Gültigkeit nicht erforderlich: Wenn die Überprüfung nicht erforderlich ist, akzeptiert der Client eine Antwort von einem nicht DNSSEC-fähigen rekursiven DNS-Server. Wenn der rekursive DNS-Server allerdings DNSSEC-fähig ist und die Überprüfung fehlschlägt, gibt er ein Serverfailover an den Client zurück, selbst wenn der Client keine Überprüfung erfordert.

Anzeigen: