Dela via

ÖVERSIKT ÖVER DNSSEC (förhandsversion)

  • Artikel

Den här artikeln innehåller en översikt över DNSSEC (Domain Name System Security Extensions) och innehåller en introduktion till DNSSEC-terminologi. Fördelarna med DNSSEC-zonsignering beskrivs och exempel ges för att visa DNSSEC-relaterade resursposter. När du är redo att signera din offentliga DNS-zon i Azure kan du läsa följande instruktionsguider:

Kommentar

DNSSEC-zonsignering är för närvarande i förhandsversion.
Juridiska villkor för Azure-funktioner i betaversion, förhandsversion eller som av någon annan anledning inte har gjorts allmänt tillgängliga ännu finns i kompletterande användningsvillkor för Microsoft Azure-förhandsversioner.

Vad är DNSSEC?

DNSSEC är en uppsättning tillägg som lägger till säkerhet i DNS-protokollet (Domain Name System) genom att göra det möjligt att verifiera DNS-svar som äkta. DNSSEC tillhandahåller ursprungsutfärdande, dataintegritet och autentiserat förnekande av existens. Med DNSSEC är DNS-protokollet mycket mindre känsligt för vissa typer av attacker, särskilt DNS-förfalskningsattacker.

De grundläggande DNSSEC-tilläggen anges i följande begäran om kommentarer (RFC):

  • RFC 4033: "INTRODUKTION och krav för DNS-säkerhet"
  • RFC 4034: "Resursposter för DNS-säkerhetstilläggen"
  • RFC 4035: "Protokolländringar för DNS-säkerhetstilläggen"

En sammanfattning av DNSSEC RFCs finns i RFC9364: DNS Security Extensions (DNSSEC).

Så här fungerar DNSSEC

DNS-zoner skyddas med DNSSEC med hjälp av en process som kallas zonsignering. Att signera en zon med DNSSEC lägger till valideringsstöd utan att ändra den grundläggande mekanismen för en DNS-fråga och ett DNS-svar. Om du vill signera en zon med DNSSEC måste zonens primära auktoritativa DNS-server ha stöd för DNSSEC.

Signaturer för resursposter (RRSIG) och andra kryptografiska poster läggs till i zonen när den signeras. Följande bild visar DNS-resursposter i zonen contoso.com före och efter zonsignering.

Ett diagram som visar hur RRSIG-poster läggs till i en zon när de signeras med DNSSEC.

DNSSEC-validering av DNS-svar sker med hjälp av dessa digitala signaturer med en obruten förtroendekedja.

Kommentar

DNSSEC-relaterade resursposter visas inte i Azure Portal. Mer information finns i Visa DNSSEC-relaterade resursposter.

Varför signerar du en zon med DNSSEC?

Signering av en zon med DNSSEC krävs för att följa vissa säkerhetsriktlinjer, till exempel SC-20: Secure Name/Address Resolution Service.

DNSSEC-validering av DNS-svar kan förhindra vanliga typer av DNS-kapningsattacker, även kallade DNS-omdirigering. DNS-kapning sker när en klientenhet omdirigeras till en skadlig server med hjälp av felaktiga (falska) DNS-svar. DNS-cacheförgiftning är en vanlig metod som används för att förfalska DNS-svar.

Ett exempel på hur DNS-kapning fungerar visas i följande bild.

Ett diagram som visar hur DNS-kapning fungerar.

Normal DNS-matchning:

  1. En klientenhet skickar en DNS-fråga för contoso.com till en DNS-server.
  2. DNS-servern svarar med en DNS-resurspost för contoso.com.
  3. Klientenheten begär ett svar från contoso.com.
  4. Contoso.com-appen eller webbservern returnerar ett svar till klienten.

DNS-kapning

  1. En klientenhet skickar en DNS-fråga för contoso.com till en kapad DNS-server.
  2. DNS-servern svarar med en ogiltig (förfalskad) DNS-resurspost för contoso.com.
  3. Klientenheten begär ett svar för contoso.com från skadlig server.
  4. Den skadliga servern returnerar ett förfalskningssvar till klienten.

Vilken typ av DNS-resurspost som är förfalskad beror på typen av DNS-kapningsattack. En MX-post kan förfalskas för att omdirigera klientmeddelanden, eller så kan en förfalskad A-post skicka klienter till en skadlig webbserver.

DNSSEC fungerar för att förhindra DNS-kapning genom att utföra validering på DNS-svar. I dns-kapningsscenariot som visas här kan klientenheten avvisa icke-verifierade DNS-svar om den contoso.com domänen är signerad med DNSSEC. Om du vill avvisa icke-verifierade DNS-svar måste klientenheten framtvinga DNSSEC-verifiering för contoso.com.

