Udostępnij za pośrednictwem

Omówienie protokołu DNSSEC (wersja zapoznawcza)

  • Artykuł

Ten artykuł zawiera omówienie rozszerzeń zabezpieczeń systemu nazw domen (DNSSEC) i zawiera wprowadzenie do terminologii DNSSEC. Opisano zalety podpisywania strefy DNSSEC i podano przykłady wyświetlania rekordów zasobów powiązanych z protokołem DNSSEC. Gdy wszystko będzie gotowe do podpisania publicznej strefy DNS platformy Azure, zobacz następujące przewodniki z instrukcjami:

Uwaga

Podpisywanie strefy DNSSEC jest obecnie dostępne w wersji ZAPOZNAWCZEJ.
Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.

Co to jest protokół DNSSEC?

DNSSEC to zestaw rozszerzeń, które dodają zabezpieczenia do protokołu DNS (Domain Name System), umożliwiając weryfikowanie odpowiedzi DNS jako prawdziwe. Protokół DNSSEC zapewnia urząd pochodzenia, integralność danych i uwierzytelnioną odmowę istnienia. W przypadku protokołu DNSSEC protokół DNS jest znacznie mniej podatny na niektóre typy ataków, szczególnie ataki fałszujące DNS.

Podstawowe rozszerzenia DNSSEC są określone w następującym żądaniu komentarzy (RFC):

  • RFC 4033: "Wprowadzenie i wymagania dotyczące zabezpieczeń DNS"
  • RFC 4034: "Rekordy zasobów dla rozszerzeń zabezpieczeń DNS"
  • RFC 4035: "Modyfikacje protokołu dla rozszerzeń zabezpieczeń DNS"

Aby uzyskać podsumowanie RFC protokołu DNSSEC, zobacz RFC9364: Rozszerzenia zabezpieczeń DNS (DNSSEC).

Jak działa protokół DNSSEC

Strefy DNS są zabezpieczone przy użyciu protokołu DNSSEC przy użyciu procesu nazywanego podpisywaniem strefy. Podpisywanie strefy przy użyciu protokołu DNSSEC dodaje obsługę walidacji bez zmiany podstawowego mechanizmu zapytania DNS i odpowiedzi. Aby podpisać strefę przy użyciu protokołu DNSSEC, podstawowy autorytatywny serwer DNS strefy musi obsługiwać protokół DNSSEC.

Podpisy rekordów zasobów (RRSIG) i inne rekordy kryptograficzne są dodawane do strefy po jego podpisaniu. Na poniższej ilustracji przedstawiono rekordy zasobów DNS w strefie contoso.com przed i po podpisaniu strefy.

Diagram przedstawiający sposób dodawania rekordów RRSIG do strefy po jej podpisaniu przy użyciu protokołu DNSSEC.

Sprawdzanie poprawności odpowiedzi DNSSEC odbywa się przy użyciu tych podpisów cyfrowych z nierozwiązanym łańcuchem zaufania.

Uwaga

Rekordy zasobów związane z protokołem DNSSEC nie są wyświetlane w witrynie Azure Portal. Aby uzyskać więcej informacji, zobacz Wyświetlanie rekordów zasobów związanych z protokołem DNSSEC.

Dlaczego warto podpisać strefę przy użyciu protokołu DNSSEC?

Podpisywanie strefy przy użyciu protokołu DNSSEC jest wymagane w celu zachowania zgodności z niektórymi wytycznymi dotyczącymi zabezpieczeń, takimi jak SC-20: Secure Name/Address Resolution Service.

Weryfikacja dnsSEC odpowiedzi DNS może zapobiec typowym typom ataków przejęcia DNS, nazywanych również przekierowywaniem DNS. Przejęcie dns występuje, gdy urządzenie klienckie jest przekierowywane do złośliwego serwera przy użyciu nieprawidłowych (sfałszowanych) odpowiedzi DNS. Zatrucie pamięci podręcznej DNS to typowa metoda używana do fałszowania odpowiedzi DNS.

