DNSSEC

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사
3. 작동 원리
4. 배포
- 4.1. 한국의 DNSSEC 현황
- 4.2. 공용 DNS 서버
5. DANE (DNS 기반 명명된 엔티티 인증)
6. 논란 및 과제
7. IETF 표준
8. 도구
참조

1. 개요

DNSSEC(Domain Name System Security Extensions)는 DNS(Domain Name System)의 보안을 강화하기 위한 확장 기술이다. 공개 키 암호 방식을 사용하여 DNS 레코드에 디지털 서명을 추가하여 DNS 조회를 보호한다. 1990년대 초 스티브 벨로빈에 의해 연구가 시작되어 여러 RFC를 거쳐 발전해왔으며, 2010년 루트 레벨에 처음 배포되었다. DNSSEC는 RRSIG, DNSKEY, DS, NSEC, NSEC3 등의 DNS 레코드 종류를 사용하며, 신뢰 앵커와 인증 체인을 통해 작동한다. DANE(DNS 기반 명명된 엔티티 인증)과 같은 기술을 지원하며, 키 관리 및 알고리즘 롤오버와 같은 특징을 갖는다. DNSSEC 배포는 DNS 서버 및 클라이언트 업데이트를 필요로 하며, 한국을 포함한 여러 국가에서 도입 및 확산을 추진하고 있다.

더 읽어볼만한 페이지

DNSSEC - .jp
.jp는 일본의 국가 코드 최상위 도메인이며, 일본 레지스트리 서비스(JPRS)에서 관리하고, 다양한 2차 도메인을 제공하며 일본 주소를 가진 개인, 단체, 조직이 등록할 수 있다.
DNSSEC - .eu
.eu는 유럽 연합을 나타내는 국가 코드 최상위 도메인으로, 상표권자 선등록, 일반 등록 기간을 거쳐 출시되었으며, 브렉시트 이후 영국 관련 도메인이 삭제되었고, 유럽 연합 기관을 위한 2차 도메인과 키릴/그리스 문자 버전도 존재한다.
키 관리 - 공개 키 기반 구조
공개 키 기반 구조(PKI)는 공개 키 암호화를 기반으로 안전한 통신과 개체 식별을 가능하게 하는 기술로서, 디지털 인증서를 통해 공개 키를 특정 개체에 연결하고 인증서를 관리하며, 인증 기관(CA), 등록 기관(RA) 등 다양한 구성 요소로 이루어져 인증서 발급, 관리, 배포, 사용 및 폐기와 관련된 역할, 정책, 하드웨어, 소프트웨어 및 절차의 집합을 포함한다.
키 관리 - 키 크기
키 크기는 암호 시스템의 보안 강도를 결정하는 핵심 요소로서, 무차별 대입 공격을 방지하기 위해 충분히 긴 길이가 필요하며, 계산 능력 및 양자 컴퓨팅 기술 발전에 따라 키 길이나 알고리즘을 주기적으로 조정하고 양자 내성 암호 기술 개발 및 전환이 중요하다.
공개 키 암호 - 공개 키 기반 구조
공개 키 기반 구조(PKI)는 공개 키 암호화를 기반으로 안전한 통신과 개체 식별을 가능하게 하는 기술로서, 디지털 인증서를 통해 공개 키를 특정 개체에 연결하고 인증서를 관리하며, 인증 기관(CA), 등록 기관(RA) 등 다양한 구성 요소로 이루어져 인증서 발급, 관리, 배포, 사용 및 폐기와 관련된 역할, 정책, 하드웨어, 소프트웨어 및 절차의 집합을 포함한다.
공개 키 암호 - 디지털 서명
디지털 서명은 공개 키 암호 방식을 기반으로 전자 문서의 위변조 방지 및 발신자 인증을 제공하며, 키 생성, 서명 생성, 검증의 세 가지 알고리즘으로 구성되어 올바른 서명 키로 생성된 서명은 항상 승인되어야 하고 공개 키만으로 유효한 서명을 생성하는 것이 계산적으로 불가능해야 한다는 특징을 가진다.

DNSSEC
DNSSEC 개요
유형	IETF 표준 모음
상태	권장
RFC	4033 4034 4035 5155 6840 6975
제안	IETF
DNSSEC 설명
설명	DNS 응답의 인증을 제공하는 IETF 사양 모음
목표	DNS 데이터를 위조로부터 보호
방법	암호화 키를 사용하여 DNS 데이터에 디지털 서명
취약점	DNS 스푸핑 방지
추가 보안 프로토콜	DKIM DMARC STARTTLS
DNSSEC 관련 RFC 문서
기본 RFC	DNS Security Introduction and Requirements (DNS 보안 소개 및 요구 사항) Resource Records for the DNS Security Extensions (DNS 보안 확장을 위한 리소스 레코드) Protocol Modifications for the DNS Security Extensions (DNS 보안 확장을 위한 프로토콜 수정)
주요 RFC	DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (DNS 보안 (DNSSEC) 해시된 인증된 존재 부정) Clarifications and Implementation Notes for DNS Security (DNSSEC) (DNS 보안 (DNSSEC)에 대한 설명 및 구현 참고 사항) Signaling Cryptographic Algorithm Understanding in DNSSEC (DNSSEC에서 암호화 알고리즘 이해도 시그널링)

2. 역사

DNS는 중요한 인터넷 서비스 중 하나이지만, 1990년에 스티브 벨로빈이 DNS에서 심각한 보안 결함을 발견하였다. 이에 대한 연구가 시작되었고, 그의 논문이 1995년 공개되면서 연구가 점차 활발해졌다.^[103] 1997년, IETF에서 초기 RFC 2065가 발표되었고, 1999년에는 RFC 2535로 개정되었다. RFC 2535를 기반으로 DNSSEC 배포 계획이 수립되었다.

하지만 IETF RFC 2535 명세는 인터넷 전체로 확장하는 데 매우 심각한 문제가 있었다. 2001년까지 이 명세가 대규모 네트워크에는 사용할 수 없다는 것이 분명해졌다. 일반적인 작동에서 DNS 서버는 종종 상위 서버와 동기화되지 않았는데, 이는 일반적으로 문제가 되지 않지만, DNSSEC가 활성화되면 이러한 동기화되지 않은 데이터는 심각한 자체 생성 서비스 거부 공격의 효과를 가져올 수 있었다. 원래 DNSSEC는 하위 서버에 대한 키 변경을 수행하기 위해 복잡한 6단계 메시지 프로토콜과 많은 데이터 전송을 필요로 했고, 공개 키 변경은 큰 영향을 미칠 수 있었다. 따라서 RFC 2535에 정의된 DNSSEC는 인터넷으로 확장될 수 없었다.