DNSSEC innehåller även Next Secure 3 (NSEC3) för att förhindra zonuppräkning. Zonuppräkning, även kallat zonvandring, är en attack där angriparen upprättar en lista över alla namn i en zon, inklusive underordnade zoner.

Innan du signerar en zon med DNSSEC måste du förstå hur DNSSEC fungerar. När du är redo att signera en zon kan du läsa Så här signerar du din offentliga DNS-zon i Azure med DNSSEC.

DNSSEC-validering

Om en DNS-server är DNSSEC-medveten kan den ange FLAGGAN DNSSEC OK (DO) i en DNS-fråga till värdet 1. Det här värdet talar om för den dns-server som svarar att inkludera DNSSEC-relaterade resursposter med svaret. Dessa DNSSEC-poster är RRSIG-poster (Resource Record Signature) som används för att verifiera att DNS-svaret är äkta.

En rekursiv (icke-auktoritativ) DNS-server utför DNSSEC-validering på RRSIG-poster med hjälp av ett förtroendeankare (DNSKEY). Servern använder en DNSKEY för att dekryptera digitala signaturer i RRSIG-poster (och andra DNSSEC-relaterade poster) och sedan beräknar och jämför hashvärden. Om hash-värden är desamma ger det ett svar till DNS-klienten med de DNS-data som begärdes, till exempel en värdadresspost (A). Se följande diagram:

Ett diagram som visar hur DNSSEC-validering fungerar.

Om hashvärdena inte är desamma svarar den rekursiva DNS-servern med ett SERVFAIL-meddelande. På så sätt kan DNSSEC-kompatibla DNS-servrar med ett giltigt förtroendeankare skydda mot DNS-kapning i sökvägen mellan den rekursiva servern och den auktoritativa servern. Det här skyddet kräver inte att DNS-klientenheter är DNSSEC-medvetna eller framtvingar DNS-svarsvalidering, förutsatt att den lokala rekursiva DNS-servern (last hop) i sig är säker från kapning.

Windows 10- och Windows 11-klientenheter är icke-validerande säkerhetsmedvetna stub-matchare. Dessa klientenheter utför inte verifiering, men kan framtvinga DNSSEC-validering med hjälp av grupprincip. NRPT kan användas för att skapa och framtvinga namnområdesbaserad DNSSEC-valideringsprincip.

Förtroendeankare och DNSSEC-validering

Kommentar

DNSSEC-svarsverifiering utförs inte av standardlösningslösningen som tillhandahålls av Azure. Informationen i det här avsnittet är användbar om du konfigurerar dina egna rekursiva DNS-servrar för DNSSEC-validering eller felsökning av valideringsproblem.

Förtroendeankare fungerar baserat på DNS-namnområdeshierarkin. En rekursiv DNS-server kan ha valfritt antal förtroendeankare eller inga förtroendeankare. Förtroendeankare kan läggas till för en enda underordnad DNS-zon eller valfri överordnad zon. Om en rekursiv DNS-server har ett rotförtroendeankare (.) kan den utföra DNSSEC-validering i valfri DNS-zon. Mer information finns i Information om rotzonsoperator.

DNSSEC-valideringsprocessen fungerar med förtroendeankare på följande sätt:

  • Om en rekursiv DNS-server inte har ett DNSSEC-förtroendeankare för en zon eller zonens överordnade hierarkiska namnområde utför den inte DNSSEC-validering i den zonen.
  • Om en rekursiv DNS-server har en DNSSEC-förtroendeankare för en zons överordnade namnområde och den tar emot en fråga för den underordnade zonen, kontrollerar den om en DS-post för de underordnade zonerna finns i den överordnade zonen.
    • Om DS-posten hittas utför den rekursiva DNS-servern DNSSEC-validering.
    • Om den rekursiva DNS-servern fastställer att den överordnade zonen inte har någon DS-post för den underordnade zonen förutsätter den att den underordnade zonen är osäker och inte utför DNSSEC-verifiering.
  • Om flera rekursiva DNS-servrar är inblandade i ett DNS-svar (inklusive vidarebefordrare) måste varje server kunna utföra DNSSEC-validering på svaret så att det finns en obruten förtroendekedja.
  • Rekursiva servrar som har DNSSEC-validering inaktiverade eller som inte är DNSSEC-medvetna utför inte validering.

Förtroendekedja

En förtroendekedja uppstår när alla DNS-servrar som är inblandade i att skicka ett svar för en DNS-fråga kan verifiera att svaret inte ändrades under överföringen. För att DNSSEC-valideringen ska fungera från slutpunkt till slutpunkt måste förtroendekedjan vara obruten. Den här förtroendekedjan gäller både auktoritativa och icke-auktoritativa (rekursiva) servrar.