Przykład działania porwania DNS przedstawiono na poniższej ilustracji.

Diagram przedstawiający sposób działania porwania DNS.

Normalne rozpoznawanie nazw DNS:

  1. Urządzenie klienckie wysyła zapytanie DNS dla contoso.com do serwera DNS.
  2. Serwer DNS odpowiada za pomocą rekordu zasobu DNS dla contoso.com.
  3. Urządzenie klienckie żąda odpowiedzi z contoso.com.
  4. Aplikacja contoso.com lub serwer internetowy zwraca odpowiedź na klienta.

Przejęcie DNS

  1. Urządzenie klienckie wysyła zapytanie DNS dla contoso.com do porwanego serwera DNS.
  2. Serwer DNS odpowiada nieprawidłowym (sfałszowany) rekordem zasobu DNS dla contoso.com.
  3. Urządzenie klienckie żąda odpowiedzi na contoso.com ze złośliwego serwera.
  4. Złośliwy serwer zwraca sfałszowaną odpowiedź na klienta.

Typ rekordu zasobu DNS, który jest fałszowany, zależy od typu ataku przejęcia DNS. Rekord MX może zostać sfałszowany w celu przekierowania wiadomości e-mail klienta lub sfałszowany rekord A może wysyłać klientów do złośliwego serwera internetowego.

Protokół DNSSEC działa, aby zapobiec przejęciom DNS przez przeprowadzenie walidacji odpowiedzi DNS. W scenariuszu przejęcia DNS na zdjęciu tutaj urządzenie klienckie może odrzucić niewalidowane odpowiedzi DNS, jeśli domena contoso.com jest podpisana przy użyciu protokołu DNSSEC. Aby odrzucić niewalidowane odpowiedzi DNS, urządzenie klienckie musi wymusić weryfikację protokołu DNSSEC dla contoso.com.

Protokół DNSSEC zawiera również protokół Next Secure 3 (NSEC3), aby zapobiec wyliczaniu strefy. Wyliczenie strefy, znane również jako chodzenie po strefie, to atak polegający na tym, że osoba atakująca ustanawia listę wszystkich nazw w strefie, w tym strefy podrzędne.

Przed podpisaniem strefy przy użyciu protokołu DNSSEC upewnij się, że wiesz , jak działa protokół DNSSEC. Gdy wszystko będzie gotowe do podpisania strefy, zobacz Jak podpisać publiczną strefę DNS platformy Azure przy użyciu protokołu DNSSEC.

Walidacja protokołu DNSSEC

Jeśli serwer DNS obsługuje protokół DNSSEC, może ustawić flagę DNSSEC OK (DO) w zapytaniu DNS na wartość 1. Ta wartość informuje serwer DNS o konieczności uwzględnienia rekordów zasobów związanych z protokołem DNSSEC z odpowiedzią. Te rekordy DNSSEC to rekordy sygnatury rekordów zasobów (RRSIG), które są używane do sprawdzania, czy odpowiedź DNS jest prawdziwa.

Serwer DNS rekursywny (nieautorytatywny) przeprowadza walidację protokołu DNSSEC na rekordach RRSIG przy użyciu kotwicy zaufania (DNSKEY). Serwer używa klucza DNSKEY do odszyfrowywania podpisów cyfrowych w rekordach RRSIG (i innych rekordów związanych z protokołem DNSSEC), a następnie oblicza i porównuje wartości skrótu. Jeśli wartości skrótu są takie same, zapewnia odpowiedź klientowi DNS z żądanymi danymi DNS, takimi jak rekord adresu hosta (A). Zobacz następujący diagram:

Diagram przedstawiający sposób działania walidacji protokołu DNSSEC.