IETF는 DNSSEC를 근본적으로 수정했는데, 원래 RFC 2535의 DNSSEC 접근 방식과 구분하기 위해 필요한 경우 "DNSSEC-bis"라고 하였다. 이 새로운 버전은 "위임 서명자(DS) 리소스 레코드"를 사용하여 상위 영역과 하위 영역 간의 위임 지점에서 간접적인 추가 수준을 제공한다. 새로운 접근 방식에서는 하위 서버의 마스터 공개 키가 변경될 때 하위 서버의 모든 레코드에 대해 6개의 메시지를 사용하는 대신, 하나의 간단한 메시지가 사용된다. 새로운 버전은 RFC 4033-4035에 발표되었다.

2010년 7월 15일, 루트 레벨에 DNSSEC가 처음 배포되었다.^[23] 2011년 1월 16일, 일본의 .jp 도메인이 DNSSEC에 대응했다.

2016년 10월부터 2018년 3월까지 루트 존 KSK (Key Signing Key) 롤오버가 진행되었다. '''KSK 롤오버 문제'''는 DNSSEC에서 전자 서명의 정당성 검증에 사용되는 최상위 암호화 키인 "루트 존 KSK"를 업데이트할 때, EDNS를 통한 IP 조각화가 발생할 정도의 크기의 응답 데이터가 발생하지만, 통신 설정이 이에 대응하지 못하는 DNS에서는 통신이 불가능해지고, DNSSEC에 의한 정당성 검증이 불가능해져 인터넷 이용에 문제가 발생할 것으로 예상되었던 문제이다. 2019년 12월, ASCII.jp에 따르면 KSK 롤오버로 인한 큰 문제는 보고되지 않았다고 한다.^[101]

3. 작동 원리

DNSSEC(DNS Security Extensions)는 도메인 등록 정보에 디지털 서명을 추가하여 응답 레코드가 정당한 관리자에 의해 생성되었고 변조되지 않았음을 보증하는 기술이다. DNSSEC는 공개키 암호 방식을 사용하여 DNS 조회를 위한 레코드에 디지털 서명을 함으로써 작동한다.

DNS에서 도메인 등록 정보는 '''리소스 레코드'''(Resource Records; RR)의 집합으로 구성된다. 리소스 레코드에는 여러 유형이 있으며, IPv4 주소는 A, IPv6 주소는 AAAA, 메일 전달 목적지는 MX와 같이 구분하여 사용한다. DNSSEC는 리소스 레코드 유형을 추가하고, 인증에 필요한 정보를 추가 리소스 레코드로 처리한다. DNSSEC를 지원하지 않는 클라이언트는 추가 리소스 레코드를 무시하면 기존과 같이 조회할 수 있다.

디지털 서명은 데이터의 해시 값에 공개키 암호에 기반한 서명 처리를 적용한 결과 값이다. 인증용 공개키는 DNSKEY 레코드로 얻을 수 있지만, 그 키의 정당성을 확인하는 방법이 필요하다. DNSSEC는 DNS가 가지는 계층 구조를 이용하여 인증 체인을 구성한다.

도메인 이름은 전체적으로 거대한 트리 구조를 구성하며, 조회 시에는 루트부터 순차적으로 탐색한다. DNS는 이 트리 구조를 "존"의 계층 구조로 분할하여 분산 관리한다. 하위 도메인이 다른 존으로 관리되는 경우, 그 존의 위임 대상이 되는 DNS 서버의 호스트 이름을 기술한다. 클라이언트는 위임 대상 DNS 서버에 대해 재귀적으로 조회를 수행한다. 여기서 DNSSEC는 위임 대상 호스트 이름에 더하여, 그 존에서 사용되는 공개키의 다이제스트 값을 추가 리소스 레코드(DS 레코드)로 제공한다. 클라이언트는 위임 대상 DNSKEY 레코드에서 공개키를 얻고, 그 다이제스트 값을 DS 레코드와 비교함으로써 정당한 키인지 확인할 수 있다.

올바른 DNSKEY 레코드는 신뢰된 제3자인 DNS 루트 영역에 대한 검증된 공개 키 집합으로 시작하는 신뢰 체인을 통해 인증된다. 도메인 소유자는 자체 키를 생성하고 도메인 이름 등록 기관의 DNS 제어판을 사용하여 업로드하며, 이는 차례로 secDNS를 통해 키를 영역 운영자(예: .com의 Verisign)에게 전달하고, 영역 운영자는 이를 서명하여 DNS에 게시한다.

3. 1. 리소스 레코드

DNSSEC는 여러 가지 새로운 DNS 레코드 종류를 사용하거나 기존 레코드를 수정하여 구현된다. 다음은 DNSSEC에 사용되는 주요 레코드들이다.

RRSIG (리소스 레코드 서명): 레코드 집합에 대한 DNSSEC 서명을 포함한다. DNS 확인자는 DNSKEY 레코드에 저장된 공개 키를 사용하여 이 서명을 확인한다.
DNSKEY: DNS 확인자가 RRSIG 레코드의 DNSSEC 서명을 확인하는 데 사용하는 공개 키를 포함한다.
DS (위임 서명자): 위임된 영역의 이름을 가지며, 하위 위임 영역의 DNSKEY 레코드를 참조한다. DS 레코드는 상위 영역에 배치되어 위임의 신뢰성을 보장한다.
NSEC (다음 보안 레코드): 영역의 다음 레코드 이름에 대한 링크를 포함하고, 해당 레코드 이름에 대해 존재하는 레코드 종류를 나열한다. DNS 확인자는 이를 통해 특정 레코드 이름 및 종류가 존재하지 않음을 확인할 수 있다.
NSEC3 (다음 보안 레코드 버전 3): NSEC 레코드와 유사하지만, 암호화 방식으로 해시된 레코드 이름을 사용하여 영역 내 레코드 이름 열거를 방지한다.
NSEC3PARAM (다음 보안 레코드 버전 3 매개변수): 권한 있는 DNS 서버가 존재하지 않는 이름/종류에 대한 DNSSEC 요청에 응답할 때 사용할 NSEC3 레코드를 계산하고 결정하는 데 사용된다.

DNSSEC가 사용될 때, DNS 조회에 대한 각 응답에는 요청된 레코드 종류 외에 RRSIG DNS 레코드가 포함된다. RRSIG 레코드는 응답 DNS 리소스 레코드 집합의 디지털 서명이며, DNSKEY 레코드에서 찾은 올바른 공개 키를 통해 확인된다. NSEC 및 NSEC3 레코드는 리소스 레코드(RR) 부재에 대한 암호화 증거를 제공하고, DS 레코드는 신뢰 체인을 통해 DNSKEY 인증에 사용된다.