Auktoritativa servrar

Auktoritativa DNS-servrar upprätthåller en förtroendekedja med hjälp av delegeringssigneringsposter (DS). DS-poster används för att verifiera äktheten för underordnade zoner i DNS-hierarkin.

  • För att DNSSEC-valideringen ska ske i en signerad zon måste även överordnad för den signerade zonen signeras. Den överordnade zonen måste också ha en DS-post för den underordnade zonen.
  • Under valideringsprocessen efterfrågas en zons överordnade för DS-posten. Om DS-posten inte finns, eller om DS-postdata i den överordnade posten inte matchar DNSKEY-data i den underordnade zonen, bryts förtroendekedjan och verifieringen misslyckas.

Rekursiva servrar

Rekursiva DNS-servrar (kallas även matchning eller cachelagring av DNS-servrar) upprätthåller en förtroendekedja med hjälp av DNSSEC-förtroendeankare.

  • Förtroendeankaret är en DNSKEY-post eller DS-post som innehåller en hash för en DNSKEY-post. DNSKEY-posten skapas på en auktoritativ server när en zon signeras och tas bort från zonen om zonen är osignerad.
  • Förtroendeankare måste installeras manuellt på rekursiva DNS-servrar.
  • Om det finns ett förtroendeankare för en överordnad zon kan en rekursiv server verifiera alla underordnade zoner i det hierarkiska namnområdet. Detta inkluderar vidarebefordrade frågor. För att stödja DNSSEC-validering av alla DNSSEC-signerade DNS-zoner kan du installera ett förtroendeankare för rotzonen (.).

Nyckelåterställning

Zonsigneringsnyckeln (ZSK) i en DNSSEC-signerad zon rullas regelbundet över (ersätts) automatiskt av Azure. Det bör inte vara nödvändigt att ersätta din nyckelsigneringsnyckel (KSK), men det här alternativet är tillgängligt genom att kontakta Microsofts support. Om du ersätter KSK måste du även uppdatera din DS-post i den överordnade zonen.

Algoritm för zonsignering

Zoner är DNSSEC-signerade med Elliptic Curve Digital Signature Algorithm (ECDSAP256SHA256).

Följande tabell innehåller en kort beskrivning av DNSSEC-relaterade poster. Mer detaljerad information finns i RFC 4034: Resursposter för DNS-säkerhetstillägg och RFC 7344: Automatisera underhåll av DNSSEC-delegeringsförtroende.

Post beskrivning
Resurspostsignatur (RRSIG) En DNSSEC-resursposttyp som används för att lagra en signatur, som omfattar en uppsättning DNS-poster för ett visst namn och en viss typ.
DNSKEY En DNSSEC-resursposttyp som används för att lagra en offentlig nyckel.
Delegeringssignerare (DS) En DNSSEC-resursposttyp som används för att skydda en delegering.
Nästa säkra (NSEC) En DNSSEC-resursposttyp som används för att bevisa att det inte finns något DNS-namn.
Nästa säkra 3 (NSEC3) NSEC3-resursposten som tillhandahåller hashad, autentiserad överbelastning av existens för DNS-resurspostuppsättningar.
Nästa säkra 3 parametrar (NSEC3PARAM) Anger parametrar för NSEC3-poster.
Underordnad delegeringssignerare (CDS) Den här posten är valfri. Om den finns kan CDS-posten användas av en underordnad zon för att ange önskat innehåll i DS-posten i en överordnad zon.
Underordnad DNSKEY (CDNSKEY) Den här posten är valfri. Om CDNSKEY-posten finns i en underordnad zon kan den användas för att generera en DS-post från en DNSKEY-post.

DNSSEC-relaterade poster visas inte i Azure Portal. Om du vill visa DNSSEC-relaterade poster använder du kommandoradsverktyg som Resolve-DnsName eller dig.exe. De här verktygen är tillgängliga med Cloud Shell eller lokalt om de är installerade på enheten. Se till att ange DO-flaggan i frågan med hjälp -dnssecok av alternativet i Resolve-DnsName eller +dnssec alternativet i dig.exe.

Viktigt!

Använd inte kommandoradsverktyget nslookup.exe för att fråga efter DNSSEC-relaterade poster. Verktyget nslookup.exe använder en intern DNS-klient som inte är DNSSEC-medveten.

Se följande exempel:

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-terminologi

Den här listan tillhandahålls för att förstå några av de vanliga termer som används när du diskuterar DNSSEC. Se även: DNSSEC-relaterade resursposter