Jeśli wartości skrótu nie są takie same, cykliczny serwer DNS odpowiada komunikatem SERVFAIL. W ten sposób serwery DNSSEC rozpoznające (lub przekazujące) serwery DNS z zainstalowaną prawidłową kotwicą zaufania mogą chronić przed przejęciem DNS w ścieżce między serwerem rekursywnym a serwerem autorytatywnym. Ta ochrona nie wymaga, aby urządzenia klienckie DNS uwzględniały protokół DNSSEC ani wymuszały weryfikację odpowiedzi DNS, pod warunkiem że lokalny (ostatni przeskok) rekursywny serwer DNS jest sam bezpieczny przed przejęciem.

Urządzenia klienckie z systemami Windows 10 i Windows 11 nie sąvalidacjami rozpoznawania wycinków obsługujących zabezpieczenia. Te urządzenia klienckie nie przeprowadzają walidacji, ale mogą wymuszać walidację protokołu DNSSEC przy użyciu zasad grupy. Element NRPT może służyć do tworzenia i wymuszania zasad weryfikacji DNSSEC opartych na przestrzeni nazw.

Kotwice zaufania i walidacja protokołu DNSSEC

Uwaga

Walidacja odpowiedzi DNSSEC nie jest wykonywana przez domyślny program rozpoznawania nazw udostępnianych przez platformę Azure. Informacje przedstawione w tej sekcji są przydatne, jeśli konfigurujesz własne rekursywne serwery DNS na potrzeby walidacji protokołu DNSSEC lub rozwiążesz problemy z walidacją.

Kotwice zaufania działają na podstawie hierarchii przestrzeni nazw DNS. Cykliczny serwer DNS może mieć dowolną liczbę kotwic zaufania lub nie ma kotwic zaufania. Kotwice zaufania można dodać dla pojedynczej podrzędnej strefy DNS lub dowolnej strefy nadrzędnej. Jeśli cykliczny serwer DNS ma kotwicę zaufania głównego (.), może przeprowadzić walidację protokołu DNSSEC w dowolnej strefie DNS. Aby uzyskać więcej informacji, zobacz Informacje o operatorze strefy głównej.

Proces weryfikacji protokołu DNSSEC działa z kotwicami zaufania w następujący sposób:

  • Jeśli cykliczny serwer DNS nie ma kotwicy zaufania DNSSEC dla strefy lub nadrzędnej przestrzeni nazw hierarchicznej strefy, nie wykona walidacji PROTOKOŁU DNSSEC w tej strefie.
  • Jeśli cykliczny serwer DNS ma kotwicę zaufania DNSSEC dla nadrzędnej przestrzeni nazw strefy i odbiera zapytanie dla strefy podrzędnej, sprawdza, czy rekord DS dla stref podrzędnych jest obecny w strefie nadrzędnej.
    • Jeśli rekord DS zostanie znaleziony, rekursywny serwer DNS przeprowadza walidację PROTOKOŁU DNSSEC.
    • Jeśli cykliczny serwer DNS ustali, że strefa nadrzędna nie ma rekordu DS dla strefy podrzędnej, zakłada, że strefa podrzędna jest niezabezpieczona i nie wykonuje walidacji PROTOKOŁU DNSSEC.
  • Jeśli w odpowiedzi DNS jest zaangażowanych wiele cyklicznych serwerów DNS (w tym usług przesyłania dalej), każdy serwer musi mieć możliwość przeprowadzenia weryfikacji protokołu DNSSEC w odpowiedzi, aby istniał niezwiązany łańcuch zaufania.
  • Serwery cykliczne, które mają wyłączoną walidację protokołu DNSSEC lub nie są obsługujące protokołu DNSSEC, nie przeprowadzają walidacji.

Łańcuch zaufania

