Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
DNSSEC-Ressourceneinträge werden verwendet, um DNS-Antworten zu überprüfen und zu sichern. DNS-Zonen werden über die Zonensignierung mit DNSSEC gesichert. Durch das Signieren einer Zone wird eine Überprüfungsunterstützung hinzugefügt, ohne den grundlegenden Mechanismus einer DNS-Abfrage und -Antwort zu ändern. Eine Einführung von DNSSEC für DNS Server in Windows Server finden Sie in der Übersicht über DNSSEC.
Digitale Signaturen sind in DNS-Antworten enthalten, um eine Überprüfung bereitzustellen. Diese digitalen Signaturen sind in DNSSEC-bezogenen Ressourceneinträgen enthalten, die während der Zonensignierung generiert und der Zone hinzugefügt werden.
Rekursives DNS
Wenn ein DNSSEC-fähiger rekursiver oder Weiterleitungs-DNS-Server eine Abfrage von einem DNS-Client für eine DNSSEC-signierte Zone empfängt, fordert er den autorisierenden DNS-Server an, auch DNSSEC-Einträge zu senden, um die DNS-Antwort zu überprüfen. Ein rekursiver oder Weiterleitungs-DNS-Server erkennt, dass die Zone DNSSEC unterstützt, wenn sie über einen DNSKEY verfügt, der auch als Vertrauensanker bezeichnet wird, für diese Zone.
Important
Ein nicht autoritativer DNS-Server kann Rekursion oder Weiterleitung verwenden, um eine DNS-Abfrage aufzulösen. Dieses Thema bezieht sich auf den nicht autoritativen Server als rekursiven DNS-Server; wenn der Server Weiterleitung verwendet, ist der prozess, der für die DNSSEC-Überprüfung von DNS-Antworten verwendet wird, identisch.
DNSKEY
Ein rekursiver DNS-Server verwendet den DNSKEY-Ressourceneintrag , um Antworten vom autorisierenden DNS-Server zu überprüfen. Um Antworten zu überprüfen, entschlüsselt der DNS-Server die digitalen Signaturen, die in DNSSEC-bezogenen Ressourceneinträgen enthalten sind, und vergleicht die Hashwerte. Wenn Hashwerte identisch sind, stellt sie eine Antwort auf den DNS-Client mit den angeforderten DNS-Daten bereit, z. B. einem Hostressourceneintrag (A). Wenn Hashwerte nicht übereinstimmen, antwortet sie mit einer SERVFAIL Nachricht. Auf diese Weise schützt ein DNSSEC-fähiger, auflösender DNS-Server mit installiertem gültigen Vertrauensanker vor DNS-Spoofing-Angriffen, unabhängig davon, ob die DNS-Clients DNSSEC unterstützen.
Wenn Ihr DNS-Client DNSSEC-fähig ist, kann er so konfiguriert werden, dass der DNS-Server die DNSSEC-Überprüfung durchführt.
Die folgende Abbildung zeigt den Überprüfungsprozess.
DNSKEYs werden verwendet, um Hashwerte zu berechnen und RRSIG-Einträge zu entschlüsseln. In der Abbildung werden nicht alle Überprüfungsprozesse angezeigt, die ausgeführt werden. Außerdem wird eine weitere Überprüfung durchgeführt, um sicherzustellen, dass die DNSKEYs gültig sind und dass DS-Einträge gültig sind, sofern sie vorhanden sind (nicht im Screenshot dargestellt).
DNS-Abfrage- und Antwortprozess
Ein einfaches Beispiel veranschaulicht, wie Sie DNSSEC in den DNS-Abfrage- und Antwortprozess integrieren können, um eine Überprüfung bereitzustellen.
Im folgenden Beispiel fragt ein DNS-Clientcomputer einen rekursiven (Caching)-DNS-Server ab, der wiederum autorisierende DNS-Server abfragt, bevor eine Antwort zurückgegeben wird. In diesem Beispiel wird davon ausgegangen, dass DNS-Daten noch nicht auf dem Client oder Server zwischengespeichert werden. DNSSEC-Daten überprüfen DNS-Antworten nur dann als original, wenn eine Zone signiert ist, und Sie verwenden DNSSEC-fähige Server und Clients.
Die folgende Abbildung zeigt den rekursiven DNS-Abfrageprozess.
In der folgenden Tabelle sind die Schritte in einer DNS-Abfrage und -Antwort mit optionalen DNSSEC-Daten aufgeführt.
| Step | Query-response | 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 Root- und Top-Level-Domain (TLD) DNS-Server. | 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, der die IP-Adresse des autorisierenden DNS-Servers für die Zone bereitstellt. | Die autoritativen 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 es DNSSEC-fähig (DO=1) ist und in der Lage ist, signierte Ressourceneinträge (CD=1) in der Antwort zu validieren. |
| 5 | Der autorisierende DNS-Server sendet eine DNS-Antwort an den rekursiven DNS-Server und stellt die Ressourcendaten bereit. | Der autoritative DNS-Server kann DNSSEC-Signaturen in Form von RRSIG-Einträgen in der DNS-Antwort zur Verwendung in der Überprüfung enthalten. |
| 6 | Der rekursive DNS-Server gibt eine DNS-Antwort an den DNS-Client zurück, die die Ressourceneintragsdaten bereitstellt. | Der rekursive DNS-Server kann angeben, ob die DNS-Antwort mit DNSSEC überprüft wurde oderAD=1 nicht. |
Einschließen von DNSSEC-Daten
DNSSEC-bezogene Flags (Bits) werden in einer DNS-Abfrage und -Antwort verwendet, um zu ermitteln, ob DNSSEC-Daten enthalten sind und 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 sind, wird dies als „Festlegen“ des Bits bezeichnet (Wert auf 1 festgelegt). Das Deaktivieren eines Flags wird als "Löschen" des Bits bezeichnet (Der Wert ist auf 0 festgelegt).
-
DO: Das DO-Bit ist in einer DNS-Abfrage enthalten und ist eine Abkürzung für "DNSSEC OK". Wenn das DO-Bit festgelegt ist (
DO=1), ist der Client DNSSEC-fähig, und es ist sicher, dass der DNS-Server DNSSEC-Daten in einer Antwort zurückgibt. Wenn das DO-Bit nicht festgelegt ist (DO=0), ist der Client nicht DNSSEC-fähig, und der DNS-Server kann keine DNSSEC-Daten in eine DNS-Antwort einschließen. DNS-Clients können weiterhin mithilfe von DNSSEC geschützt werden, auch wenn sie nicht DNSSEC-fähig sind. In diesem Zusammenhang ist ein DNS-Client jeder 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 autoritative DNSSEC-Server DNSSEC-Daten in der Antwort sendet. -
AD: Das AD-Bit ist in einer DNS-Antwort enthalten und ist eine Abkürzung für "authentifizierte Daten". Wenn das AD-Bit festgelegt ist (
AD=1), bedeutet dies, dass die DNS-Antwort authentifiziert ist, da sie mit DNSSEC überprüft wurde. Ein nicht überprüfter DNSSEC-kompatibler Computer, z. B. ein Windows 8-Computer, führt keine DNSSEC-Überprüfung durch, kann jedoch so konfiguriert werden, dass DNS-Antworten authentifiziert sind. Wenn das AD-Bit nicht festgelegt ist (AD=0), wurde die DNS-Antwort nicht überprüft. Das AD-Bit ist möglicherweise nicht festgelegt, weil die Überprüfung nicht versucht wurde oder weil die Überprüfung fehlgeschlagen ist. -
CD: Das CD-Bit ist in einer DNS-Abfrage enthalten und ist eine Abkürzung für "Check disabled". Wenn das CD-Bit in einer Anfrage gesetzt ist
CD=1, bedeutet dies, dass eine DNS-Antwort gesendet werden soll, unabhängig davon, ob die Validierung erfolgreich durchgeführt wurde. Wenn das CD-Bit nicht festgelegt ist (CD=0), wird keine DNS-Antwort gesendet, wenn die Überprüfung erforderlich war und ein Fehler aufgetreten ist. Wenn das CD-Bit klar ist (CD=0), bedeutet dies, dass die Überprüfung aktiviert ist und die DNSSEC-Validierung erfolgen kann. Das CD-Bit kann in einer Abfrage festgelegt (CD=1) werden, da der Host die DNSSEC-Überprüfung durchführen kann und keine Upstreamüberprüfung erfordert, z. B. einen rekursiven DNS-Server mit Windows Server 2012 oder höher. Ein nichtvalidierender Stubresolver, wie z. B. ein Computer, auf dem der Windows-DNS-Client läuft, stellt Abfragen mit dem gelöschten CD-BitCD=0. Weitere Informationen finden Sie unter RFC4035, Abschnitt 3.2.2.
Ein viertes wichtiges Flag (Bit), das in einem DNS-Paketheader vorhanden sein kann, ist das AA-Bit. Dieses Flag ist mit DNSSEC nicht neu, kann aber verwendet werden, wenn DNSSEC bereitgestellt wird:
-
AA: Das AA-Bit ist in einer DNS-Antwort enthalten und ist eine Abkürzung für "autoritative Antwort". Wenn das AA-Bit festgelegt ist, bedeutet dies, dass die DNS-Antwort authentifiziert ist, da sie direkt von einem autorisierenden DNS-Server stammt. Ein Client, der die DNSSEC-Überprüfung (
AD=1) erfordert, akzeptiert stattdessen das AA-Bit (AA=1,AD=0). Wenn der Client direkt einen autorisierenden Server abfragt, da autoritative Antworten nicht überprüft werden müssen. Es wäre redundant für einen autoritativen Server, seine eigene Antwort zu validieren.
Beispiel für DNS-Abfragen
In den folgenden Beispielen werden DNS-Abfrageergebnisse angezeigt, die von einem DNS-Clientcomputer ausgeführt werden, auf dem Windows 8.1 mit dem Cmdlet Resolve-DnsName ausgeführt wird. Das Cmdlet Resolve-DnsName wurde in Windows Server 2012 und Windows 8 eingeführt und kann verwendet werden, um DNS-Abfragen anzuzeigen, die DNSSEC-Daten enthalten.
Important
Verwenden Sie das Befehlszeilentool nicht, um die nslookup.exe DNSSEC-Unterstützung für eine Zone zu testen. Das nslookup.exe Tool 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 Adresseintrag (A) in der signierten Zone secure.contoso.com mit DO=0.
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
Das DO-Bit ist nicht festgelegt, da der Dnssecok-Parameter nicht enthalten war.
Beispiel 2: Im folgenden Beispiel wird das DO=1 Flag durch Hinzufügen des dnssecok-Parameters festgelegt.
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, sendet der DNS-Server keine DNSSEC-Daten in der DNS-Antwort. Wenn DO=1der Client angibt, dass er DNSSEC-Daten empfangen kann, falls verfügbar. Da die secure.contoso.com Zone signiert ist, wurde ein RRSIG-Ressourceneintrag in die DNS-Antwort einbezogen, wenn DO=1.
In Beispiel 1 und Beispiel 2 ist die Überprüfung für die secure.contoso.com Zone nicht erforderlich, da die NrPT (Name Resolution Policy Table) nicht für die Überprüfung konfiguriert ist.
Sie können das Cmdlet Get-DnsClientNrptPolicy verwenden, um aktuelle NRPT-Regeln anzuzeigen. Weitere Informationen finden Sie unter Get-DnsClientNrptPolicy.
Beispiel 3: Im folgenden Beispiel wird eine NRPT-Regel für secure.contoso.com.
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 ist der Wert für DnsSecValidationRequired"False". Wenn der Wert "false" lautet, ist die DNSSEC-Überprüfung nicht erforderlich.
Beispiel 4: Bei aktivierter secure.contoso.comDNSSEC-Überprüfung zeigt das NRPT "True " für DnsSecValidationRequired an. In diesem Beispiel werden nur der secure.contoso.com Namespace und der Parameter DnsSecValidationRequired angezeigt.
(Get-DnsClientNrptPolicy -NameSpace secure.contoso.com).DnsSecValidationRequired
True
Wenn der Wert von DnsSecValidationRequired"True " lautet, senden DNSSEC-fähige Clientcomputer immer Abfragen mit DO=1, auch wenn der Dnssecok-Parameter nicht enthalten ist.
Beispiel 5: Wenn die DNSSEC-Überprüfung in der Namensauflösungsrichtlinientabelle (NAME RESOLUTION Policy Table, NRPT) erforderlich ist, wird das DNSSEC OK-Bit automatisch (DO=1) für DNSSEC-fähige Clients festgelegt.
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-Eintrag in der DNS-Antwort gesendet, um die Validierungsanforderungen zu secure.contoso.comerfüllen. Ein gültiger Vertrauensanker ist auch auf dem rekursiven DNS-Server dns1.contoso.comkonfiguriert.
Wenn ein DNS-Client nicht DNSSEC-fähig ist, gilt die NRPT-Regel nicht, und Abfragen werden mit DO=0gesendet, auch wenn eine NRPT-Regel vorhanden ist, die DNSSEC-Überprüfung erfordert.
Beispiel 6: Im folgenden Beispiel wird dieselbe Abfrage wie in Beispiel 5 ausgeführt, jedoch ohne einen gültigen Vertrauensanker, der für dns1.contoso.com.
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 tritt bei der DNS-Auflösung der Fehler DNS_ERROR_UNSECURE_PACKET auf. Die Lösung schlägt fehl, da die Überprüfung im NRPT erforderlich ist, aber aufgrund des Mangels eines gültigen Vertrauensankers für die Zone secure.contoso.comnicht ausgeführt werden kann. Das Cmdlet Resolve-DnsName meldet detaillierte Ergebnisse für den Aufgetretenen Fehlertyp. Wenn der DNS-Client versucht, finance.secure.contoso.com aufzulösen, um eine Verbindung mit diesem Host herzustellen, schlägt dies fehl.
DNSSEC-Szenarien
DNSSEC kann in vielen verschiedenen Umgebungen mit eindeutigen Server- und Clienteinstellungen bereitgestellt werden, es ist wichtig zu verstehen, wie DNS-Abfragen und -Antworten betroffen sind.
Berücksichtigen Sie die folgenden vier DNSSEC-bezogenen Aussagen. Jede Anweisung wirkt sich auf die Funktionsweise von DNSSEC in einem bestimmten Szenario aus:
- Der
finance.secure.contoso.comRessourceneintrag ist ordnungsgemäß mit DNSSEC signiert. - Ein rekursiver DNS-Server kann Antworten auf eine Abfrage für
finance.secure.contoso.comvalidieren. - Ein DNS-Client ist DNSSEC-fähig.
- Ein DNS-Client ist so konfiguriert, dass für alle Abfragen im
secure.contoso.comNamespace eine Überprüfung erforderlich ist.
Betrachten wir die vier einzelnen Aussagen ausführlicher.
DNSSEC-Signaturstatus: DNSSEC signiert alle Einträge in der Zone, diese Bedingung bezieht sich auf den Status der
secure.contoso.comZone, nicht nur auf denfinance.secure.contoso.comRessourceneintrag. Sie können einige Datensätze nicht signieren und keine anderen Datensätze signieren. Der DNSSEC-Status vonfinance.secure.contoso.comhängt daher vom DNSSEC-Status vonsecure.contoso.comab.Richtig signiert: Die
secure.contoso.comZone kann auf gültige Weise signiert werden, wodurch sie als Originalversion überprüft werden kannfinance.secure.contoso.com. 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
secure.contoso.comZone ist möglicherweise nicht signiert, in diesem Fall ist kein RRSIG-Eintrag zugeordnetfinance.secure.contoso.com, und DNS-Antworten auf Abfragenfinance.secure.contoso.comkönnen nicht überprüft werden. Wenn ein Client eine Überprüfung erfordert, schlägt eine AN einen rekursiven DNS-Server gesendete DNS-Abfrage fehl, da der DNS-Client keine nichtvalidierte Antwort akzeptiert. Wenn ein Client einen autorisierenden Server direkt abfragt, schlägt die Überprüfung nicht fehl, da die Antwort bereits als authentifiziert betrachtet wird.Nicht richtig signiert: Die
secure.contoso.comZone ist möglicherweise signiert, aber nicht gültig. Beispielsweise ist ein oder mehrere DNSSEC-Signaturschlüssel möglicherweise abgelaufen. Nachdem Sie eine Zone anfangs signiert haben, muss die Zone regelmäßig mit neuen Schlüsseln erneut signiert werden, bevor der Gültigkeitszeitraum des Signaturschlüssels abläuft, um einen sicheren DNSSEC-Betriebsstatus zu erhalten. Der Gültigkeitszeitraum für DNSSEC-Signaturschlüssel sollte kurz genug sein, um die Sicherheit aufrechtzuerhalten, aber lange genug, um eine einfache Verwaltung zu ermöglichen. DNSSEC in Windows Server 2012 und Windows Server 2012 R2 unterstützt den automatischen Schlüsselrollover und bietet sowohl Sicherheit als auch Einfache Verwaltung für Ihre DNSSEC-signierten Zonen.
Überprüfungsstatus: Ein rekursiver DNS-Server mit einem gültigen Vertrauensanker (öffentlicher kryptografischer Schlüssel) für die
secure.contoso.comZone kann eine DNS-Antwort für denfinance.secure.contoso.comRessourceneintrag überprüfen. Ein rekursiver DNS-Server muss auch die DNSSEC-Standards und -Algorithmen unterstützen, die zum Signieren der Zone verwendet werden.Kann überprüfen: Wenn der rekursive DNS-Server alle kryptografischen Algorithmen unterstützt, die zum Signieren der
secure.contoso.comZone verwendet werden, und es verfügt über einen gültigen Vertrauensanker, den er zum Entschlüsseln der DNSSEC-Signatur verwenden kann, die dem signierten Ressourceneintrag zugeordnet ist, dann kann er denfinance.secure.contoso.comRessourceneintrag als original überprüfen.Kann nicht überprüfen: Ein nicht DNSSEC-fähiger DNS-Server kann nicht überprüft werden. Dementsprechend kann ein DNS-Server, der derzeit nicht über einen gültigen Vertrauensanker für die Zone
secure.contoso.comverfügt, keine DNS-Antwort fürfinance.secure.contoso.comüberprüfen. Vertrauensanker müssen aktualisiert werden, wenn eine Zone neu signiert wird, z. B. während eines Schlüsselrollovers. DNSSEC in Windows Server 2012 und Windows Server 2012 R2 unterstützt die automatische Aktualisierung von Vertrauensankern für den Schlüsselrollover pro RFC 5011, "Automatisierte Updates von DNS Security (DNSSEC)-Vertrauensankern".
DNSSEC-fähiger Status: Der DNSSEC-fähige Status eines DNS-Clients hängt vom Betriebssystem ab, das ausgeführt wird. Der Windows-DNS-Clientdienst unter Windows 7 oder Windows Server 2008 R2 und höher sind DNSSEC-fähige Stubresolver, die keine Überprüfungen ausführen. Frühere Windows-Betriebssysteme sind nicht DNSSEC-fähig. Der DNS-Client informiert einen DNS-Server, ob er DNSSEC-fähig ist, wenn er eine DNS-Abfrage sendet.
Sowohl der Client als auch der Server sind DNSSEC-aware: Wenn sowohl der Client als auch der Server DNSSEC-aware sind, dann enthält die DNS-Antwort vom Server an den Client das DNSSEC-authentifizierte Daten-Flag (AD). Wenn die DNS-Antwort mit DNSSEC überprüft wird, wird
AD=1gesendet. Wenn die DNS-Antwort nicht überprüft wurde, wirdAD=0gesendet.Der DNS-Server ist nicht DNSSEC-fähig: Wenn der DNS-Server nicht DNSSEC-fähig ist, wird keine Überprüfung ausgeführt, und das AD-Flag wird nicht festgelegt (
AD=0), unabhängig davon, ob der DNS-Client 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 das AD-Flag nicht in seiner Antwort auf den Client fest, auch wenn er DNSSEC versteht. Wenn der DNS-Server jedoch DNSSEC-fähig ist und er über einen Vertrauensanker für die Zone verfügt, versucht der Server, die Antwort vom autorisierenden Server zu überprüfen. Wenn die Überprüfung fehlschlägt, wird ein DNS-Serverfehler an den DNS-Client zurückgegeben. Wenn die Überprüfung erfolgreich ist, werden die Abfrageergebnisse an den Client zurückgegeben. Auf diese Weise kann ein DNSSEC-fähiger rekursiver DNS-Server nicht DNSSEC-fähige DNS-Clients 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.
Überprüfungsanforderung: Diese Einstellung bestimmt die Anforderung eines DNSSEC-fähigen DNS-Clients für DNSSEC-Daten (das AD-Flag) in einer Antwort von einem DNS-Server. Damit der DNS-Client eine Überprüfung erfordert, muss er DNSSEC-fähig sein. Nicht DNSSEC-fähige DNS-Clients können nicht gezwungen werden, eine DNSSEC-Überprüfung erforderlich zu machen. Wenn der DNS-Client direkt einen autorisierenden DNS-Server abfragt, wird die Antwort überprüft, auch wenn die Zone nicht signiert ist. Dies liegt daran, dass autoritative DNS-Server immer authentische Antworten zurückgeben.
Die Überprüfung ist erforderlich: Wenn eine Überprüfung erforderlich ist, muss der Client (Überprüfung erfolgreich) empfangen
AD=1oder die DNS-Antwort ablehnen. Wenn die Überprüfung nicht erfolgreich war oder nicht versucht wurde (AD=0), schlägt die DNS-Auflösung fehl. Dies gilt auch dann, wenn die Zone nicht signiert ist. Dies gilt nur für Abfragen für einen rekursiven, nicht authentifizierten DNS-Server.Die Überprüfung ist nicht erforderlich: Wenn eine Überprüfung nicht erforderlich ist, akzeptiert der Client eine Antwort von einem nicht DNSSEC-fähigen rekursiven DNS-Server. Wenn der rekursive DNS-Server jedoch DNSSEC-fähig ist und die Überprüfung fehlschlägt, wird ein Serverfailover an den Client zurückgegeben, auch wenn der Client keine Überprüfung erfordert.
Nächste Schritte
Hier finden Sie einige Artikel, um mehr über DNSSEC für DNS Server zu erfahren.