Period beskrivning
Autentiserad databit (AD) En databit som i ett svar anger att alla data som ingår i svars- och utfärdaravsnitten i svaret har autentiserats av DNS-servern enligt serverns principer.
Autentiseringskedja En kedja med signerade och verifierade DNS-poster som sträcker sig från en förkonfigurerad förtroendeankare till någon underordnad zon i DNS-trädet.
DNS-tillägg (EDNS0) En DNS-post som innehåller utökad DNS-rubrikinformation, till exempel DO-bitar och maximal UDP-paketstorlek.
DNS-säkerhetstillägg (DNSSEC) Tillägg till DNS-tjänsten som tillhandahåller mekanismer för signering och för säker matchning av DNS-data.
DNSSEC OK-bit (DO) Lite i EDNS0-delen av en DNS-begäran som signalerar att klienten är DNSSEC-medveten.
DNSSEC-validering DNSSEC-validering är processen för att verifiera dns-datas ursprung och integritet med hjälp av offentliga kryptografiska nycklar.
Ö av säkerhet En signerad zon som inte har någon autentiseringskedja från den delegerande överordnade zonen.
Nyckelsigneringsnyckel (KSK) En autentiseringsnyckel som motsvarar en privat nyckel som används för att signera en eller flera andra signeringsnycklar för en viss zon. Vanligtvis signerar den privata nyckel som motsvarar en KSK en zonsigneringsnyckel (ZSK), som i sin tur har en motsvarande privat nyckel som signerar andra zondata. Lokal princip kan kräva att ZSK ändras ofta, medan KSK kan ha en längre giltighetsperiod för att tillhandahålla en stabilare och säkrare startpunkt i zonen. Att ange en autentiseringsnyckel som en KSK är bara ett driftproblem: DNSSEC-verifiering skiljer inte mellan KSK:er och andra DNSSEC-autentiseringsnycklar. Det är möjligt att använda en enda nyckel som både en KSK och en ZSK.
Icke-validerande säkerhetsmedveten stub resolver En säkerhetsmedveten stub-matchare som litar på att en eller flera säkerhetsmedvetna DNS-servrar utför DNSSEC-verifiering för dess räkning.
säker startpunktsnyckel (SEP) En delmängd av offentliga nycklar i DNSKEY RRSet. En SEP-nyckel används antingen för att generera en DS RR eller distribueras till matchare som använder nyckeln som ett förtroendeankare.
Säkerhetsmedveten DNS-server En DNS-server som implementerar DNS-säkerhetstilläggen enligt definitionen i RFCs 4033 [5], 4034 [6] och 4035 [7]. I synnerhet är en säkerhetsmedveten DNS-server en entitet som tar emot DNS-frågor, skickar DNS-svar, stöder EDNS0 -meddelandestorlekstillägget [3] och DO-biten och stöder DNSSEC-posttyper och meddelandehuvudbitar.
Signerad zon En zon vars poster är signerade enligt definitionen i RFC 4035 [7] Avsnitt 2. En signerad zon kan innehålla resursposterna DNSKEY, NSEC, NSEC3, NSEC3PARAM, RRSIG och DS. Dessa resursposter gör att DNS-data kan verifieras av matchare.
Förtroendeankare En förkonfigurerad offentlig nyckel som är associerad med en viss zon. Med ett förtroendeankare kan en DNS-matchare verifiera signerade DNSSEC-resursposter för den zonen och skapa autentiseringskedjor till underordnade zoner.
Osignerad zon Alla DNS-zoner som inte har signerats enligt definitionen i RFC 4035 [7] Avsnitt 2.
Zonsignering Zonsignering är processen att skapa och lägga till DNSSEC-relaterade resursposter i en zon, vilket gör den kompatibel med DNSSEC-validering.
Avsignering av zon Zonens avsignering är processen att ta bort DNSSEC-relaterade resursposter från en zon och återställa den till en osignerad status.
Zonsigneringsnyckel (ZSK) En autentiseringsnyckel som motsvarar en privat nyckel som används för att signera en zon. Vanligtvis är en zonsigneringsnyckel en del av samma DNSKEY RRSet som nyckelsigneringsnyckeln vars motsvarande privata nyckel signerar denna DNSKEY RRSet, men zonsigneringsnyckeln används för ett något annat syfte och kan skilja sig från nyckelsigneringsnyckeln på andra sätt, till exempel i giltighetens livslängd. Att utse en autentiseringsnyckel som en zonsigneringsnyckel är bara ett driftproblem. DNSSEC-validering skiljer inte mellan zonsigneringsnycklar och andra DNSSEC-autentiseringsnycklar. Det är möjligt att använda en enda nyckel som både en nyckelsigneringsnyckel och en zonsigneringsnyckel.

Nästa steg