Łańcuch zaufania występuje, gdy wszystkie serwery DNS zaangażowane w wysyłanie odpowiedzi dla zapytania DNS są w stanie sprawdzić, czy odpowiedź nie została zmodyfikowana podczas przesyłania. Aby weryfikacja protokołu DNSSEC działała kompleksowo, łańcuch zaufania musi zostać zdjęty. Ten łańcuch zaufania dotyczy zarówno autorytatywnych, jak i nieautorytatywnych (cyklicznych) serwerów.

Serwery autorytatywne

Autorytatywne serwery DNS utrzymują łańcuch zaufania za pomocą rekordów osoby podpisujące delegowanie (DS). Rekordy DS służą do weryfikowania autentyczności stref podrzędnych w hierarchii DNS.

  • Aby walidacja protokołu DNSSEC odbywała się w strefie podpisanej, należy również podpisać element nadrzędny podpisanej strefy. Strefa nadrzędna musi również mieć rekord DS dla strefy podrzędnej.
  • Podczas procesu sprawdzania poprawności obiekt nadrzędny strefy jest odpytywane dla rekordu DS. Jeśli rekord DS nie jest obecny lub dane rekordu DS w obiekcie nadrzędnym nie są zgodne z danymi DNSKEY w strefie podrzędnej, łańcuch zaufania zostanie przerwany i walidacja zakończy się niepowodzeniem.

Serwery cykliczne

Rekursywne serwery DNS (nazywane również rozpoznawaniem lub buforowaniem serwerów DNS) utrzymują łańcuch zaufania za pomocą kotwic zaufania DNSSEC.

  • Kotwica zaufania jest rekordem DNSKEY lub rekordem DS zawierającym skrót rekordu DNSKEY. Rekord DNSKEY jest tworzony na serwerze autorytatywnym po podpisaniu strefy i usunięty ze strefy, jeśli strefa jest niepodpisane.
  • Kotwice zaufania muszą być instalowane ręcznie na rekursywnych serwerach DNS.
  • Jeśli istnieje kotwica zaufania dla strefy nadrzędnej, serwer rekursywny może zweryfikować wszystkie strefy podrzędne w hierarchicznej przestrzeni nazw. Obejmuje to zapytania przekazywane. Aby obsługiwać walidację protokołu DNSSEC wszystkich stref DNSSEC z podpisem DNS, można zainstalować kotwicę zaufania dla strefy głównej (.).

Przerzucanie klucza

Klucz podpisywania strefy (ZSK) w strefie z podpisem DNSSEC jest okresowo przerzucany (zastąpiony) automatycznie przez platformę Azure. Nie należy zastępować klucza podpisywania klucza (KSK), ale ta opcja jest dostępna, kontaktując się z pomocą techniczną firmy Microsoft. Zastąpienie KSK wymaga również zaktualizowania rekordu DS w strefie nadrzędnej.

Algorytm podpisywania strefy

Strefy są podpisane przez protokół DNSSEC przy użyciu algorytmu podpisu cyfrowego krzywej eliptycznej (ECDSAP256SHA256).

Poniższa tabela zawiera krótki opis rekordów związanych z protokołem DNSSEC. Aby uzyskać bardziej szczegółowe informacje, zobacz RFC 4034: Resource Records for the DNS Security Extensions (Rekordy zasobów dla rozszerzeń zabezpieczeń DNS) i RFC 7344: Automating DNSSEC Delegation Trust Maintenance (Automatyzacja konserwacji zaufania delegowania protokołu DNSSEC).

