Delen via

Overzicht van DNSSEC (preview)

  • Artikel

Dit artikel bevat een overzicht van DNSSEC-extensies (Domain Name System Security Extensions) en bevat een inleiding tot DNSSEC-terminologie. De voordelen van ondertekening van DNSSEC-zones worden beschreven en er worden voorbeelden gegeven voor het weergeven van DNSSEC-gerelateerde resourcerecords. Wanneer u klaar bent om uw openbare DNS-zone van Azure te ondertekenen, raadpleegt u de volgende handleidingen:

Notitie

DNSSEC-zoneondertekening is momenteel in PREVIEW.
Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.

Wat is DNSSEC?

DNSSEC is een suite met extensies die beveiliging toevoegen aan het DNS-protocol (Domain Name System) door DNS-antwoorden in te schakelen voor validatie als echt. DNSSEC biedt oorsprongsinstantie, gegevensintegriteit en geverifieerde weigering van bestaan. Met DNSSEC is het DNS-protocol veel minder gevoelig voor bepaalde soorten aanvallen, met name DNS-adresvervalsingsaanvallen.

De DNSSEC-kernextensies worden opgegeven in de volgende aanvraag voor opmerkingen (RFC's):

  • RFC 4033: "Inleiding en vereisten voor DNS-beveiliging"
  • RFC 4034: "Resourcerecords voor de DNS-beveiligingsextensies"
  • RFC 4035: "Protocolwijzigingen voor de DNS-beveiligingsextensies"

Zie RFC9364: DNS Security Extensions (DNSSEC) voor een overzicht van DNSSEC-RFC's.

Hoe DNSSEC werkt

DNS-zones worden beveiligd met DNSSEC met behulp van een proces dat zoneondertekening wordt genoemd. Het ondertekenen van een zone met DNSSEC voegt validatieondersteuning toe zonder het basismechanisme van een DNS-query en -antwoord te wijzigen. Als u een zone wilt ondertekenen met DNSSEC, moet de primaire gezaghebbende DNS-server van de zone DNSSEC ondersteunen.

Resource Record Signatures (RRSIG's) en andere cryptografische records worden toegevoegd aan de zone wanneer deze is ondertekend. In de volgende afbeelding ziet u DNS-resourcerecords in de zone contoso.com vóór en na zoneondertekening.

Een diagram waarin wordt getoond hoe RRSIG-records worden toegevoegd aan een zone wanneer deze is ondertekend met DNSSEC.

DNSSEC-validatie van DNS-antwoorden vindt plaats met behulp van deze digitale handtekeningen met een niet-verbroken vertrouwensketen.

Notitie

DNSSEC-gerelateerde resourcerecords worden niet weergegeven in Azure Portal. Zie DNSSEC-gerelateerde resourcerecords weergeven voor meer informatie.

Waarom een zone ondertekenen met DNSSEC?

Het ondertekenen van een zone met DNSSEC is vereist voor naleving van bepaalde beveiligingsrichtlijnen, zoals SC-20: Secure Name/Address Resolution Service.

DNSSEC-validatie van DNS-antwoorden kan veelvoorkomende typen DNS-hijackingaanvallen voorkomen, ook wel DNS-omleiding genoemd. DNS-hijacking vindt plaats wanneer een clientapparaat wordt omgeleid naar een schadelijke server met behulp van onjuiste (vervalste) DNS-antwoorden. DNS-cachevergiftiging is een veelgebruikte methode voor het spoofen van DNS-antwoorden.

In de volgende afbeelding ziet u een voorbeeld van hoe DNS-hijacking werkt.

Een diagram waarin wordt getoond hoe DNS-hijacking werkt.

Normale DNS-resolutie:

  1. Een clientapparaat verzendt een DNS-query voor contoso.com naar een DNS-server.
  2. De DNS-server reageert met een DNS-resourcerecord voor contoso.com.
  3. Het clientapparaat vraagt een reactie van contoso.com.
  4. De contoso.com-app of webserver retourneert een antwoord op de client.

DNS-hijacking

  1. Een clientapparaat verzendt een DNS-query voor contoso.com naar een gekaapte DNS-server.
  2. De DNS-server reageert met een ongeldige (vervalste) DNS-bronrecord voor contoso.com.
  3. Het clientapparaat vraagt een antwoord op contoso.com van schadelijke server.
  4. De schadelijke server retourneert een vervalst antwoord op de client.

Het type DNS-resourcerecord dat is vervalst, is afhankelijk van het type DNS-hijacking-aanval. Een MX-record kan worden vervalst om e-mailberichten van clients om te leiden of een vervalstE A-record kan clients naar een kwaadwillende webserver verzenden.

DNSSEC werkt om DNS-hijacking te voorkomen door validatie uit te voeren op DNS-antwoorden. In het scenario voor DNS-hijacking dat hier wordt weergegeven, kan het clientapparaat niet-gevalideerde DNS-antwoorden weigeren als het contoso.com domein is ondertekend met DNSSEC. Als u niet-gevalideerde DNS-antwoorden wilt weigeren, moet het clientapparaat DNSSEC-validatie afdwingen voor contoso.com.

DNSSEC bevat ook Next Secure 3 (NSEC3) om zone-inventarisatie te voorkomen. Zone-inventarisatie, ook wel zone lopen genoemd, is een aanval waarbij de aanvaller een lijst met alle namen in een zone opstelt, inclusief onderliggende zones.

Voordat u een zone ondertekent met DNSSEC, moet u weten hoe DNSSEC werkt. Wanneer u klaar bent om een zone te ondertekenen, raadpleegt u Hoe u uw openbare Azure DNS-zone ondertekent met DNSSEC.

DNSSEC-validatie

Als een DNS-server DNSSEC-bewust is, kan de DNSSEC OK-vlag (DO) in een DNS-query worden ingesteld op een waarde van 1. Deze waarde geeft aan dat de reagerende DNS-server DNSSEC-gerelateerde bronrecords met het antwoord moet bevatten. Deze DNSSEC-records zijn RRSIG-records (Resource Record Signature) die worden gebruikt om te controleren of het DNS-antwoord legitiem is.

Een recursieve (niet-bindende) DNS-server voert DNSSEC-validatie uit op RRSIG-records met behulp van een vertrouwensanker (DNSKEY). De server gebruikt een DNSKEY voor het ontsleutelen van digitale handtekeningen in RRSIG-records (en andere DNSSEC-gerelateerde records) en berekent en vergelijkt vervolgens hashwaarden. Als hashwaarden hetzelfde zijn, geeft het een antwoord op de DNS-client met de DNS-gegevens die zijn aangevraagd, zoals een hostadresrecord (A). Zie het volgende diagram:

Een diagram waarin wordt getoond hoe DNSSEC-validatie werkt.

Als hashwaarden niet hetzelfde zijn, reageert de recursieve DNS-server met een SERVFAIL-bericht. Op deze manier kunnen DNSSEC-compatibele DNS-servers (of doorsturen) met een geldig vertrouwensanker worden beveiligd tegen DNS-hijacking in het pad tussen de recursieve server en de gezaghebbende server. Voor deze beveiliging hoeven DNS-clientapparaten niet DNSSEC-bewust te zijn of dns-antwoordvalidatie af te dwingen, mits de lokale (laatste hop) recursieve DNS-server zelf beveiligd is tegen hijacking.

Windows 10- en Windows 11-clientapparaten zijn niet-geldige beveiligingsbewuste stub-resolvers. Deze clientapparaten voeren geen validatie uit, maar kunnen DNSSEC-validatie afdwingen met behulp van groepsbeleid. De NRPT kan worden gebruikt voor het maken en afdwingen van DNSSEC-validatiebeleid op basis van een naamruimte.

Vertrouwensankers en DNSSEC-validatie

Notitie

DNSSEC-antwoordvalidatie wordt niet uitgevoerd door de standaard door Azure geleverde resolver. De informatie in deze sectie is handig als u uw eigen recursieve DNS-servers instelt voor DNSSEC-validatie of het oplossen van validatieproblemen.

Vertrouwensankers werken op basis van de DNS-naamruimtehiërarchie. Een recursieve DNS-server kan een willekeurig aantal vertrouwensankers of geen vertrouwensankers hebben. Vertrouwensankers kunnen worden toegevoegd voor één onderliggende DNS-zone of een bovenliggende zone. Als een recursieve DNS-server een basisvertrouwensanker (.) heeft, kan deze DNSSEC-validatie uitvoeren op elke DNS-zone. Zie De operatorinformatie van de hoofdzone voor meer informatie.

Het DNSSEC-validatieproces werkt als volgt met vertrouwensankers:

  • Als een recursieve DNS-server geen DNSSEC-vertrouwensanker heeft voor een zone of de bovenliggende hiërarchische naamruimte van de zone, wordt er geen DNSSEC-validatie op die zone uitgevoerd.
  • Als een recursieve DNS-server een DNSSEC-vertrouwensanker heeft voor de bovenliggende naamruimte van een zone en er een query voor de onderliggende zone wordt ontvangen, wordt gecontroleerd of er een DS-record voor de onderliggende zones aanwezig is in de bovenliggende zone.
    • Als de DS-record wordt gevonden, voert de recursieve DNS-server DNSSEC-validatie uit.
    • Als de recursieve DNS-server bepaalt dat de bovenliggende zone geen DS-record voor de onderliggende zone heeft, wordt ervan uitgegaan dat de onderliggende zone onveilig is en geen DNSSEC-validatie uitvoert.
  • Als er meerdere recursieve DNS-servers betrokken zijn bij een DNS-antwoord (inclusief doorstuurservers), moet elke server DNSSEC-validatie kunnen uitvoeren op het antwoord, zodat er een niet-verbroken vertrouwensketen is.
  • Recursieve servers waarvoor DNSSEC-validatie is uitgeschakeld of die niet DNSSEC-bewust zijn, voeren geen validatie uit.

Vertrouwensketen

Een vertrouwensketen treedt op wanneer alle DNS-servers die betrokken zijn bij het verzenden van een antwoord voor een DNS-query, kunnen valideren dat het antwoord niet is gewijzigd tijdens de overdracht. Om DNSSEC-validatie end-to-end te laten werken, moet de vertrouwensketen worden verbroken. Deze vertrouwensketen is van toepassing op zowel gezaghebbende als niet-gezaghebbende (recursieve) servers.

Gezaghebbende servers

Gezaghebbende DNS-servers onderhouden een vertrouwensketen door middel van DS-records (delegeringsregistratie). DS-records worden gebruikt om de echtheid van onderliggende zones in de DNS-hiërarchie te verifiëren.

  • Om DNSSEC-validatie uit te voeren op een ondertekende zone, moet het bovenliggende element van de ondertekende zone ook zijn ondertekend. De bovenliggende zone moet ook een DS-record hebben voor de onderliggende zone.
  • Tijdens het validatieproces wordt de bovenliggende zone opgevraagd voor de DS-record. Als de DS-record niet aanwezig is of de DS-recordgegevens in het bovenliggende item niet overeenkomen met de DNSKEY-gegevens in de onderliggende zone, wordt de vertrouwensketen verbroken en mislukt de validatie.

Recursieve servers

Recursieve DNS-servers (ook wel omzetten of cachen van DNS-servers genoemd) onderhouden een vertrouwensketen via het gebruik van DNSSEC-vertrouwensankers.

  • Het vertrouwensanker is een DNSKEY-record of DS-record die een hash van een DNSKEY-record bevat. De DNSKEY-record wordt gemaakt op een gezaghebbende server wanneer een zone is ondertekend en verwijderd uit de zone als de zone niet is ondertekend.
  • Vertrouwensankers moeten handmatig worden geïnstalleerd op recursieve DNS-servers.
  • Als er een vertrouwensanker voor een bovenliggende zone aanwezig is, kan een recursieve server alle onderliggende zones in de hiërarchische naamruimte valideren. Dit omvat doorgestuurde query's. Ter ondersteuning van DNSSEC-validatie van alle DNSSEC-ondertekende DNS-zones, kunt u een vertrouwensanker voor de hoofdzone (.) installeren.

Sleutelrollover

De zoneondertekeningssleutel (ZSK) in een door DNSSEC ondertekende zone wordt periodiek automatisch overgezet (vervangen) door Azure. Het is niet nodig om uw sleutelondertekeningssleutel (KSK) te vervangen, maar deze optie is beschikbaar door contact op te leggen met Microsoft Ondersteuning. Als u de KSK vervangt, moet u uw DS-record ook bijwerken in de bovenliggende zone.

Algoritme voor zoneondertekening

Zones zijn DNSSEC ondertekend met Elliptic Curve Digital Signature Algorithm (ECDSAP256SHA256).

De volgende tabel bevat een korte beschrijving van DNSSEC-gerelateerde records. Zie RFC 4034: Resourcerecords voor de DNS-beveiligingsextensies en RFC 7344: DNSSEC-delegatievertrouwensonderhoud automatiseren voor meer informatie.

Opnemen Beschrijving
Handtekening voor resourcerecords (RRSIG) Een DNSSEC-bronrecordtype dat wordt gebruikt voor het opslaan van een handtekening, waarin een set DNS-records voor een bepaalde naam en een bepaald type wordt behandeld.
DNSKEY Een DNSSEC-resourcerecordtype dat wordt gebruikt voor het opslaan van een openbare sleutel.
Delegatie-ondertekenaar (DS) Een DNSSEC-resourcerecordtype dat wordt gebruikt om een delegatie te beveiligen.
Volgende beveiligde (NSEC) Een DNSSEC-bronrecordtype dat wordt gebruikt om niet-existentie van een DNS-naam te bewijzen.
Volgende beveiligde 3 (NSEC3) De NSEC3-resourcerecord die hashed, geverifieerde doken van bestaan biedt voor DNS-resourcerecordsets.
Volgende beveiligde 3 parameters (NSEC3PARAM) Hiermee geeft u parameters voor NSEC3-records.
Ondertekenaar voor onderliggende delegatie (CDS) Deze record is optioneel. Indien aanwezig, kan de CDS-record worden gebruikt door een onderliggende zone om de gewenste inhoud van de DS-record in een bovenliggende zone op te geven.
Onderliggende DNSKEY (CDNSKEY) Deze record is optioneel. Als de CDNSKEY-record aanwezig is in een onderliggende zone, kan deze worden gebruikt om een DS-record te genereren op basis van een DNSKEY-record.

DNSSEC-gerelateerde records worden niet weergegeven in Azure Portal. Als u DNSSEC-gerelateerde records wilt weergeven, gebruikt u opdrachtregelprogramma's zoals Resolve-DnsName of dig.exe. Deze hulpprogramma's zijn beschikbaar via Cloud Shell of lokaal als ze op uw apparaat zijn geïnstalleerd. Zorg ervoor dat u de DO-vlag in uw query instelt met behulp van de -dnssecok optie in Resolve-DnsName of de +dnssec optie in dig.exe.

Belangrijk

Gebruik het opdrachtregelprogramma nslookup.exe niet om query's uit te voeren op DNSSEC-gerelateerde records. Het hulpprogramma nslookup.exe maakt gebruik van een interne DNS-client die niet DNSSEC-bewust is.

Zie de volgende voorbeelden:

PS C:\> resolve-dnsname server1.contoso.com -dnssecok

Name                                      Type   TTL   Section    IPAddress
----                                      ----   ---   -------    ---------
server1.contoso.com                        A     3600  Answer     203.0.113.1

Name        : server1.contoso.com
QueryType   : RRSIG
TTL         : 3600
Section     : Answer
TypeCovered : A
Algorithm   : 13
LabelCount  : 3
OriginalTtl : 3600
Expiration  : 9/20/2024 11:25:54 PM
Signed      : 9/18/2024 9:25:54 PM
Signer      : contoso.com
Signature   : {193, 20, 122, 196…}

C:\>dig server1.contoso.com +dnssec

; <<>> DiG 9.9.2-P1 <<>> server1.contoso.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61065
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
server1.contoso.com. 3600   IN      A       203.0.113.1
server1.contoso.com. 3600   IN      RRSIG   A 13 3 3600 20240920232359 20240918212359 11530 contoso.com. GmxeQhNk1nJZiep7nuCS2qmOQ+Ffs78Z2eoOgIYP3j417yqwS1DasfA5 e1UZ4HuujDk2G6GIbs0ji3RiM9ZpGQ==

;; Query time: 153 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 15:23:45 2024
;; MSG SIZE  rcvd: 179

PS C:\> resolve-dnsname contoso.com -Type dnskey -dnssecok

Name                                 Type   TTL   Section    Flags  Protocol Algorithm      Key
----                                 ----   ---   -------    -----  -------- ---------      ---
contoso.com                          DNSKEY 3600  Answer     256    DNSSEC   13             {115, 117, 214,
                                                                                                165…}
contoso.com                          DNSKEY 3600  Answer     256    DNSSEC   13             {149, 166, 55, 78…}
contoso.com                          DNSKEY 3600  Answer     257    DNSSEC   13             {45, 176, 217, 2…}

Name        : contoso.com
QueryType   : RRSIG
TTL         : 3600
Section     : Answer
TypeCovered : DNSKEY
Algorithm   : 13
LabelCount  : 2
OriginalTtl : 3600
Expiration  : 11/17/2024 9:00:15 PM
Signed      : 9/18/2024 9:00:15 PM
Signer      : contoso.com
Signature   : {241, 147, 134, 121…}

C:\>dig contoso.com dnskey

; <<>> DiG 9.9.2-P1 <<>> contoso.com dnskey
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46254
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
contoso.com.        3600    IN      DNSKEY  256 3 13 laY3Toc/VTyjupgp/+WgD05N+euB6Qe1iaM/253k7bkaA0Dx+gSDhbH2 5wXTt+uLQgPljL9OusKTneLdhU+1iA==
contoso.com.        3600    IN      DNSKEY  257 3 13 LbDZAtjG8E9Ftih+LC8CqQrSZIJFFJMtP6hmN3qBRqLbtAj4JWtr2cVE ufXM5Pd/yW+Ca36augQDucd5n4SgTg==
contoso.com.        3600    IN      DNSKEY  256 3 13 c3XWpTqZ0q9IO+YqMEtOBHZSzGGeyFKq0+3xzs6tifvD1rey1Obhrkz4 DJlEIxy2m84VsG1Ij9VYdtGxxeVHIQ==

;; Query time: 182 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Sep 19 16:35:10 2024
;; MSG SIZE  rcvd: 284

DNSSEC-terminologie

Deze lijst wordt verstrekt om inzicht te krijgen in enkele algemene termen die worden gebruikt bij het bespreken van DNSSEC. Zie ook: DNSSEC-gerelateerde resourcerecords

Term Omschrijving
Geverifieerde gegevens (AD) bit Een gegevensbit die aangeeft in een antwoord dat alle gegevens die zijn opgenomen in de antwoord- en instantiesecties van het antwoord, zijn geverifieerd door de DNS-server volgens het beleid van die server.
Verificatieketen Een keten van ondertekende en gevalideerde DNS-records die zich uitbreidt van een vooraf geconfigureerd vertrouwensanker naar een onderliggende zone in de DNS-structuur.
DNS-extensie (EDNS0) Een DNS-record met uitgebreide DNS-headergegevens, zoals de DO-bit en de maximale UDP-pakketgrootte.
DNS-beveiligingsextensies (DNSSEC) Extensies voor de DNS-service die mechanismen bieden voor ondertekening en voor het veilig omzetten van DNS-gegevens.
DNSSEC OK-bit (DO) Een beetje in het EDNS0-gedeelte van een DNS-aanvraag die aangeeft dat de client DNSSEC-bewust is.
DNSSEC-validatie DNSSEC-validatie is het proces van het verifiëren van de oorsprong en integriteit van DNS-gegevens met behulp van openbare cryptografische sleutels.
Eiland van veiligheid Een ondertekende zone die geen verificatieketen heeft van de bovenliggende zone.
Sleutelondertekeningssleutel (KSK) Een verificatiesleutel die overeenkomt met een persoonlijke sleutel die wordt gebruikt voor het ondertekenen van een of meer andere ondertekeningssleutels voor een bepaalde zone. Normaal gesproken ondertekent de persoonlijke sleutel die overeenkomt met een KSK een zone-ondertekeningssleutel (ZSK), die op zijn beurt een bijbehorende persoonlijke sleutel heeft die andere zonegegevens ondertekent. Lokaal beleid kan vereisen dat de ZSK regelmatig wordt gewijzigd, terwijl de KSK een langere geldigheidsperiode kan hebben om een stabieler, veilig toegangspunt in de zone te bieden. Het toewijzen van een verificatiesleutel als een KSK is puur een operationeel probleem: DNSSEC-validatie maakt geen onderscheid tussen KSK's en andere DNSSEC-verificatiesleutels. Het is mogelijk om één sleutel te gebruiken als zowel een KSK als een ZSK.
Niet-validerende beveiligingsbewuste stub-resolver Een beveiligingsbewuste stub-resolver die een of meer beveiligingsbewuste DNS-servers vertrouwt om DNSSEC-validatie namens hen uit te voeren.
SEP-sleutel (Secure Entry Point) Een subset van openbare sleutels binnen de DNSKEY RRSet. Een SEP-sleutel wordt gebruikt om een DS RR te genereren of wordt gedistribueerd naar resolvers die de sleutel gebruiken als vertrouwensanker.
Beveiligingsbewuste DNS-server Een DNS-server die de DNS-beveiligingsextensies implementeert zoals gedefinieerd in RFCs 4033 [5], 4034 [6] en 4035 [7]. Met name een beveiligingsbewuste DNS-server is een entiteit die DNS-query's ontvangt, DNS-antwoorden verzendt, de EDNS0 [3] berichtgrootte-extensie en de DO-bit ondersteunt, en ondersteunt de DNSSEC-recordtypen en berichtheader-bits.
Ondertekende zone Een zone waarvan de records zijn ondertekend zoals gedefinieerd door RFC 4035 [7] Sectie 2. Een ondertekende zone kan DNSKEY-, NSEC-, NSEC3-, NSEC3PARAM-, RRSIG- en DS-resourcerecords bevatten. Met deze resourcerecords kunnen DNS-gegevens worden gevalideerd door resolvers.
Vertrouwensanker Een vooraf geconfigureerde openbare sleutel die is gekoppeld aan een bepaalde zone. Met een vertrouwensanker kan een DNS-resolver ondertekende DNSSEC-bronrecords voor die zone valideren en verificatieketens bouwen naar onderliggende zones.
Niet-ondertekende zone Dns-zone die niet is ondertekend zoals gedefinieerd door RFC 4035 [7] Sectie 2.
Zoneondertekening Zoneondertekening is het proces voor het maken en toevoegen van DNSSEC-gerelateerde resourcerecords aan een zone, waardoor deze compatibel is met DNSSEC-validatie.
Zone ongedaan maken Zone ongedaan maken is het proces van het verwijderen van DNSSEC-gerelateerde bronrecords uit een zone, waarbij deze wordt hersteld naar een niet-ondertekende status.
Zone-ondertekeningssleutel (ZSK) Een verificatiesleutel die overeenkomt met een persoonlijke sleutel die wordt gebruikt om een zone te ondertekenen. Normaal gesproken maakt een zoneondertekeningssleutel deel uit van dezelfde DNSKEY RRSet als de sleutelondertekeningssleutel waarvan de bijbehorende persoonlijke sleutel deze DNSKEY RRSet ondertekent, maar de zoneondertekeningssleutel wordt gebruikt voor een iets ander doel en kan op andere manieren verschillen van de sleutelondertekeningssleutel, zoals de geldigheidsduur. Het aanwijzen van een verificatiesleutel als een zoneondertekeningssleutel is uitsluitend een operationeel probleem; DNSSEC-validatie maakt geen onderscheid tussen zoneondertekeningssleutels en andere DNSSEC-verificatiesleutels. Het is mogelijk om één sleutel te gebruiken als zowel een sleutel voor ondertekening als een zoneondertekeningssleutel.

Volgende stappen