이 문서에서는 DNSSEC(Domain Name System 보안 확장 프로그램)에 대해 간략하게 설명하고 DNSSEC 용어에 대한 소개를 포함합니다. DNSSEC 영역 서명의 이점에 대해 설명하고 DNSSEC 관련 리소스 레코드를 보는 방법에 대한 예를 제공합니다. Azure 공용 DNS 영역에 서명할 준비가 되면 다음 방법 가이드를 참조하세요.
DNSSEC이란?
DNSSEC은 DNS 응답이 진짜인지 유효성을 검사할 수 있도록 하여 DNS(Domain Name System) 프로토콜에 보안을 추가하는 확장 기능 모음입니다. DNSSEC은 원본 권한, 데이터 무결성 및 부재 인증을 제공합니다. DNSSEC을 사용하면 DNS 프로토콜이 특정 형식의 공격, 특히 DNS 스푸핑 공격에 훨씬 덜 취약해집니다.
핵심 DNSSEC 확장은 다음의 RFC(Request for Comments)에 명시되어 있습니다.
- RFC 4033: "DNS 보안 소개 및 요구 사항"
- RFC 4034: "DNS 보안 확장을 위한 리소스 레코드"
- RFC 4035: "DNS 보안 확장을 위한 프로토콜 수정"
- RFC 9824: "DNSSEC의 컴팩트한 존재 거부"
DNSSEC RFC 요약은 RFC9364: DNSSEC(DNS 보안 확장 프로그램)을 참조하세요.
DNSSEC 작동 방식
DNS 영역은 영역 서명이라는 프로세스를 사용하여 DNSSEC로 보호됩니다. DNSSEC로 영역에 서명하면 DNS 쿼리 및 응답의 기본 메커니즘을 변경하지 않고도 유효성 검사 지원이 추가됩니다. DNSSEC로 영역에 서명하려면 해당 영역의 주요 권한 DNS 서버가 DNSSEC를 지원해야 합니다.
영역이 서명되면 RRSIG(리소스 레코드 서명) 및 기타 암호화 레코드가 영역에 추가됩니다. 다음 그림은 contoso.com 영역의 DNS 리소스 레코드를 영역 서명 전후로 보여 줍니다.
DNS 응답의 DNSSEC 유효성 검사는 끊김 없는 신뢰 체인을 통해 이러한 디지털 서명을 사용하여 수행됩니다.
참고
DNSSEC 관련 리소스 레코드는 Azure Portal에 표시되지 않습니다. 자세한 내용은 DNSSEC 관련 리소스 레코드 보기를 참조하세요.
DNSSEC로 영역에 서명하는 이유는 무엇인가요?
SC-20: 보안 이름/주소 확인 서비스와 같은 일부 보안 지침을 준수하려면 DNSSEC로 영역에 서명해야 합니다.
DNS 응답에 대한 DNSSEC 유효성 검사를 통해 DNS 리디렉션이라고도 알려진 일반적인 형식의 DNS 하이재킹 공격을 방지할 수 있습니다. DNS 하이재킹은 잘못된(스푸핑된) DNS 응답을 사용하여 클라이언트 디바이스가 악성 서버로 리디렉션될 때 발생합니다. DNS 캐시 포이즈닝은 DNS 응답을 스푸핑하는 데 사용되는 일반적인 방법입니다.
DNS 하이재킹이 작동하는 방식의 예는 다음 그림에 나와 있습니다.
일반 DNS 확인:
- 클라이언트 디바이스는 contoso.com에 대한 DNS 쿼리를 DNS 서버로 보냅니다.
- DNS 서버는 contoso.com에 대한 DNS 리소스 레코드로 응답합니다.
- 클라이언트 디바이스는 contoso.com에서 응답을 요청합니다.
- contoso.com 앱이나 웹 서버는 클라이언트에 응답을 반환합니다.
DNS 하이재킹
- 클라이언트 디바이스는 해킹된 DNS 서버로 contoso.com에 대한 DNS 쿼리를 보냅니다.
- DNS 서버는 contoso.com에 대한 잘못된(스푸핑된) DNS 리소스 레코드로 응답합니다.
- 클라이언트 디바이스는 악성 서버에서 contoso.com에 대한 응답을 요청합니다.
- 악성 서버는 클라이언트에게 위조된 응답을 반환합니다.
스푸핑되는 DNS 리소스 레코드의 형식은 DNS 하이재킹 공격의 형식에 따라 달라집니다. MX 레코드가 스푸핑되어 클라이언트 이메일을 리디렉션할 수도 있고, 스푸핑된 A 레코드가 클라이언트를 악성 웹 서버로 보낼 수도 있습니다.
DNSSEC은 DNS 응답에 대한 유효성 검사를 수행하여 DNS 하이재킹을 방지합니다. 여기에 나와 있는 DNS 하이재킹 시나리오에서 contoso.com 도메인이 DNSSEC로 서명된 경우 클라이언트 디바이스는 유효성 검사되지 않은 DNS 응답을 거부할 수 있습니다. 유효성 검사되지 않은 DNS 응답을 거부하려면 클라이언트 디바이스에서 contoso.com에 대한 DNSSEC 유효성 검사를 적용해야 합니다.
Azure DNS DNSSEC는 영역 열거를 방지하기 위해 RFC 9824를 구현했습니다. 영역 열거형, 영역 트래버스라고도 불리는 공격은 공격자가 자식 영역을 포함하여 영역에 있는 모든 이름 목록을 작성하려는 공격입니다.
DNSSEC로 영역에 서명하기 전에 DNSSEC가 작동하는 방식을 이해해야 합니다. 영역에 서명할 준비가 되면 DNSSEC를 사용하여 Azure 공용 DNS 영역에 서명하는 방법을 참조하세요.
DNSSEC 유효성 검사
DNS 서버가 DNSSEC를 인식하는 경우 DNS 쿼리에서 DO(DNSSEC 확인) 플래그를 1 값으로 설정할 수 있습니다. 이 값은 응답하는 DNS 서버에 응답에 DNSSEC 관련 리소스 레코드를 포함하도록 지시합니다. 이러한 DNSSEC 레코드는 DNS 응답이 진짜인지 유효성을 검사하는 데 사용되는 RRSIG(리소스 레코드 서명) 레코드입니다.
재귀적(비권한적) DNS 서버는 트러스트 앵커(DNSKEY)를 사용하여 RRSIG 레코드에 대한 DNSSEC 유효성 검사를 수행합니다. 서버는 DNSKEY를 사용하여 RRSIG 레코드(및 기타 DNSSEC 관련 레코드)의 디지털 서명을 해독한 다음 해시 값을 계산하고 비교합니다. 해시 값이 동일하면 요청한 DNS 데이터(예: 호스트 주소(A) 레코드)를 DNS 클라이언트에 회신으로 제공합니다. 다음 다이어그램을 참조하세요.
해시 값이 같지 않으면 재귀적 DNS 서버는 SERVFAIL 메시지로 회신합니다. 이런 방식으로 유효한 트러스트 앵커가 설치된 DNSSEC 가능 확인(또는 전달) DNS 서버는 재귀 서버와 권한 서버 사이의 경로에서 DNS 하이재킹을 방지할 수 있습니다. 이러한 보호 기능을 사용하려면 DNS 클라이언트 디바이스가 DNSSEC를 인식하거나 DNS 응답 유효성 검사를 강제할 필요가 없습니다. 단, 로컬(마지막 홉) 재귀 DNS 서버 자체가 하이재킹으로부터 안전해야 합니다.
Windows 10 및 Windows 11 클라이언트 디바이스는 유효성 검사되지 않는 보안 인식 스텁 확인자입니다. 이러한 클라이언트 디바이스는 유효성 검사를 수행하지 않지만 그룹 정책을 사용하여 DNSSEC 유효성 검사를 적용할 수 있습니다. NRPT는 네임스페이스 기반 DNSSEC 유효성 검사 정책을 만들고 적용하는 데 사용할 수 있습니다.
트러스트 앵커 및 DNSSEC 유효성 검사
참고
DNSSEC 응답 유효성 검사는 기본 Azure 제공 확인자에 의해 수행되지 않습니다. 이 섹션의 정보는 DNSSEC 유효성 검사를 위해 자체 재귀 DNS 서버를 설정하거나 유효성 검사 문제를 해결하는 데 유용합니다.
트러스트 앵커는 DNS 네임스페이스 계층 구조를 기반으로 작동합니다. 재귀적 DNS 서버에 트러스트 앵커가 어느 정도 있거나 전혀 없을 수 있습니다. 트러스트 앵커는 단일 자식 DNS 영역이나 모든 부모 영역에 추가할 수 있습니다. 재귀적 DNS 서버에 루트(.) 트러스트 앵커가 있는 경우 모든 DNS 영역에서 DNSSEC 유효성 검사를 수행할 수 있습니다. 자세한 내용은 루트 영역 운영자 정보를 참조하세요.
DNSSEC 유효성 검사 프로세스는 다음과 같이 트러스트 앵커와 함께 작동합니다.
- 재귀적 DNS 서버에 영역 또는 영역의 부모 계층 구조 네임스페이스에 대한 DNSSEC 트러스트 앵커가 없는 경우 해당 영역에서 DNSSEC 유효성 검사를 수행하지 않습니다.
- 재귀적 DNS 서버에 영역의 부모 네임스페이스에 대한 DNSSEC 트러스트 앵커가 있고 자식 영역에 대한 쿼리를 수신하는 경우, 자식 영역에 대한 DS 레코드가 부모 영역에 있는지 확인합니다.
- DS 레코드가 발견되면 재귀적 DNS 서버는 DNSSEC 유효성 검사를 수행합니다.
- 재귀적 DNS 서버가 부모 영역에 자식 영역에 대한 DS 레코드가 없다고 판단하면 자식 영역이 안전하지 않다고 가정하고 DNSSEC 유효성 검사를 수행하지 않습니다.
- DNS 응답에 여러 재귀 DNS 서버(전달자 포함)가 관련된 경우 각 서버는 응답에 대한 DNSSEC 유효성 검사를 수행할 수 있어야 하므로 신뢰 체인이 끊어지지 않습니다.
- DNSSEC 유효성 검사가 사용하지 않도록 설정되었거나 DNSSEC를 인식하지 못하는 재귀 서버는 유효성 검사를 수행하지 않습니다.
신뢰 체인
신뢰 체인은 DNS 쿼리에 대한 응답을 보내는 데 관련된 모든 DNS 서버가 응답이 전송 중에 수정되지 않았음의 유효성을 검사할 수 있을 때 발생합니다. DNSSEC 유효성 검사가 엔드투엔드에 이루어지려면 신뢰 체인이 끊어지지 않아야 합니다. 이러한 신뢰 체인은 권한 있는 서버와 권한 없는(재귀적) 서버 모두에 적용됩니다.
권한 있는 서버
권한 있는 DNS 서버는 위임 서명자(DS) 레코드를 사용하여 신뢰 체인을 유지합니다. DS 레코드는 DNS 계층 구조에서 자식 영역의 신뢰성을 확인하는 데 사용됩니다.
- 서명된 영역에서 DNSSEC 유효성 검사가 이루어지려면 서명된 영역의 부모 영역도 서명되어야 합니다. 부모 영역에는 자식 영역에 대한 DS 레코드도 있어야 합니다.
- 유효성 검사 프로세스에서 영역의 부모에 DS 레코드가 쿼리됩니다. DS 레코드가 없거나 부모 영역의 DS 레코드 데이터가 자식 영역의 DNSKEY 데이터와 일치하지 않으면 신뢰 체인이 끊어지고 유효성 검사가 실패합니다.
재귀 서버
재귀적 DNS 서버(DNS 서버 확인 또는 캐싱이라고도 함)는 DNSSEC 트러스트 앵커를 사용하여 신뢰 체인을 유지합니다.
- 트러스트 앵커는 DNSKEY 레코드 또는 DNSKEY 레코드의 해시를 포함하는 DS 레코드입니다. DNSKEY 레코드는 영역이 서명되면 권한 있는 서버에 만들어지고, 영역 서명이 취소되면 영역에서 제거됩니다.
- 트러스트 앵커는 재귀적 DNS 서버에 수동으로 설치해야 합니다.
- 부모 영역에 대한 트러스트 앵커가 있는 경우 재귀 서버는 계층 구조 네임스페이스에 있는 모든 자식 영역의 유효성을 검사할 수 있습니다. 여기에는 전달된 쿼리가 포함됩니다. 모든 DNSSEC 서명 DNS 영역에 대한 DNSSEC 유효성 검사를 지원하려면 루트(.) 영역에 대한 트러스트 앵커를 설치할 수 있습니다.
키 롤오버
DNSSEC 서명 영역의 ZSK(영역 서명 키)는 Azure에서 주기적으로 자동으로 롤오버(바꾸기)됩니다. KSK(키 서명 키)를 바꿀 필요는 없지만 Microsoft 지원에 문의하면 바꾸기 옵션을 이용할 수 있습니다. KSK를 바꾸려면 부모 영역의 DS 레코드도 업데이트해야 합니다.
영역 서명 알고리즘
영역은 타원 곡선 디지털 서명 알고리즘(ECDSAP256SHA256)을 사용하여 DNSSEC에 서명됩니다.
DNSSEC 관련 리소스 레코드
다음 표는 DNSSEC 관련 레코드에 대한 간략한 설명을 제공합니다. 자세한 내용은 RFC 4034: DNS 보안 확장 프로그램을 위한 리소스 레코드 및 RFC 7344: DNSSEC 위임 신뢰 유지 관리 자동화를 참조하세요.
| 레코드 | 설명 |
|---|---|
| RRSIG(리소스 레코드 서명) | 특정 이름과 형식에 대한 DNS 레코드 집합을 포함하는 서명을 보관하는 데 사용되는 DNSSEC 리소스 레코드 종류. |
| DNSKEY | 공개 키를 저장하는 데 사용되는 DNSSEC 리소스 레코드 종류. |
| DS(위임 서명자) | 위임을 보호하는 데 사용되는 DNSSEC 리소스 레코드 종류. |
| NSEC(다음 보안) | RFC 9824에 정의된 DNSSEC 리소스 레코드 유형은 인증된 존재 거부를 제공하고 영역 열거 공격을 방지합니다. |
| CDS(자식 위임 서명자) | 이 레코드는 선택 사항입니다. CDS 레코드가 있는 경우, 자식 영역에서는 CDS 레코드를 사용하여 부모 영역의 DS 레코드에 원하는 콘텐츠를 지정할 수 있습니다. |
| CDNSKEY(자식 DNSKEY) | 이 레코드는 선택 사항입니다. CDNSKEY 레코드가 자식 영역에 있는 경우 DNSKEY 레코드에서 DS 레코드를 생성하는 데 사용할 수 있습니다. |
참고
Azure DNSSEC는 인증된 존재 거부에 대한 최신 반복인 NSEC(RFC 9824) 를 구현합니다. NSEC 및 NSEC3의 이전 반복은 영역 열거 또는 오프라인 사전 공격을 허용하기 때문에 Azure DNS에서 사용되지 않습니다.
DNSSEC 관련 리소스 레코드 보기
DNSSEC 관련 레코드는 Azure Portal에 표시되지 않습니다. DNSSEC 관련 레코드를 보려면 Resolve-DnsName이나 dig.exe와 같은 명령줄 도구를 사용합니다. 이러한 도구는 Cloud Shell을 사용하여 사용할 수 있으며, 디바이스에 설치된 경우 로컬로 사용할 수 있습니다. Resolve-DnsName의 -dnssecok 옵션이나 dig.exe의 +dnssec 옵션을 사용하여 쿼리에서 DO 플래그를 설정해야 합니다.
중요
DNSSEC 관련 레코드를 쿼리하기 위해 nslookup.exe 명령줄 도구를 사용하지 마세요. nslookup.exe 도구는 DNSSEC를 인식하지 못하는 내부 DNS 클라이언트를 사용합니다.
다음 예제를 참조하세요.
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 용어
이 목록은 DNSSEC를 토론할 때 사용되는 일반적인 용어를 이해하는 데 도움이 되도록 제공됩니다. 또한 다음을 참조하세요: DNSSEC 관련 리소스 레코드
| 용어 | 설명 |
|---|---|
| AD(인증된 데이터) 비트 | 응답의 답변 및 권한 섹션에 포함된 모든 데이터가 해당 서버의 정책에 따라 DNS 서버에 의해 인증되었음을 응답에서 나타내는 데이터 비트. |
| 인증 체인 | 미리 구성된 트러스트 앵커에서 DNS 트리의 일부 자식 영역까지 확장되는 서명되고 유효성 검사된 DNS 레코드 체인. |
| DNS 확장(EDNS0) | DO 비트 및 최대 UDP 패킷 크기와 같은 확장된 DNS 헤더 정보를 전달하는 DNS 레코드. |
| DNSSEC(DNS 보안 확장) | DNS 데이터에 서명하고 안전하게 확인하기 위한 메커니즘을 제공하는 DNS 서비스 확장. |
| DO(DNSSEC 확인) 비트 | DNS 요청의 EDNS0 부분에 있는 비트이며, 클라이언트가 DNSSEC을 인식하고 있다는 신호를 보냅니다. |
| DNSSEC 유효성 검사 | DNSSEC 유효성 검사는 공용 암호화 키를 사용하여 DNS 데이터의 원본과 무결성의 유효성을 검사하는 프로세스입니다. |
| 보안 섬 | 위임 부모 영역에서 인증 체인이 없는 서명된 영역. |
| KSK(키 서명 키) | 지정된 영역에 대한 하나 이상의 다른 서명 키에 서명하는 데 사용되는 프라이빗 키에 해당하는 인증 키. 일반적으로 KSK에 해당하는 프라이빗 키는 ZSK(영역 서명 키)에 서명하고, 이 ZSK는 다른 영역 데이터에 서명하는 해당 프라이빗 키를 갖습니다. 로컬 정책에 따라 ZSK를 자주 변경해야 할 수 있는 반면, KSK는 해당 영역으로의 보다 안정적이고 안전한 진입점을 제공하기 위해 유효 기간이 더 길어질 수 있습니다. 인증 키를 KSK로 지정하는 것은 순전히 운영상의 문제입니다. DNSSEC 유효성 검사는 KSK와 다른 DNSSEC 인증 키를 구분하지 않습니다. 하나의 키를 KSK와 ZSK로 모두 사용하는 것이 가능합니다. |
| 유효성 검사가 불가능한 보안 인식 스텁 확인자 | 하나 이상의 보안 인식 DNS 서버가 대신 DNSSEC 유효성 검사를 수행하도록 신뢰하는 보안 인식 스텁 확인자. |
| SEP(보안 진입점) 키 | DNSKEY RRSet 내의 공개 키 하위 집합. SEP 키는 DS RR을 생성하는 데 사용되거나 키를 트러스트 앵커로 사용하는 확인자에 배포됩니다. |
| 보안 인식 DNS 서버 | RFC 4033[5], 4034[6] 및 4035[7]에 정의된 DNS 보안 확장 프로그램을 구현하는 DNS 서버. 특히, 보안 인식 DNS 서버는 DNS 쿼리를 수신하고 DNS 응답을 보내고 EDNS0[3] 메시지 크기 확장 및 DO 비트를 지원하고 DNSSEC 레코드 종류 및 메시지 헤더 비트를 지원하는 엔터티입니다. |
| 서명된 영역 | RFC 4035 [7] 섹션 2에 정의된 대로 레코드가 서명된 영역. 서명된 영역에는 DNSKEY, NSEC, RRSIG 및 DS 리소스 레코드가 포함될 수 있습니다. 이러한 리소스 레코드를 통해 확인자가 DNS 데이터의 유효성을 검사할 수 있습니다. |
| 트러스트 앵커 | 특정 영역과 연관된 미리 구성된 공개 키. 트러스트 앵커를 사용하면 DNS 해결 프로그램이 해당 영역에 대한 서명된 DNSSEC 리소스 레코드의 유효성을 검사하고 자식 영역에 대한 인증 체인을 빌드할 수 있습니다. |
| 서명 취소 영역 | RFC 4035 [7] 섹션 2에 정의된 대로 서명되지 않은 모든 DNS 영역. |
| 영역 서명 | 영역 서명은 DNSSEC 관련 리소스 레코드를 영역에 만들고 추가하는 프로세스로, 이를 통해 DNSSEC 유효성 검사와 호환됩니다. |
| 영역 서명 취소 | 영역 서명 취소는 영역에서 DNSSEC 관련 리소스 레코드를 제거하고 서명되지 않은 상태로 복원하는 프로세스입니다. |
| ZSK(영역 서명 키) | 영역에 서명하는 데 사용되는 프라이빗 키에 해당하는 인증 키. 일반적으로 영역 서명 키는 해당 프라이빗 키가 이 DNSKEY RRSet에 서명하는 키 서명 키와 동일한 DNSKEY RRSet의 일부이지만, 영역 서명 키는 약간 다른 목적으로 사용되며 유효 기간 등 다른 면에서 키 서명 키와 다를 수 있습니다. 인증 키를 영역 서명 키로 지정하는 것은 순전히 운영상의 문제입니다. DNSSEC 유효성 검사는 영역 서명 키와 다른 DNSSEC 인증 키를 구분하지 않습니다. 하나의 키를 키 서명 키와 영역 서명 키로 모두 사용할 수 있습니다. |
다음 단계
- DNSSEC를 사용하여 DNS 영역에 서명하는 방법을 알아봅니다.
- DNS 영역 서명을 취소하는 방법을 알아봅니다.
- Azure DNS에서 ISP 할당 IP 범위에 대한 역방향 조회 영역 호스트 방법을 알아봅니다.
- Azure 서비스에 대한 역방향 DNS 레코드를 관리하는 방법을 알아봅니다.