Nagraj opis
Sygnatura rekordu zasobu (RRSIG) Typ rekordu zasobu DNSSEC używany do przechowywania podpisu, który obejmuje zestaw rekordów DNS dla określonej nazwy i typu.
KLUCZ DNS Typ rekordu zasobu DNSSEC używany do przechowywania klucza publicznego.
Podpisywanie delegowania (DS) Typ rekordu zasobu DNSSEC używany do zabezpieczania delegowania.
Następne bezpieczne (NSEC) Typ rekordu zasobu DNSSEC używany do udowodnienia braku nazwy DNS.
Następne bezpieczne 3 (NSEC3) Rekord zasobu NSEC3, który zapewnia skrót, uwierzytelniony odmowa istnienia dla zestawów rekordów zasobów DNS.
Następne bezpieczne 3 parametry (NSEC3PARAM) Określa parametry rekordów NSEC3.
Podrzędny element podpisywania delegowania (CDS) Ten rekord jest opcjonalny. Jeśli istnieje, rekord CDS może być używany przez strefę podrzędną do określenia żądanej zawartości rekordu DS w strefie nadrzędnej.
Podrzędny klucz DNSKEY (CDNSKEY) Ten rekord jest opcjonalny. Jeśli rekord CDNSKEY znajduje się w strefie podrzędnej, można go użyć do wygenerowania rekordu DS z rekordu DNSKEY.

Rekordy związane z protokołem DNSSEC nie są wyświetlane w witrynie Azure Portal. Aby wyświetlić rekordy związane z protokołem DNSSEC, użyj narzędzi wiersza polecenia, takich jak Resolve-DnsName lub dig.exe. Te narzędzia są dostępne przy użyciu usługi Cloud Shell lub lokalnie, jeśli są zainstalowane na urządzeniu. Pamiętaj, aby ustawić flagę DO w zapytaniu przy użyciu -dnssecok opcji Resolve-DnsName lub +dnssec opcji w dig.exe.

Ważne

Nie używaj narzędzia wiersza polecenia nslookup.exe do wykonywania zapytań dotyczących rekordów związanych z protokołem DNSSEC. Narzędzie nslookup.exe używa wewnętrznego klienta DNS, który nie jest świadomy protokołu DNSSEC.

Zobacz poniższe przykłady:

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

Terminologia protokołu DNSSEC

Ta lista ułatwia zrozumienie niektórych typowych terminów używanych podczas omawiania protokołu DNSSEC. Zobacz też: Rekordy zasobów związane z protokołem DNSSEC