에서는 host.example.com의 A 레코드에 대한 디지털 서명의 구체적인 예로 다음과 같은 RRSIG 레코드를 제시한다.

```

host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (

20030220173103 2642 example.com.

oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr

PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o

B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t

GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG

J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

```

위 예시에서 3행 이후는 디지털 서명을 베이스64 표기로 나타낸 것이다. 디지털 서명은 데이터의 해시 값에 공개키 암호를 적용한 결과 값이다. 여기서는 SHA-1 및 RSA가 사용되었다 (1행의 "5"는 사용된 알고리즘을 나타냄). 인증에 사용되는 공개키는 DNSKEY 레코드에서 얻을 수 있으며, DNSSEC는 DNS 계층 구조를 활용하여 이 키의 정당성을 확인하는 인증 체인을 구성한다.

3. 2. 알고리즘

DNSSEC는 다양한 암호화 알고리즘을 지원하며, 필요에 따라 새로운 알고리즘을 도입할 수 있도록 설계되었다. 다음은 주요 알고리즘 및 구현 상태를 나타내는 표이다.

알고리즘 필드	알고리즘	출처
1	RSA/MD5
3	DSA/SHA-1
5	RSA/SHA-1	RFC 3110
7	RSASHA1-NSEC3-SHA1	RFC 5155
8	RSA/SHA-256	RFC 5702
10	RSA/SHA-512	RFC 5702
12	GOST R 34.10-2001	RFC 5933
13	ECDSA P-256/SHA-256	RFC 6605
14	ECDSA P-384/SHA-384	RFC 6605
15	Ed25519	RFC 8080
16	Ed448	RFC 8080

다이제스트 필드	다이제스트	출처
1	SHA-1	RFC 3658
2	SHA-256	RFC 4509
3	GOST R 34.10-2001	RFC 5933
4	SHA-384	RFC 6605

^[102]^[5]

3. 3. 조회 절차

보안을 인식하는 DNS 확인자는 DNS 쿼리에 "DO" (DNSSEC OK) 플래그 비트를 설정하여 DNSSEC 검증을 시작한다.^[6]^[7] DO 비트는 DNS 확장 메커니즘(EDNS)에 정의된 확장 플래그 비트에 있으므로, 모든 DNSSEC 트랜잭션은 EDNS를 지원해야 한다. DNSSEC 트랜잭션에 필요한 훨씬 더 큰 패킷 크기를 허용하려면 EDNS 지원도 필요하다.

보안을 인식하는 리졸버가 일반적인 DNS 조회 프로세스를 통해 응답을 받으면, 응답이 정확한지 확인한다. 이상적으로는 DNS 루트에서 DS 및 DNSKEY 레코드 확인부터 시작하여 신뢰 체인을 따라 검증을 수행한다. 루트에서 찾은 "com" 최상위 도메인의 DS 레코드를 사용하여 "com" 영역의 DNSKEY 레코드를 확인하고, "com" 영역에 "example.com" 하위 도메인에 대한 DS 레코드가 있는지 확인한다. 있다면 DS 레코드를 사용하여 "example.com" 영역에서 발견된 DNSKEY 레코드를 확인하고, 마지막으로 "www.example.com"에 대한 A 레코드에 대한 응답에서 발견된 RRSIG 레코드를 확인한다.^[6]^[7]

하지만 몇 가지 예외가 존재한다.

"example.com"이 DNSSEC를 지원하지 않는 경우, 응답에 RRSIG 레코드가 없고 "com" 영역에 "example.com"에 대한 DS 레코드가 없다.
"example.com"에 대한 DS 레코드가 있지만 응답에 RRSIG 레코드가 없다면, 중간자 공격이 발생하여 DNSSEC 정보가 제거되고 A 레코드가 수정되었을 수 있다. 또는 구성 오류일 수도 있다.
"www.example.com"이라는 도메인 이름이 없을 수 있는데, 이 경우 응답에 RRSIG 레코드를 반환하는 대신 NSEC 레코드 또는 NSEC3 레코드가 있다. 이들은 리졸버가 도메인 이름이 존재하지 않음을 증명할 수 있도록 하는 "다음 안전" 레코드이다. NSEC/NSEC3 레코드에는 RRSIG 레코드가 있으며, 위에서 설명한 대로 확인할 수 있다.
"example.com" 영역이 DNSSEC를 구현하지만 "com" 영역 또는 루트 영역이 구현하지 않아 다른 방식으로 확인해야 하는 "보안의 섬"이 생성될 수 있다.

스텁 리졸버는 재귀적 네임 서버에 요청을 전달하고, 응답의 인증 데이터(AD) 비트를 확인한다.^[10]^[11] 마이크로소프트 윈도우는 스텁 리졸버를 사용하며, 특히 Windows Server 2008 R2 및 Windows 7은 검증되지 않지만 AD 비트를 인식하는 스텁 리졸버를 사용한다.^[6]^[7]

검증 스텁 리졸버는 쿼리 메시지에 검사 비활성화(CD) 비트를 설정하여 자체 서명 검증을 수행할 수 있다.^[11] 이를 통해 인터넷 서비스 제공자 또는 해당 연결이 신뢰할 수 없는 경우에도 클라이언트 엔드투엔드 DNS 보안을 제공한다.

검증되지 않은 스텁 리졸버는 외부 DNSSEC 검증 서비스와 자체와 해당 이름 서버 간의 통신 채널(예: DNS over TLS)에 의존해야 한다.^[11]^[12]

3. 4. 신뢰 앵커 및 인증 체인

DNSSEC는 신뢰 앵커(trust anchors)라고 하는, DNS 외부에서 얻은 하나 이상의 올바른 키 또는 DS 레코드를 기반으로 한다. 이러한 신뢰 앵커는 운영 체제나 다른 신뢰할 수 있는 소스를 통해 얻는 것이 일반적이다.^[13] DNSSEC가 처음 설계되었을 때는 DNS 루트에 대한 신뢰 앵커만 필요할 것으로 생각되었으나, 루트 앵커는 2010년 7월 15일에 처음 게시되었다.

'''인증 체인(authentication chain)'''은 신뢰 앵커에서 해당 도메인의 권한 있는 이름 서버까지 연결된 DS 및 DNSKEY 레코드의 시리즈이다. 완전한 인증 체인이 없으면 DNS 조회에 대한 응답을 안전하게 인증할 수 없다. 예를 들어, 재귀적 리졸버가 "www.example.com" 도메인의 IP 주소(A 레코드 및/또는 AAAA 레코드)를 가져오려고 할 때, 보안을 인식하는 리졸버는 DNS 쿼리에서 "DO"("DNSSEC OK") 플래그 비트를 설정하여 프로세스를 시작하고, 응답의 정확성을 확인하기 위해 DNS 루트에서 DS 및 DNSKEY 레코드 확인부터 시작한다.

3. 5. 키 관리

DNSSEC는 키 서명 키(KSK)와 영역 서명 키(ZSK)라는 두 가지 종류의 키를 사용한다. KSK는 ZSK를 서명하는 데 사용되며, ZSK는 다른 레코드들을 서명하는 데 사용된다.^[13] ZSK는 특정 DNS 영역에서 완전히 제어하고 사용하므로 더 쉽고 자주 교체할 수 있다. 결과적으로 ZSK는 KSK보다 훨씬 짧으면서도 동일한 수준의 보호 기능을 제공하고 RRSIG/DNSKEY 레코드의 크기를 줄일 수 있다.

새로운 키로 교체하기 위해 '''키 롤오버(key rollover)''' 방식을 사용한다. 일반적으로 기존의 이전 키와 함께 새로운 DNSKEY 레코드에 새로운 키를 먼저 배포한다. 그런 다음 이전 키의 캐싱이 TTL(Time To Live) 값에 의해 만료되었다고 안전하게 판단되면 이러한 새 키를 사용할 수 있다. 마지막으로 이전 키를 사용하는 레코드의 캐싱이 만료되었다고 안전하게 판단되면 이전 DNSKEY 레코드를 삭제할 수 있다.^[13]

새로운 KSK가 생성되면 DS 레코드를 상위 영역으로 전송하여 게시해야 한다. 레코드 크기를 작게 유지하기 위해 DS 레코드는 전체 키 대신 KSK의 메시지 다이제스트를 사용한다. 이는 .com 도메인과 같이 매우 큰 영역에 유용하다.^[13]

밀접하게 관련된 원칙은 '''알고리즘 롤오버(Algorithm rollover)'''이다. 이는 영역을 한 서명 알고리즘에서 다른 알고리즘으로 마이그레이션하는 것을 포함한다. 좋은 예로 알고리즘 8(RSA/SHA-256)에서 알고리즘 13(ECDSA/SHA-256)으로 마이그레이션하는 것이다. .at, .br, .cz, .ch, .fr, .ie, .nl^[14] 및 .ph를 포함한 여러 ccTLD가 이미 마이그레이션되었다. 베라이즌(Verisign)은 2023년 말에 .com, .net 및 .edu를 알고리즘 13으로 마이그레이션했다.^[15]^[16]

4. 배포

DNSSEC 배포는 쉽지 않은 과제였지만, 인터넷 보안을 위해 필수적인 요소로 인식되면서 전 세계적으로 꾸준히 진행되고 있다.

DNSSEC 배포에는 다음과 같은 어려움이 있었다.^[4]

인터넷 규모로 확장될 수 있는 하위 호환 가능한 표준 설계
"영역 열거" 방지
다양한 DNS 서버 및 리졸버(클라이언트)에 DNSSEC 구현 배포
최상위 도메인 루트 키 소유자에 대한 의견 불일치
DNSSEC 및 DNSSEC 배포의 복잡성에 대한 인식 극복

이러한 어려움에도 불구하고, DNSSEC는 DNS 계층 구조의 어느 수준에서든 배포될 수 있으며, 많은 기관에서 채택하기 전에 영역에서 광범위하게 사용 가능해야 한다. DNS 서버는 DNSSEC를 지원하는 소프트웨어로 업데이트해야 하며, DNSSEC 데이터를 생성하여 DNS 영역 데이터에 추가해야 한다. TCP/IP를 사용하는 클라이언트는 DNSSEC 기능을 사용하기 전에 DNS 리졸버(클라이언트)를 업데이트해야 하며, 모든 리졸버는 DNSSEC를 사용하기 시작하기 전에 신뢰할 수 있는 최소 하나의 공개 키를 가지고 있거나 획득할 수 있는 방법이 있어야 한다.

초기 도입 국가로는 브라질 (.br), 불가리아 (.bg), 체코 (.cz), 나미비아 (.na)^[32], 푸에르토리코 (.pr), 스웨덴 (.se) 등이 있으며, 이들은 자국의 국가 코드 최상위 도메인에 DNSSEC를 사용하고 있다.^[33] RIPE NCC는 인터넷 할당 번호 기관(IANA)으로부터 위임받은 모든 역방향 조회 레코드(in-addr.arpa)에 서명했고,^[34] ARIN 또한 역방향 영역에 서명하고 있다.^[35]

국제 인터넷 주소 관리 기관(IANA)은 2007년 6월부터 서명된 루트 샘플을 공개적으로 테스트했으며, 루트의 본격적인 서명 이전 기간 동안 여러 대체 신뢰 앵커도 있었다. 2010년 7월 15일에는 최초의 루트 전체 프로덕션 DNSSEC 루트 영역이 서명되었다.^[48]

미국에서는 국토안보부(DHS)가 "DNSSEC 배포 계획"을 지원하며, 인터넷 네이밍 인프라의 보안을 개선하기 위한 노력을 장려하고 있다. 또한, 미국 연방 정부 내에 DNSSEC 배포를 위한 노력에도 자금을 지원하고 있다. 2008년 8월 22일, 미국 행정관리예산처(OMB)는 미국 연방 기관이 .gov 사이트 전체에 DNSSEC를 배포하도록 요구하는 각서를 발표했다.^[70]

몇몇 인터넷 서비스 제공자(ISP)들도 DNSSEC 검증 재귀적 리졸버를 배포하기 시작했다. 미국에서는 Comcast가 2012년 1월 11일에 배포를 완료하며 최초로 이를 시행한 주요 ISP가 되었다.^[74]

APNIC의 연구에 따르면, DNSSEC 검증을 수행하는 DNS 리졸버만을 독점적으로 사용하는 클라이언트의 비율은 2013년 5월 8.3%였으며,^[75] 2016년 초에는 약 15%로 증가했다.^[77]

4. 1. 한국의 DNSSEC 현황

이 섹션은 주어진 원본 소스에 한국의 DNSSEC 현황에 대한 내용이 없어 요약문의 내용만을 기반으로 작성되었습니다.

한국인터넷진흥원(KISA)은 DNSSEC 확산을 위한 기술 지원 및 교육을 제공하고 있다. .kr 도메인은 DNSSEC를 지원하며, 국내 주요 ISP들도 DNSSEC 검증을 지원하는 추세다. 더불어민주당은 사이버 안보 강화를 위한 정책의 일환으로 DNSSEC 확산을 지지하며, 관련 법/제도 개선에 노력을 기울이고 있다.

4. 2. 공용 DNS 서버