Okres opis
Bit uwierzytelnionych danych (AD) Bit danych wskazujący w odpowiedzi, że wszystkie dane zawarte w sekcjach odpowiedzi i urzędu odpowiedzi zostały uwierzytelnione przez serwer DNS zgodnie z zasadami tego serwera.
Łańcuch uwierzytelniania Łańcuch podpisanych i zweryfikowanych rekordów DNS, który rozciąga się od wstępnie skonfigurowanej kotwicy zaufania do jakiejś strefy podrzędnej w drzewie DNS.
Rozszerzenie DNS (EDNS0) Rekord DNS, który zawiera rozszerzone informacje nagłówka DNS, takie jak bit DO i maksymalny rozmiar pakietu UDP.
Rozszerzenia zabezpieczeń DNS (DNSSEC) Rozszerzenia usługi DNS, które zapewniają mechanizmy podpisywania i bezpiecznego rozpoznawania danych DNS.
Bit DNSSEC OK (DO) Bit w części EDNS0 żądania DNS, który sygnalizuje, że klient jest obsługujący protokół DNSSEC.
Walidacja protokołu DNSSEC Weryfikacja protokołu DNSSEC to proces weryfikowania źródła i integralności danych DNS przy użyciu publicznych kluczy kryptograficznych.
Wyspa bezpieczeństwa Podpisana strefa, która nie ma łańcucha uwierzytelniania z delegowania strefy nadrzędnej.
Klucz podpisywania klucza (KSK) Klucz uwierzytelniania odpowiadający kluczowi prywatnemu używanemu do podpisywania co najmniej jednego innego klucza podpisywania dla danej strefy. Zazwyczaj klucz prywatny odpowiadający KSK podpisuje klucz podpisywania strefy (ZSK), który z kolei ma odpowiedni klucz prywatny, który podpisuje inne dane strefy. Zasady lokalne mogą wymagać częstego zmieniania ZSK, podczas gdy KSK może mieć dłuższy okres ważności, aby zapewnić bardziej stabilny, bezpieczny punkt wejścia do strefy. Wyznaczanie klucza uwierzytelniania jako KSK jest wyłącznie problemem operacyjnym: weryfikacja protokołu DNSSEC nie rozróżnia zestawów KSKs i innych kluczy uwierzytelniania DNSSEC. Można użyć pojedynczego klucza zarówno jako KSK, jak i ZSK.
Niewalejące rozpoznawanie wycinków obsługujących zabezpieczenia Rozpoznawanie zabezpieczeń programu rozpoznawania wycinków, które ufa co najmniej jednemu serwerowi DNS obsługującemu zabezpieczenia w celu przeprowadzenia weryfikacji protokołu DNSSEC w jego imieniu.
klucz bezpiecznego punktu wejścia (SEP) Podzbiór kluczy publicznych w zestawie RRSet DNSKEY. Klucz SEP służy do generowania RR DS lub jest dystrybuowany w celu rozpoznawania nazw używających klucza jako kotwicy zaufania.
Serwer DNS obsługujący zabezpieczenia Serwer DNS, który implementuje rozszerzenia zabezpieczeń DNS zgodnie z definicją w rfCs 4033 [5], 4034 [6] i 4035 [7]. W szczególności serwer DNS obsługujący zabezpieczenia jest jednostką, która odbiera zapytania DNS, wysyła odpowiedzi DNS, obsługuje rozszerzenie rozmiaru komunikatów EDNS0 [3] i bit DO oraz obsługuje typy rekordów DNSSEC i bity nagłówków komunikatów.
Podpisana strefa Strefa, w której rekordy są podpisane zgodnie z definicją RFC 4035 [7] Sekcja 2. Podpisana strefa może zawierać rekordy zasobów DNSKEY, NSEC, NSEC3, NSEC3PARAM, RRSIG i DS. Te rekordy zasobów umożliwiają weryfikowanie danych DNS przez program rozpoznawania nazw.
Kotwica zaufania Wstępnie skonfigurowany klucz publiczny skojarzony z określoną strefą. Kotwica zaufania umożliwia rozpoznawaniu nazw DNS weryfikowanie podpisanych rekordów zasobów DNSSEC dla tej strefy i tworzenie łańcuchów uwierzytelniania w strefach podrzędnych.
Strefa niepodpisane Każda strefa DNS, która nie została podpisana zgodnie z definicją w dokumencie RFC 4035 [7] Sekcja 2.
Podpisywanie strefy Podpisywanie strefy to proces tworzenia i dodawania rekordów zasobów związanych z protokołem DNSSEC do strefy, dzięki czemu jest zgodny z weryfikacją protokołu DNSSEC.
Anulowanie znaku strefy Anulowanie znaku strefy to proces usuwania rekordów zasobów związanych z protokołem DNSSSEC ze strefy, przywracając go do stanu niepodpisanego.
Klucz podpisywania strefy (ZSK) Klucz uwierzytelniania odpowiadający kluczowi prywatnemu używanemu do podpisywania strefy. Zazwyczaj klucz podpisywania strefy jest częścią tego samego zestawu DNSKEY RRSet co klucz podpisywania klucza, którego odpowiedni klucz prywatny podpisuje ten klucz DNSKEY RRSet, ale klucz podpisywania strefy jest używany do nieco innego celu i może różnić się od klucza podpisywania kluczy w inny sposób, na przykład w okresie istnienia ważności. Projektowanie klucza uwierzytelniania jako klucza podpisywania strefy jest wyłącznie problemem operacyjnym; Walidacja protokołu DNSSEC nie rozróżnia kluczy podpisywania strefy i innych kluczy uwierzytelniania DNSSEC. Można użyć pojedynczego klucza zarówno jako klucza podpisywania klucza, jak i klucza podpisywania strefy.

Następne kroki