구글 퍼블릭 DNS (Google Public DNS), Verisign Public DNS^[96], Norton ConnectSafe^[97](종료) 등 여러 공용 DNS 서버 (일반적으로 제공하는 공개 DNS 리졸버)가 DNSSEC 검증을 지원한다.

국내에서는 IIJ^[98], InfoSphere^[99], SANNET^[100] 등의 사업자가 이용자에게 DNSSEC 대응 서비스를 제공하고 있다.

5. DANE (DNS 기반 명명된 엔티티 인증)

DNS 기반 명명된 엔티티 인증(DANE)은 DNSSEC를 기반으로 TLS, DTLS, SMTP, S/MIME을 사용하여 인터넷 애플리케이션이 암호화된 통신을 설정할 수 있도록 하는 프로토콜 및 기술이다.^[18] DANE은 IETF 작업반에서 개발되었다.

DANE을 통해 도메인 소유자는 제3자 인증 기관을 거치지 않고 자체 인증서를 주장할 수 있다. 이는 공개 키 기반 구조 모델에 추가적인 보장과 제약을 제공한다.

구글 크롬 14에서는 DNSSEC 고정 인증서 지원이 활성화되었으나,^[19] 이후 제거되었다.^[20] 모질라 파이어폭스에서는 추가 기능을 통해 지원되었으며,^[21] 기본 지원은 현재 작업 착수를 기다리고 있다.^[22] 2023년 9월, 마이크로소프트는 SMTP 통신 중 인증서 확인에 DNSSEC (DANE 방식)를 활용할 것이라고 발표했다.^[80]

6. 논란 및 과제

DNSSEC는 원래 보안을 고려하지 않고 설계된 DNS에 보안 기능을 추가하여 DNS 캐시 포이즈닝과 같은 위협으로부터 보호하기 위해 만들어졌다.^[1] 그러나 복잡성, 배포 비용, 성능 오버헤드 등의 문제로 인해 널리 배포되지 못하고 있다.

DNSSEC는 DNS 데이터를 디지털 서명하여 데이터의 무결성과 출처를 확인한다.^[1] 이를 통해 위조되거나 조작된 DNS 데이터를 걸러낼 수 있다. DNSSEC는 IP 주소뿐만 아니라 DNS에 게시된 모든 데이터를 보호할 수 있으며, 다른 보안 시스템을 구축하는 데 활용될 수 있다.^[2] ^[3] 그러나 DNSSEC는 데이터의 기밀성을 제공하지 않으며, 모든 응답은 인증되지만 암호화되지는 않는다. 또한, DoS 공격을 직접적으로 방지하지는 못한다.

DNSSEC 배포가 어려운 이유는 다음과 같다:

인터넷 규모로 확장 가능한 하위 호환 표준 설계의 어려움
"영역 열거" 방지 필요성
다양한 DNS 서버 및 클라이언트(리졸버)에 DNSSEC 구현 배포 필요
최상위 도메인 루트 키 소유권에 대한 의견 불일치
DNSSEC 및 DNSSEC 배포의 복잡성에 대한 인식

초기 DNSSEC 구현(RFC 2535)은 대규모 네트워크에서 심각한 문제를 일으켰다. 상위 서버와 동기화되지 않은 데이터는 자체 생성 서비스 거부 공격을 유발할 수 있었다. 또한, 공개 키 변경은 엄청난 양의 데이터 전송을 필요로 했다. 이후 IETF는 DNSSEC를 수정하여 "위임 서명자(DS) 리소스 레코드"를 사용하는 "DNSSEC-bis"를 발표했다. 이 새로운 접근 방식은 상위 서버와 하위 서버 간의 데이터 교환을 줄여 문제를 해결했다.

2024년 1월에는 "KeyTrap" 서비스 거부 공격이 발표되었다. 이 공격은 리졸버가 서명된 패킷을 수신할 때 모든 키 조합을 시도해야 하는 DNSSEC 사양을 악용하여 리졸버 속도를 크게 늦출 수 있다.^[24]

DNSSEC는 존재하지 않는 도메인에 대한 응답을 암호화 방식으로 증명하기 위해 NSEC 레코드를 사용했다. 그러나 이는 기존 도메인의 존재를 노출하는 문제가 있었다. NSEC3 레코드는 도메인 이름을 해시하여 이 문제를 해결했지만, 오프라인 사전 공격에 취약해졌다. https://datatracker.ietf.org/doc/draft-vcelak-nsec5/ NSEC5는 이러한 문제를 해결하기 위해 제안되었다.^[25]

클라우드플레어(CloudFlare)는 응답 크기를 줄이는 "검은 거짓말"과 "DNS 샷건"과 같은 대안적인 방법을 개발했다.^[27] ^[28] ^[29]

DNS는 인터넷의 중요한 기반 시설이지만, 근본적으로 안전하지 않다. DNSSEC 배포는 이러한 문제를 해결하기 위한 중요한 단계로 간주된다.^[30] 그러나 DNSSEC 배포는 "부트스트랩 문제"를 가지고 있다. 사용자는 즉각적인 이점을 얻을 수 있을 때만 기술을 배포하는 경향이 있는데, DNSSEC는 최소 배포 수준이 필요하기 때문에 어려움이 있다.

DNSSEC 구현은 일부 DNS 서버에 상당한 부하를 추가할 수 있다. DNSSEC 서명 응답은 일반적인 UDP 크기보다 크기 때문에 TCP를 사용해야 하는 경우가 많다. 그러나 많은 TCP 구현은 각 연결에 많은 양의 데이터를 저장하여 부하가 많은 서버의 리소스를 고갈시킬 수 있다. TCP 쿠키 트랜잭션과 같은 프로토콜 확장이 이러한 부하를 줄이기 위해 개발되었다.^[31]

'''KSK 롤오버 문제'''는 DNSSEC에서 최상위 암호화 키인 "루트 존 KSK"를 업데이트할 때 발생하는 문제였다. 업데이트 시 발생하는 큰 응답 데이터가 IP 조각화를 일으키고, 일부 DNS 설정이 이를 처리하지 못해 통신이 불가능해질 수 있다는 우려가 있었다. 그러나 2019년 12월, ASCII.jp에 따르면 KSK 롤오버로 인한 큰 문제는 보고되지 않았다.^[101]

제프 허스턴은 DNSSEC 배포를 포기해야 한다고 주장하기도 했다.^[81]

7. IETF 표준

다음은 DNSSEC 관련 IETF 표준 문서 목록이다.

RFC 2535 - 도메인 이름 시스템 보안 확장 (Domain Name System Security Extensions)^[23]
RFC 3833 - 도메인 이름 시스템의 위협 분석^[1]
RFC 4033 - DNS 보안 소개 및 요구 사항 (''DNSSEC-bis'')^[1]
RFC 4034 - DNS 보안 확장을 위한 리소스 레코드 (''DNSSEC-bis'')^[1]
RFC 4035 - DNS 보안 확장을 위한 프로토콜 수정 (''DNSSEC-bis'')^[1]
RFC 4398 - 도메인 이름 시스템(DNS)에 인증서 저장^[2]
RFC 4470 - 최소한으로 NSEC 레코드를 포함하고 DNSSEC 온라인 서명
RFC 4509 - DNSSEC 위임 서명자(DS) 리소스 레코드(RR)에서 SHA-256 사용
RFC 5155 - DNSSEC 해시 인증 거부
RFC 6781 - DNSSEC 운영 관행, 버전 2
RFC 5702 - DNSSEC의 DNSKEY 및 RRSIG 리소스 레코드에서 RSA와 SHA-2 알고리즘 사용
RFC 3110 - 도메인 이름 시스템(DNS)의 RSA/SHA-1 서명 및 RSA 키
RFC 4431 - DNSSEC 잠시 보기 확인(DLV) DNS 리소스 레코드
RFC 5074 - DNSSEC 잠시 보기 확인(DLV)
RFC 9364 (BCP 237) - DNS 보안 확장
RFC 3225 - DNSSEC 지원 해결기 표시
RFC 3226 - DNSSEC 및 IPv6 A6 인식 서버/해결기 메시지 크기 요구 사항
RFC 4641 - DNSSEC 운영 관행
RFC 4955 - DNS 보안(DNSSEC) 실험
RFC 5011 - DNS 보안(DNSSEC) 신뢰 앵커의 자동 업데이트
RFC 6014 - DNSSEC의 암호 알고리즘 식별자 할당
RFC 6605 - DNSSEC용 타원 곡선 디지털 서명 알고리즘(DSA)
RFC 6725 - DNS 보안(DNSSEC) DNSKEY 알고리즘 IANA 레지스트리 업데이트
RFC 6840 - DNS 보안(DNSSEC)에 대한 명확화 및 구현 참고 사항
RFC 6975 - DNS 보안 확장(DNSSEC)에서 암호 알고리즘 이해 신호 전달
RFC 7129 - DNS의 인증된 존재 부인
RFC 7344 - DNSSEC 위임 신뢰 유지 관리 자동화
RFC 7583 - DNSSEC 키 롤오버 타이밍 고려 사항
RFC 8078 - CDS/CDNSKEY를 통한 상위에서 DS 레코드 관리
RFC 8080 - DNSSEC용 에드워즈 곡선 디지털 보안 알고리즘(EdDSA)
RFC 8198 - DNSSEC 유효성 검사 캐시의 공격적인 사용
RFC 8624 - DNSSEC의 알고리즘 구현 요구 사항 및 사용 지침
RFC 8749 - DNSSEC 잠시 보기 유효성 검사(DLV)를 기록 상태로 이동
RFC 9077 - NSEC 및 NSEC3: TTL 및 공격적인 사용
RFC 9157 - DNSSEC에 대한 개정된 IANA 고려 사항
RFC 9276 - NSEC3 매개변수 설정에 대한 지침

DNSSEC (Domain Name System Security Extensions)는 도메인 등록 정보에 디지털 서명을 추가하여, 정당한 관리자에 의해 생성된 응답 레코드임을 보장하고 응답 레코드가 변조되지 않았음을 보증하는 기술이다.

DNS에서 도메인 등록 정보는 '''리소스 레코드'''(Resource Records; RR)의 집합으로 구성된다. 리소스 레코드에는 여러 유형이 정의되어 있으며, 호스트 이름에 해당하는 IPv4 주소의 정의에는 A, IPv6 주소에는 AAAA, 메일 전달 목적지는 MX와 같이 구분하여 사용한다. DNSSEC는 리소스 레코드의 유형을 추가하고, 인증에 필요한 정보를 추가 리소스 레코드로 처리한다. DNSSEC를 지원하지 않는 클라이언트는 추가 리소스 레코드를 무시하면 기존과 같이 조회할 수 있다.

RFC 4034에서는 host.example.com의 A 레코드에 대한 디지털 서명의 구체적인 예로서 다음과 같은 RRSIG 레코드를 보여준다.

```text

host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (

20030220173103 2642 example.com.

oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr

PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o

B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t

GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG

J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

```

3행 이후는 디지털 서명을 베이스64 표기로 나타낸 것이다.

디지털 서명은 구체적으로 데이터의 해시 값에 대해 공개키 암호에 기반한 서명 처리를 적용한 결과 값이다. 위의 예에서는 SHA-1 및 RSA를 사용하고 있다(1행의 "5"가 사용한 알고리즘을 나타낸다). 인증용 공개키는 또 다른 리소스 레코드(DNSKEY 레코드)로 얻을 수 있지만, 그 키의 정당성을 확인하는 방법이 필요하다. DNSSEC는 DNS가 가지는 계층 구조를 이용하여 인증 체인을 구성한다.

도메인 이름은 전체적으로 거대한 트리 구조를 구성하며, 조회 시에는 루트부터 순차적으로 탐색한다. DNS는 이 트리 구조를 "존"의 계층 구조로 분할하여 분산 관리한다. 하위 도메인이 다른 존으로 관리되는 경우, 그 존의 위임 대상이 되는 DNS 서버의 호스트 이름을 기술한다. 클라이언트는 위임 대상 DNS 서버에 대해 재귀적으로 조회를 수행한다. 여기서 DNSSEC는 위임 대상 호스트 이름에 더하여, 그 존에서 사용되는 공개키의 다이제스트 값을 추가 리소스 레코드(DS 레코드)로 제공한다. 클라이언트는 위임 대상 DNSKEY 레코드에서 공개키를 얻고, 그 다이제스트 값을 DS 레코드와 비교함으로써 정당한 키인지 확인할 수 있다.

8. 도구

BIND(dig 포함)는 ''DNSSEC-bis''(DS 레코드) 프로토콜과 NSEC3 레코드를 지원한다.
Unbound는 처음부터 DNSSEC 개념을 중심으로 설계된 DNS 이름 서버이다.
DNS ASP용 GPL DNS 관리 소프트웨어인 mysqlBind는 DNSSEC를 지원한다.
OpenDNSSEC는 PKCS#11을 사용하여 하드웨어 보안 모듈과 인터페이스하는 DNSSEC 서명 도구이다.
Knot DNS는 1.4.0 버전부터 자동 DNSSEC 서명을 지원한다.
PowerDNS는 3.0 버전부터 사전 서명 및 라이브 서명 모드에서 DNSSEC를 지원한다.
[https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en DNSSEC이란 무엇이며 왜 오랫동안 구현하는 것이 중요한가?] — [https://en.internet.nl/connection/ 인터넷 커뮤니티와 네덜란드 정부의 이니셔티브]
Windows 7 및 Windows Server 2008 R2에는 재귀적 이름 서버의 안전한 응답과 안전하지 않은 응답을 구분할 수 있는 "보안 인식" 스텁 리졸버가 포함되어 있다. Windows Server 2012 DNSSEC는 Active Directory와 통합된 영역을 사용한 안전한 동적 업데이트와 함께 다른 서버로의 앵커 키의 Active Directory 복제와 호환된다.^[82]^[83]

참조

_[1] 논문 Retrofitting Security into Network Protocols: The Case of DNSSEC https://ieeexplore.i[...]
_[2] 웹사이트 Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRS) https://datatracker.[...]
_[3] 웹사이트 TLS Encrypted Client Hello https://datatracker.[...]
_[4] 인터뷰 Kaminsky interview: DNSSEC addresses cross-organizational trust and security https://web.archive.[...] 2009-06-25
_[5] 웹사이트 Domain Name System Security (DNSSEC) Algorithm Numbers https://www.iana.org[...] IANA 2010-07-12
_[6] 웹사이트 Understanding DNSSEC in Windows https://technet.micr[...] Microsoft 2009-10-07
_[7] 웹사이트 DNS Security Extensions (DNSSEC) https://technet.micr[...] Microsoft 2009-10-21
_[8] 웹사이트 Root DNSSEC https://www.iana.org[...]
_[9] 웹사이트 Computing - the UK's leading source for the analysis of business technology http://www.v3.co.uk/[...]
_[10] 표준 RFC 4033: DNS Security Introduction and Requirements http://tools.ietf.or[...] The Internet Society 2005-03
_[11] 표준 RFC 4033: DNS Security Introduction and Requirements http://tools.ietf.or[...] The Internet Society 2005-03
_[12] 서적 Enabling Practical IPsec Authentication for the Internet https://web.archive.[...] Springer
_[13] 웹사이트 root-anchors https://data.iana.or[...]
_[14] 웹사이트 New DNSSEC algorithm for .nl https://www.sidn.nl/[...] 2024-01-29
_[15] 웹사이트 Verisign Will Help Strengthen Security with DNSSEC Algorithm Update https://blog.verisig[...] 2023-08-10
_[16] 웹사이트 Transitioning Verisign's TLDs to Elliptic Curve DNSSEC https://indico.dns-o[...]
_[17] 웹사이트 Root Zone KSK Algorithm Rollover - ICANN https://www.icann.or[...]
_[18] 웹사이트 IETF: DNS-based Authentication of Named Entities (dane) https://datatracker.[...]
_[19] 웹사이트 ImperialViolet http://www.imperialv[...]
_[20] 웹사이트 chromium git https://git.chromium[...]
_[21] 웹사이트 DNSSEC/TLSA Validator https://www.dnssec-v[...]
_[22] 웹사이트 Bug 672600 - Use DNSSEC/DANE chain stapled into TLS handshake in certificate chain validation https://bugzilla.moz[...]
_[23] 논문 Using the Domain Name System for System Break-Ins http://citeseer.ist.[...]
_[24] 웹사이트 The KeyTrap Denial-of-Service Algorithmic Complexity Attacks on DNS Version: January 2024 https://www.athene-c[...]
_[25] 웹사이트 NSEC5: Provably Preventing DNSSEC Zone Enumeration https://www.cs.bu.ed[...]
_[26] 표준 Authenticated Denial of Existence in the DNS
_[27] 웹사이트 Economical With The Truth: Making DNSSEC Answers Cheap https://blog.cloudfl[...] 2016-06-24
_[28] 표준 Compact DNSSEC Denial of Existence or Black Lies
_[29] 웹사이트 DNSSEC Done Right https://blog.cloudfl[...] 2015-01-29
_[30] 보고서 U.S. National Strategy to Secure Cyberspace https://www.us-cert.[...] 2003-02
_[31] 논문 Improving TCP security with robust cookies http://www.usenix.or[...]
_[32] 웹사이트 Bare URL PDF https://ccnso.icann.[...] 2022-03
_[33] 웹사이트 DNSSEC http://epic.org/priv[...] Electronic Privacy Information Center (EPIC) 2008-05-27
_[34] 웹사이트 RIPE NCC DNSSEC Policy http://www.ripe.net/[...]
_[35] 웹사이트 ARIN DNSSEC Deployment Plan https://www.arin.net[...]
_[36] 웹사이트 [dns-wg] Swedish ISP TCD Song Adopts DNSSEC https://www.ripe.net[...] RIPE NCC 2012-12-02
_[37] 웹사이트 dns-wg archive: Signed zones list http://www.ripe.net/[...] 2007-03-05
_[38] 웹사이트 ISC Launches DLV registry to kick off worldwide DNSSEC deployment https://www.isc.org/[...] 2008-11-18
_[39] 웹사이트 Interim Trust Anchor Repository https://itar.iana.or[...]
_[40] 웹사이트 .ORG is the first open TLD signed with DNSSEC http://pir.org/index[...]
_[41] 웹사이트 .ORG the Most Secure Domain? http://www.internetn[...] 2008-09-27
_[42] 웹사이트 .ORG Registrar List — with DNSSEC enabled at the top https://web.archive.[...] 2010-06-23
_[43] 웹사이트 VeriSign: We will support DNS security in 2011 http://www.networkwo[...] 2009-03-03
_[44] 웹사이트 VeriSign: Major internet security update by 2011 https://web.archive.[...] 2009-11-18
_[45] 웹사이트 .com Domain Finally Safe https://archive.toda[...]
_[46] 웹사이트 Verisign's Matt Larson Wins 2011 InfoWorld Technology Leadership Award http://www.circleid.[...]
_[47] 웹사이트 The InfoWorld 2011 Technology Leadership Awards http://www.infoworld[...]
_[48] 웹사이트 DNSSEC Project Archive https://www.iana.org[...]
_[49] 뉴스 Feds Start Moving on Net Security Hole http://blog.wired.co[...] CondéNet 2008-10-09
_[50] 보도자료 Press Release: NTIA Seeks Public Comments for the Deployment of Security Technology Within the Internet Domain Name System http://www.ntia.doc.[...] National Telecommunications and Information Administration, U.S. Department of Commerce 2008-10-09
_[51] 보도자료 Commerce Department to Work with ICANN and VeriSign to Enhance the Security and Stability of the Internet's Domain Name and Addressing System https://web.archive.[...] National Institute of Standards and Technology 2017-07-13
_[52] 웹사이트 DNSSEC for the Root Zone http://www.ripe.net/[...]
_[53] 웹사이트 ICANN, Verisign place last puzzle pieces in DNSSEC saga https://web.archive.[...] 2010-05-17
_[54] 웹사이트 DNSSEC to become standard on .ORG domains by end of June https://web.archive.[...] 2010-03-24
_[55] 웹사이트 Verisign deploys DNSSEC on .com TLD https://web.archive.[...]
_[56] 웹사이트 More security for root DNS servers http://www.h-online.[...] Heise Online 2010-03-24
_[57] 웹사이트 DNSSEC Update from ICANN 42 in Dakar http://www.circleid.[...]
_[58] 웹사이트 ISC Launches DLV registry to kick off worldwide DNSSEC deployment https://www.isc.org/[...] 2011-06-14
_[59] RFC Automated Updates of DNS Security (DNSSEC) Trust Anchors
_[60] RFC The DNSSEC Lookaside Validation (DLV) DNS Resource Record
_[61] RFC DNSSEC Lookaside Validation (DLV)
_[62] 웹사이트 DLV Replaced With Signed Empty Zone - Internet Systems Consortium https://www.isc.org/[...] 2020-06-05
_[63] 웹사이트 BIND 9.16.0, Stable Branch for 2020 and Beyond - Internet Systems Consortium https://www.isc.org/[...] 2020-06-05
_[64] 웹사이트 Unbound 1.5.4 Changes https://nlnetlabs.nl[...] 2020-06-05
_[65] IETF Moving DNSSEC Lookaside Validation (DLV) to Historic Status Internet Engineering Task Force 2020-03
_[66] 웹사이트 Department of Homeland and Security wants master key for DNS http://www.heise.de/[...] Heise 2007-03-30
_[67] 뉴스 Analysis: of Owning the keys to the Internet http://www.upi.com/S[...] United Press International 2007-04-21
_[68] 웹사이트 UPI Analysis: Owning the keys to the Internet http://www.mail-arch[...] 2011-03-24
_[69] 웹사이트 DNSSEC Deployment Initiative Newsletter - Volume 1, Number 2 http://www.dnssec-de[...] 2006-06
_[70] 웹사이트 Memorandum For Chief Information Officers http://www.whitehous[...] Executive Office Of The President — Office Of Management And Budget 2008-08-22
_[71] 뉴스 Feds tighten security on .gov http://www.networkwo[...] Network World 2008-09-22
_[72] 블로그 Comcast Blog - DNS Security Rollout Begins http://blog.comcast.[...] Comcast Blog 2010-10-18
_[73] 웹사이트 Comcast DNSSEC Public Service Announcement Video http://www.dnssec.co[...] Comcast 2010-10-18
_[74] 블로그 Comcast Completes DNSSEC Deployment http://blog.comcast.[...] Comcast 2012-01-11
_[75] 블로그 Geoff Huston: DNS, DNSSEC and Google's Public DNS Service (CircleID) http://www.circleid.[...] CircleID
_[76] 블로그 Introducing Verisign Public DNS http://www.circleid.[...] CircleID
_[77] 웹사이트 Use of DNSSEC Validation for World (XA) http://stats.labs.ap[...] APNIC Labs
_[78] 블로그 Google Public DNS Now Supports DNSSEC Validation https://security.goo[...] Google Code Blog 2013-06-01
_[79] 웹사이트 Quad9 FAQ https://www.quad9.ne[...] 2018-07-07
_[80] 웹사이트 Implementing Inbound SMTP DANE with DNSSEC for Exchange Online Mail Flow https://techcommunit[...] 2024-05-28
_[81] 블로그 Calling time on DNSSEC? https://blog.apnic.n[...] 2024-05-28
_[82] 블로그 DNSSEC on Windows 7 DNS client http://blogs.technet[...] Microsoft 2008-11-11
_[83] 문서 DNSSEC in Windows Server https://www.dns-oarc[...]
_[84] 웹사이트 複数のDNSサーバ製品におけるキャッシュポイズニングの脆弱性 https://www.jpcert.o[...] JPCERT コーディネーションセンター 2008-07-25
_[85] 문서 WIDE合宿におけるDNS攻撃実験 http://member.wide.a[...] WIDE Project 2005-01-31
_[86] 문서 ポート53を使わずにポート443を使う
_[87] 논문 public DNSとプライバシー
_[88] 웹사이트 DNSSEC and BIND https://www.isc.org/[...] Internet Systems Consortium 2009-09-13
_[89] 웹사이트 JPCERT/CC REPORT 2008-09-10 https://www.jpcert.o[...] JPCERT コーディネーションセンター 2008-09-10
_[90] 웹사이트 .ORG is the First Open Top-Level Domain to be Signed with Domain Name Security Extensions http://pir.org/node/[...] Public Interest Registry 2009-06-02
_[91] 뉴스 VeriSign: We will support DNS security in 2011 http://www.networkwo[...] Network World, Inc. 2009-02-24
_[92] 뉴스 ベリサイン、2年以内に全トップレベル・ドメインでDNSSEC導入へ http://www.computerw[...] IDG Japan, Inc. 2009-02-25
_[93] 웹사이트 VeriSign Announces DNSSEC Deployment Support Plans to Enhance Internet Security https://press.verisi[...] VeriSign, Inc. 2009-12-23
_[94] 웹사이트 ルートゾーンへのDNSSECの導入と展開 https://jprs.jp/rela[...] Japan Registry Services Co., Ltd. 2009-12-16
_[95] 웹사이트 JPドメイン名サービスへのDNSSECの導入予定について http://jprs.jp/info/[...] Japan Registry Services Co., Ltd. 2009-07-09
_[96] 웹사이트 DNSの安定性とセキュリティを提供するベリサインのPublic DNS – ベリサイン https://www.verisign[...]
_[97] 웹사이트 Norton ConnectSafe https://dns.norton.c[...]
_[98] 웹사이트 独自開発によるDNSSECの実現 {{!}} IIJの技術 {{!}} インターネットイニシアティブ（IIJ） https://www.iij.ad.j[...] 2021-01-23
_[99] 웹사이트 InfoSphere {{!}} NTTPCコミュニケーションズ https://www.sphere.n[...] 2021-01-23
_[100] 웹사이트 SANNET ホームページ［DNSSEC］DNS Security Extensions https://www.sannet.n[...]
_[101] 뉴스 ICANN会合やルートゾーンKSKロールオーバーなど2019年の「ドメイン名ニュース」 (2/2) https://ascii.jp/ele[...] 2021-01-23
_[102] 웹사이트 RFC-6944 http://tools.ietf.or[...] IETF
_[103] 논문 Using the Domain Name System for System Break-Ins http://citeseer.ist.[...] 1995

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com