도메인 네임시스템 보안 확장

Domain Name System Security Extensions
인터넷 보안
프로토콜
키 관리
응용 프로그램레이어
도메인 네임 시스템
인터넷 레이어

Domain Name System Security Extensions(DNSEC; 도메인네임 시스템보안 확장)는 Internet Protocol(IP) 네트워크의 Domain Name System(DNS; 도메인네임 시스템)에서 교환되는 데이터를 보호하기 위한 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)의 확장 사양 스위트입니다.이 프로토콜은 데이터의 암호화 인증, 인증된 존재 거부 및 데이터 무결성을 제공하지만 가용성이나 기밀성은 제공하지 않습니다.

개요

도메인 네임 시스템의 원래 설계에는 보안 기능이 포함되어 있지 않았습니다.확장 가능한 분산 시스템으로만 생각되었습니다.DNSSEC(Domain Name System Security Extensions)는 하위 호환성을 유지하면서 보안을 추가하려고 합니다.Request for Comments 3833은 DNS 및 DNSSEC에 대한 기존 위협의 일부를 문서화합니다.

DNSSEC은 DNS 캐시 포이즈닝에 의해 생성된 것과 같은 위조 또는 조작된 DNS 데이터를 DNS를 사용하는 응용 프로그램이 받아들이는 것을 방지하기 위해 설계되었습니다.DNSSEC 보호 존으로부터의 모든 응답은 디지털 서명됩니다.DNS 리졸바는 디지털 서명을 체크함으로써 존 소유자가 공개하고 신뢰할 수 있는 DNS 서버에서 제공되는 정보와 정보가 동일한지(변경되지 않은 완전한지) 확인할 수 있습니다.IP 주소의 보호는 많은 유저에게 있어서 시급한 과제이지만, DNSSEC는 텍스트 레코드(TXT)나 메일 교환 레코드(MX)를 포함한 DNS에 공개되어 있는 모든 데이터를 보호할 수 있습니다.또, 증명서 레코드(Certificate Records, Certificate Records)등의 DNS에 격납되어 있는 암호화 증명서에 대한 참조를 발행하는 다른 시큐러티 시스템을 부트 스트랩 하기 위해서도 가능합니다.RFC 4398), SSH 핑거프린트(SSHFP, RFC 4255), IPSec 공개키(IPsecKEY, RFC 4025), TLS Trust Anchor(TLSA, RFC 6698) 또는 Encrypted Client Hello(ECH의 경우 SVCB/HTPS 레코드).[2]

DNSSEC는 데이터의 기밀성을 제공하지 않습니다.특히, 모든 DNSSEC 응답은 인증되지만 암호화되지는 않습니다.DNSSEC는 DoS 공격으로부터 직접 보호하지는 않지만 간접적으로 이점을 제공합니다(시그니처 체크는 잠재적으로 신뢰할 수 없는 [citation needed]당사자를 사용할 수 있기 때문입니다).

DNS 서버간에 송신되는 벌크 데이터(DNS 존 전송등)의 시큐러티 확보에는, DNSSEC 가 아닌 다른 표준이 사용됩니다.IETF RFC 4367에 기재되어 있는 바와 같이 일부 사용자 및 개발자는 DNS 이름에 대해 잘못된 가정을 합니다.예를 들어 회사의 공통 이름과 ".com"을 항상 도메인 이름으로 가정합니다.DNSSEC는 잘못된 가정으로부터 데이터를 보호할 수 없습니다.도메인 [citation needed]소유자의 데이터인지 아닌지만 인증할 수 있습니다.

DNSSEC 사양(DNSEC-bis라고 함)은 현재의 DNSSEC 프로토콜을 매우 상세하게 기술하고 있습니다.RFC 4033, RFC 4034 및 RFC 4035 를 참조해 주세요.이러한 새로운 RFC(2005년 3월)가 발표됨에 따라 RFC 2535는 폐지되었습니다.

DNS의 보안은 인터넷 전체의 보안에 매우 중요하다고 널리[3] 알려져 있습니다만, DNSSEC의 도입은 특히 몇 가지 어려움으로 인해 방해받고 있습니다(2010년 1월 22일 현재).

  • 인터넷 크기에 맞게 확장할 수 있는 하위 호환 규격 설계 필요성
  • 필요한 경우 "구역 열거" 방지
  • 다양한 DNS 서버 및 리졸바(클라이언트)에 대한 DNSSEC 구현 도입
  • 최상위 도메인 루트 키를 소유할 사용자를 두고 구현자 간에 의견 불일치가 발생함
  • DNSSEC 및 DNSSEC 도입의 복잡성 극복

작동

DNSSEC는 공개키 암호화를 사용하여 DNS 룩업을 위한 레코드에 디지털 서명함으로써 작동합니다.올바른 DNSKEY 레코드는 신뢰받는 서드파티인 DNS 루트존의 검증된 공개키 세트부터 신뢰 체인을 통해 인증됩니다.도메인 소유자는 자신의 키를 생성하고 도메인 이름 레지스트라의 DNS 제어판을 사용하여 업로드합니다.이것에 의해, 존 오퍼레이터(예를 들면, .com 의 경우는 Verisign)가 DNS 에 서명해 퍼블리시 합니다.

자원 레코드

DNS는 여러 리소스 레코드를 사용하여 구현됩니다.DNSSEC 를 실장하기 위해서, 다음의 몇개의 새로운 DNS 레코드 타입이 작성 또는 조정되어 DNSSEC 와 함께 사용할 수 있게 되었습니다.

RRSIG(리소스 레코드 시그니처)
레코드 세트의 DNSSEC 시그니처가 포함됩니다.DNS 리졸바는 DNSKEY 레코드에 저장된 공개 키를 사용하여 서명을 확인합니다.
DNS 키
DNS 리졸바가 RRSIG 레코드의 DNSSEC 시그니처를 확인하기 위해 사용하는 공개 키를 포함합니다.
DS(위임 서명자)
위임된 영역의 이름을 유지합니다.서브 위임 존의 DNSKEY 레코드를 참조합니다.DS 레코드는 위임 NS 레코드와 함께 부모 존에 배치됩니다.
NSEC(다음 시큐어 레코드)
영역의 다음 레코드 이름에 대한 링크가 포함되어 레코드 이름에 대해 존재하는 레코드 유형을 나열합니다.DNS 리졸바는 NSEC 레코드를 사용하여 DNSSEC 검증의 일부로서 레코드명과 타입이 존재하지 않는 것을 확인합니다.
NSEC3(다음 시큐어 레코드 버전 3)
존 내의 다음 레코드명에 대한 링크(해시 이름 정렬 순서)가 포함되어 NSEC3 레코드 자신의 이름의 첫 번째 라벨에 해시 값이 포함되는 이름의 레코드 타입이 나열됩니다.이러한 레코드는 DNSSEC 검증의 일부로서 레코드명과 타입이 존재하지 않는 것을 확인하기 위해서 리졸바에 의해서 사용할 수 있습니다.NSEC3 레코드는 NSEC 레코드와 비슷하지만 NSEC3에서는 암호화 해시된 레코드 이름을 사용하여 존 내의 레코드 이름의 열거를 회피합니다.
NSEC3PARAM(다음 시큐어 레코드 버전3 파라미터)
정규 DNS 서버는 이 레코드를 사용하여 존재하지 않는 이름 또는 유형에 대한 DNSSEC 요구에 대한 응답에 포함할 NSEC3 레코드를 계산 및 결정합니다.

DNSSEC 를 사용하는 경우, DNS 검색에 대한 각 응답에는, 요구된 레코드 타입에 가세해 RRSIG DNS 레코드가 포함됩니다.RRSIG 레코드는 응답 DNS 리소스 레코드 세트의 디지털 서명입니다.디지털 서명은 DNSKEY 레코드에서 발견된 올바른 공개 키를 찾아 확인합니다.NSEC 레코드 및 NSEC3 레코드는 Resource Record(RR; 자원 레코드)가 존재하지 않는다는 암호화 증거를 제공하기 위해 사용됩니다.DS 레코드는 신뢰 체인을 사용한 검색 절차에서 DNSKEY 인증에 사용됩니다.NSEC 및 NSEC3 레코드는 스푸핑에 대한 강력한 내성을 위해 사용됩니다.

알고리즘

DNSSEC은 기존 알고리즘에 대한 공격이 발견되면 하위 호환 방식으로 새로운 알고리즘을 도입할 수 있도록 확장 가능하도록 설계되었습니다.다음 표에 2013년 4월 현재 가장 자주 [4]사용되는 보안 알고리즘을 정의합니다.

[ Algorithm ]필드 알고리즘. 원천 DNSSEC 서명 DNSSEC 검증[5]
1 RSA/MD5 구현하지 말 것 구현하지 말 것
3 DSA/SHA-1 구현하지 말 것 구현하지 말 것
5 RSA/SHA-1 RFC 3110 권장하지 않음 필수의
6 DSA-NSEC3-SHA1 구현하지 말 것 구현하지 말 것
7 RSASA1-NSEC3-SHA1 RFC 5155 권장하지 않음 필수의
8 RSA/SHA-256 RFC 5702 필수의 필수의
10 RSA/SHA-512 권장하지 않음 필수의
12 고스트 R 34.10-2001 RFC 5933 구현하지 말 것 선택적.
13 ECDSA/SHA-256 RFC 6605 필수의 필수의
14 ECDSA/SHA-384 선택적. 권장된
15 Ed25519 RFC 8080 권장된 권장된
16 Ed448 선택적. 권장된
[ Digest ]필드 다이제스트 원천 구현현황[6]
1 SHA-1 RFC 3658 필수의
2 SHA-256 RFC 4509 필수의
3 고스트 R 34.10-2001 RFC 5933 선택적.
4 SHA-384 RFC 6605 선택적.

조회 절차

보안 인식 DNS 리졸바는 DNS 검색 결과를 통해 쿼리 대상 도메인의 정규 네임서버가 DNSSEC를 지원하는지 여부, 수신한 응답이 안전한지 여부 및 일종의 오류가 있는지 여부를 판단할 수 있습니다.검색 순서는 많은 ISP 등의 재귀 네임서버와 메인스트림오퍼레이팅시스템에 디폴트로 포함되어 있는 스터브리졸바와는 다릅니다.Microsoft Windows 에서는 stub resolver 가 사용되며, 특히 Windows Server 2008 R2 및 Windows 7 에서는 검증은 되지 않지만 DNSSEC 대응의 stub resolver [7][8]가 사용됩니다.

재귀 네임 서버

신뢰 체인 모델을 사용하면 부모 도메인(DNS 존)의 위임 서명자(DS) 레코드를 사용하여 서브도메인 내의 DNSKEY 레코드를 확인할 수 있습니다.이 레코드는 서브도메인을 확인하기 위해 다른 DS 레코드를 포함할 수 있습니다.ISP 네임서버등의 재귀 리졸바가 도메인 「www.example.com」의 IP 주소(레코드 및/또는 AAAA 레코드)를 취득하고 싶다고 합니다.

  1. 이 프로세스는 보안 인식 리졸바가 DNS 쿼리에서 "DO"("DNSEC OK")[9] 플래그 비트를 설정하면 시작됩니다.DO 비트는 Extension Mechanism for DNS(EDNS; 확장 메커니즘)에 의해 정의된 확장 플래그 비트에 포함되어 있기 때문에 모든 DNSSEC 트랜잭션은 EDNS를 지원해야 합니다.또한 DNSSEC 트랜잭션에 필요한 훨씬 큰 패킷사이즈를 허용하려면 EDNS 지원이 필요합니다.
  2. 리졸바는 일반 DNS 검색 프로세스를 통해 응답을 수신하면 응답이 올바른지 확인합니다.이상적으로는 보안 인식 리졸바는 DNS 루트에서 DS 및 DNSKEY 레코드를 확인하는 것으로 시작합니다.그런 다음 루트에 있는 "com" 최상위 도메인의 DS 레코드를 사용하여 "com" 존의 DNSKEY 레코드를 확인합니다.여기서부터 "com" 존에 "example.com" 서브도메인에 대한 DS 레코드가 있는지 여부를 확인하고 있는 경우 DS 레코드를 사용하여 "example.com" 존에 있는 DNSKEY 레코드를 확인합니다.마지막으로 "www.example.com"에 대한 A 레코드의 답변에 있는 RRSIG 레코드를 확인합니다.

위의 예에는 몇 가지 예외가 있습니다.

첫째, "example.com"이 DNSSEC를 지원하지 않는 경우 응답에 RRSIG 레코드가 없고 "com" 존에 "example.com"의 DS 레코드가 없습니다."example.com"에 대한 DS 레코드가 있지만 응답에 RRSIG 레코드가 없는 경우 뭔가 잘못되어 있으며 중간 공격을 받은 사람이 DNSSEC 정보를 삭제하고 A 레코드를 수정하고 있을 수 있습니다.또는 쿼리에서 DO 플래그 비트를 삭제하거나 응답에서 RRSIG 레코드를 삭제한 도중에 보안에 문제가 있는 네임서버가 고장났을 가능성이 있습니다.또는 설정 오류일 수 있습니다.

다음으로, 「www.example.com」라고 하는 도메인명이 없는 경우가 있습니다.이 경우 응답에 RRSIG 레코드를 반환하는 대신 NSEC 레코드 또는 NSEC3 레코드가 있습니다.이러한 레코드는 해결자가 도메인 이름이 존재하지 않음을 증명할 수 있는 "next secure" 레코드입니다.NSEC/NSEC3 레코드에는 위와 같이 확인할 수 있는 RRSIG 레코드가 있습니다.

마지막으로 "example.com" 존이 DNSSEC를 구현하지만 "com" 존 또는 루트존 중 하나가 구현하지 않아 다른 방법으로 검증할 필요가 있는 "security"가 생성됩니다.2010년 7월 15일부로 루트에 대한 DNSSEC 도입이 완료되었습니다.[10].com 도메인은 유효한 보안 키로 서명되었으며,[11] 안전한 위임은 2011년 4월 1일 루트존에 추가되었습니다.

스터브 리졸바

스터브 리졸바는 "재귀 쿼리 모드를 사용하여 DNS 확인 작업의 대부분을 재귀 네임 [12]서버로 오프로드하는 최소 DNS 리졸바"입니다.스터브 리졸바는 단순히 요구를 재귀 네임서버에 전송하고 응답의 Authenticated Data(AD; 인증 데이터) 비트를 사용하여 "재귀 [13]네임서버가 응답의 [Answer]섹션과 [Authority]섹션의 모든 데이터에 대한 시그니처를 검증할 수 있었는지 여부를 확인합니다."Microsoft Windows 에서는 stub resolver 가 사용되며, 특히 Windows Server 2008 R2 및 Windows 7 에서는 검증은 되지 않지만 AD 비트 대응의 stub resolver [7][8]가 사용됩니다.

검증 중인 스터브리졸바는 쿼리 [13]메시지로 Checking Disabled(CD; 체크 디세이블) 비트를 설정하여 자체 시그니처 검증을 실행할 수도 있습니다.검증 중인 스터브리졸바는 CD 비트를 사용하여 자체 재귀 인증을 수행합니다.이러한 검증 스터브리졸바를 사용하면 인터넷서비스 공급자 또는 도메인 접속을 신뢰할 수 없는 경우에도 클라이언트는 DNSSEC를 구현하는 도메인의 엔드 투 엔드 DNS 보안을 확보할 수 있습니다.

검증되지 않은 스터브리졸바는 사용자의 인터넷서비스 공급자 또는 퍼블릭 재귀 네임서버에 의해 제어되는 외부 DNSSEC 검증 서비스 및 DNS over [13][14]TLS 등의 방법을 사용하여 서버와 네임서버 간의 통신채널에 의존해야 합니다.

신뢰 앵커 및 인증 체인

DNS 응답이 올바른 것을 증명하려면 DNS 이외의 소스로부터 올바른 키 또는 DS 레코드를 적어도1개 알아야 합니다.이러한 시작점은 신뢰 앵커라고 하며 일반적으로 운영 체제 또는 다른 신뢰할 수 있는 소스를 통해 얻습니다.DNSSEC가 처음 설계되었을 때 필요한 신뢰 앵커는 DNS 루트뿐이라고 생각되었습니다.루트 앵커는 2010년 [15]7월 15일에 처음 발행되었습니다.

인증 체인은 일련의 링크된 DS 레코드와 DNSKEY 레코드로, 문제의 도메인의 신뢰할 수 있는 네임서버에 대한 앵커부터 시작합니다.완전한 인증 체인이 없으면 DNS 검색에 대한 응답을 안전하게 인증할 수 없습니다.

시그니처 및 존서명

리플레이 공격을 제한하기 위해 캐시 목적의 일반 DNS TTL 값뿐만 아니라 시그니처의 유효성을 제한하기 위한 추가 타임스탬프가 RRSIG 레코드에 있습니다.레코드가 송신되었을 때에 상대적인 TTL 값과 달리 타임스탬프는 절대적입니다.즉, 모든 보안 인식 DNS 리졸바에는 클럭이 몇 분 이내에 거의 동기화되어 있어야 합니다.

이러한 타임스탬프는 존이 정기적으로 재서명되어 세컨더리 서버에 재배포될 필요가 있음을 나타냅니다.그렇지 않으면 시그니처는 리졸바 검증에 의해 거부됩니다.

키 관리

DNSSEC 에는, DNSKEY 레코드에 격납되어 있는 다양한 키와 신뢰 앵커를 형성하기 위한 다른 송신원으로부터의 키가 포함됩니다.

키 교환을 허용하려면 키 롤오버 방식이 필요합니다.일반적으로 이 작업에는 기존의 오래된 키와 더불어 새로운 DNSKEY 레코드의 새로운 키를 먼저 롤아웃하는 작업이 포함됩니다.그 후 Time to Live 값이 오래된 키의 캐시를 통과했다고 가정해도 안전한 경우 이러한 새 키를 사용할 수 있습니다.마지막으로 오래된 키를 사용한 레코드의 캐싱이 기한이 지났다고 해도 안전할 경우 오래된 DNSKEY 레코드를 삭제할 수 있습니다.루트 등 operating system의 갱신이 필요한 앵커를 신뢰하는 키 등의 경우에는 이 프로세스가 더욱 복잡합니다.

DNSKEY 레코드의 키는 2개의 다른 용도로 사용할 수 있으며 일반적으로는 각각 다른 DNSKEY 레코드가 사용됩니다.먼저 다른 DNSKEY 레코드에 서명하기 위해 사용되는 Key Signing Key(KSK; 키 서명 키)가 있습니다.둘째, 다른 레코드에 서명하기 위해 사용되는 Zone Signing Key(ZSK; 존 서명 키)가 있습니다.ZSK는 1개의 특정 DNS 존에 의해 완전히 제어되어 사용되므로 보다 쉽고 빈번하게 스위칭할 수 있습니다.그 결과 ZSK는 KSK보다 훨씬 짧으며 RRSIG/DNSKEY 레코드의 크기를 줄이면서도 동일한 수준의 보호를 제공할 수 있습니다.

새로운 KSK가 생성되면 DS 레코드는 부모존으로 전송되어 거기에 퍼블리시되어야 합니다.DS 레코드는 레코드 크기를 작게 유지하기 위해 전체 키가 아닌 KSK 메시지 다이제스트를 사용합니다.이것은 매우 큰 .com 도메인 등의 존에 도움이 됩니다.부모 존의 DS 키를 갱신하는 순서도 부모 존에 DNSKEY 레코드가 필요했던 이전의 DNSSEC 버전보다 간단합니다.

DANE 작업 그룹

DNS 기반의 Authentication of Named Entities(DANE; 명명된 엔티티 인증)는[16] 인터넷애플리케이션이 DNSSEC에 근거해 TLS, DTLS, SMTP, 및 S/MIME과 암호화로 보호된 통신을 확립하는 것을 목적으로 하는 IETF 작업 그룹입니다.

새로운 프로토콜은 공개 키 인프라를 기반으로 하는 기존 모델에 대한 추가 보증과 제약을 가능하게 합니다.또한 도메인 소유자가 타사 인증 기관을 참조하지 않고 직접 인증서를 확인할 수 있습니다.

Google Chrome 14에서는 [17]DNSSEC 스테이플 인증서의 지원이 유효하게 되어 있었습니다만,[18] 나중에 삭제되었습니다.Mozilla Firefox의 경우 네이티브 지원이 현재 [20]다른 사용자가 작업을 시작하기를 기다리는 동안 추가[19] 기능에 의해 지원이 제공되었습니다.

역사

DNS는 중요하고 기본적인 인터넷 서비스이지만 1990년 Steve Bellovin은 DNS의 심각한 보안 결함을 발견했습니다.그것을 확보하기 위한 연구가 시작되었고 1995년 [21]그의 논문이 발표되었을 때 극적으로 진전되었다.최초의 RFC 2065는 1997년에 IETF에 의해 발행되었습니다.이 사양을 실장하기 위한 최초의 시도는 1999년에 IETF RFC 2535로서 개정(완전 동작 가능한 것으로 생각됨)되었습니다.RFC 2535에 근거해 DNSSEC를 도입하는 계획이 작성되었습니다.

안타깝게도 IETF RFC 2535 사양은 인터넷 전체까지 확장하는데 매우 큰 문제가 있었습니다.2001년까지 이 사양은 대규모 네트워크에서는 사용할 수 없는 것이 분명해졌습니다.통상의 동작에서는, DNS 서버가 부모 서버와 동기 할 수 없게 되는 일이 자주 있습니다.이것은 보통 문제가 되지 않지만, DNSSEC가 유효하게 되어 있는 경우, 이 비동기 데이터는 심각한 자기 생성 서비스 거부의 영향을 미칠 수 있습니다.원래 DNSSEC에서는 자녀의 키 변경을 수행하기 위해 복잡한 6개의 메시지 프로토콜과 많은 데이터 전송이 필요했습니다(DNS 자식 영역은 모든 데이터를 부모에게 전송하고 부모가 각 레코드를 서명하도록 한 다음 자녀가 SIG 레코드에 저장할 수 있도록 해당 서명을 자녀에게 다시 전송해야 했습니다).또, 공개 키의 변경은, 부조리한 영향을 미칠 가능성이 있습니다.예를 들면, 「.com」존이 공개 키를 변경했을 경우, 2200만 개의 레코드를 송신할 필요가 있습니다(모든 자녀의 시그니처를 갱신할 필요가 있기 때문입니다).따라서 RFC 2535에서 정의된 DNSSEC는 인터넷까지 확장할 수 없었습니다.

IETF는 DNSSEC를 근본적으로 변경했습니다.이는 RFC 2535의 원래 DNSSEC 접근법과 구별하기 위해 필요에 따라 DNSSEC-bis라고 불립니다.이 새로운 버전에서는 "위임 서명자(DS) 리소스 레코드"를 사용하여 상위 영역과 하위 영역 간의 위임 지점에서 추가 수준의 간접 기능을 제공합니다.새로운 접근법에서는 자녀의 마스터 공개 키가 변경되면 자녀의 모든 레코드에 대해 6개의 메시지가 있는 대신 아이가 새 공개 키를 부모에게 보내는 간단한 메시지가 하나 있습니다(물론 서명됨).부모들은 단지 아이들 한 명당 하나의 마스터 공개키를 저장한다; 이것은 훨씬 더 실용적이다.이는 부모와 자녀 간에 대량의 데이터가 교환되는 대신 약간의 데이터가 부모에게 푸시된다는 것을 의미합니다.즉, 클라이언트는 키를 확인할 때 조금 더 많은 작업을 수행해야 합니다.구체적으로는 DNS 존의 KEY RRset을 검증하려면 RFC 2535에서 요구하는 것이 아니라2개의 시그니처 검증 조작이 필요합니다(다른 타입의 RRset에 대해 검증되는 시그니처의 수에 영향은 없습니다).대부분의 경우 DNSSEC 도입이 보다 실용적이기 때문에 이를 작은 비용으로 간주하고 있습니다.

NXDOMAIN 응답 및 NSEC 인증

도메인의 부재를 암호화로 증명하려면 존재하지 않는 도메인에 대한 모든 쿼리에 대한 응답에 서명해야 합니다.이는 키를 온라인으로 사용할 수 있는 상태로 유지하는 온라인 서명 서버에서는 문제가 되지 않습니다.그러나 DNSSEC은 존 서명 키를 콜드 스토리지에 보관할 수 있도록 오프라인 컴퓨터를 사용하여 레코드에 서명하도록 설계되었습니다.이는 존재하지 않는 도메인에 대한 쿼리에 대한 응답을 인증하려고 할 때 발생할 수 있는 모든 호스트 이름 쿼리에 대한 응답을 미리 생성할 수 없기 때문에 문제를 나타냅니다.

초기 해결책은 존 내의 도메인 쌍별로 NSEC 레코드를 작성하는 것이었습니다.따라서 클라이언트가 존재하지 않는 레코드에 대해 문의한 경우k.example.com서버는 NSEC 레코드로 응답합니다.NSEC 레코드에는, 이 레코드 사이에 아무것도 존재하지 않는 것이 기술되어 있습니다.a.example.com그리고.z.example.com단, 존에 대한 정보는 기존의 인증되지 않은 NXDOMAIN 오류보다 더 많이 유출됩니다.이는 존이 실제 도메인의 존재를 보여주기 때문입니다.

도메인 보행 방지

NSEC3 레코드(RFC 5155)는 직접 나열하지 않고 이름을 해시하는 대체 수단으로 작성되었습니다.시간이 지남에 따라 GPU와 전용 하드웨어를 사용한 해싱이 향상됨에 따라 NSEC3 응답은 오프라인 사전 공격을 통해 저비용으로 강제될 수 있었습니다.NSEC5는 존 변경에 사용할 수 있는 개인 키를 유지할 필요 없이 신뢰할 수 있는 서버가 NSEC 응답에 서명할 수 있도록 제안되었습니다.따라서 NSEC5KEY를 도용하면 [22]존을 보다 쉽게 열거할 수 있을 뿐입니다.

프로토콜의 난잡한 발전과 하위 호환성을 유지하려는 욕구로 인해 온라인 DNSSEC 서명 서버는 존재 거부를 직접 인증하는 대신 "흰 거짓말"을 반환합니다.RFC 4470에서 개략적으로 기술된 기술은 요청된 도메인을 어휘적으로 둘러싼 도메인의 쌍을 포함하는 NSEC 레코드를 반환합니다.예를 들어 다음과 같은 경우k.example.com따라서 NSEC 레코드에 의해 (가정) 도메인 사이에 아무것도 존재하지 않는 것이 증명됩니다.j.example.com그리고.l.example.com이것은 NSEC3 [23]레코드에서도 가능합니다.

CloudFlare는 응답 규모의 [24]3분의 1로 동일한 결과를 얻을 수 있는 두 가지 대안적 접근 방식을 개척했습니다.첫 번째는 일반적인 DNS 클라이언트의 동작을 이용하여 부재를 보다 간결하게 [25]기술하는 '블랙 거짓말'이라고 불리는 '화이트 거짓말은 '블랙 거짓말'이라고 불립니다.두 번째 접근법은 대신 "기록은 존재하지만 요청된 기록 유형은 존재하지 않는다"는 것을 증명하는 것을 선택하는데, 이를 "DNS 샷건"[26][24]이라고 한다.

도입

인터넷은 중요한 인프라스트럭처이지만 그 운용은 근본적으로 안전하지 않은 DNS에 의존합니다.따라서 DNS의 보안을 확보하기 위한 강력한 인센티브가 존재하며 일반적으로 DNSSEC의 도입은 이 작업의 중요한 부분으로 간주됩니다.예를 들면, 미국의 사이버 스페이스 시큐어 전략(National Strategy to Secure Cyberspace)은,[27] DNS의 시큐어 필요성을 특정했습니다.DNSEC의 대규모 전개는, E-메일 주소의 시큐어 키 배포 등, 그 외의 많은 시큐러티 문제도 해결할 수 있습니다.

대규모 네트워크에 DNSSEC를 도입하는 것도 어렵습니다.Ozment와 Schechter는 DNSSEC(및 기타 테크놀로지)에 '부트스트랩 문제'가 있음을 인식하고 있습니다.일반적으로 사용자는 즉각적인 이점을 얻을 수 있는 경우에만 테크놀로지를 도입합니다.그러나 최소한의 도입이 필요한 경우에는 (DNSEC의 경우와 마찬가지로) 비용 이상의 이점을 얻을 수 있습니다.DNSSEC는 DNS 계층의 어느 레벨에서도 전개할 수 있지만, 다른 많은 계층이 채택하기 전에 존 내에서 널리 사용할 수 있어야 합니다.DNS 서버는 DNSSEC를 지원하는 소프트웨어로 업데이트해야 하며 DNSSEC 데이터를 생성하여 DNS 존 데이터에 추가해야 합니다.TCP/IP를 사용하는 클라이언트는 DNSSEC 기능을 사용하려면 DNS 리졸바(클라이언트)를 업데이트해야 합니다.또한 리졸바는 DNSSEC 사용을 시작하기 전에 신뢰할 수 있는 공용 키를 적어도1개 가지고 있거나 취득할 방법이 있어야 합니다.

DNSSEC 를 실장하면, 일부의 DNS 서버에 큰 부하가 걸릴 가능성이 있습니다.일반적인 DNSSEC 서명 응답은 기본 UDP 크기인 512바이트보다 훨씬 큽니다.이론적으로 이것은 여러 IP fragment를 통해 처리할 수 있지만 필드의 많은 "중간 상자"는 이러한 fragment를 올바르게 처리하지 못합니다.이것에 의해, 대신에 TCP 가 사용됩니다.그러나, 현재의 많은 TCP 실장에서는, TCP 접속 마다 대량의 데이터가 보존되고 있습니다.고부하 서버는, 대량의 DNSSEC 요구에 응답하려고 하는 것만으로 리소스가 부족할 가능성이 있습니다.TCP Cookie Transactions와 같은 일부 프로토콜 확장 기능은 이러한 [28]로드를 줄이기 위해 개발되었습니다.인터넷은 많은 조직에게 매우 중요하기 때문에 이러한 과제에 대처하기 위해 DNSSEC를 도입하기 위한 상당한 노력이 계속되고 있습니다.

조기 도입

얼리어답터에는 브라질(.br), 불가리아(.br), 체코(.cz), 나미비아(.na)[29] 푸에르토리코(.pr) 및 스웨덴(.se)이 있으며, 이들은 국가 코드 [30]최상위 도메인에 DNSSEC를 사용합니다.RIPE NCC는 Internet Number Authority(IANA)[31]로부터 위임된 모든 역방향 조회 레코드(in-addr.arpa)에 서명했습니다.ARIN도 리버스 [32]존에 서명하고 있습니다.2007년 2월에 TDC는 스웨덴 ISP 최초로 고객에게 [33]이 기능을 제공하기 시작했습니다.

IANA는 2007년 6월부터 샘플 서명 루트 테스트를 실시했습니다.루트의 생산 계약 전 이 기간 동안 여러 개의 대체 신뢰 앵커도 존재했습니다.IKS Jena는 [34]2006년 1월 19일에, Internet Systems Consortium은 같은 해 [35]3월 27일에, ICANN은 2009년 [36]2월 17일에 각각 1개를 발표했습니다.

2009년 6월 2일, 공익 레지스트리의 .org 존의 레지스트리 서비스 프로바이더인 Afilias는 .org [37]TLD에 서명했습니다.Afilias와 PIR는 2008년 9월 26일에도 "2009년 [38]초"를 시작으로 그들의 도메인에 서명할 수 있는 첫 번째 단계가 될 것이라고 상술했다.2010년 6월 23일 13개의 레지스트라가 DNSSEC 레코드를 제공하는 것으로 리스트 되어 있습니다.ORG [39]도메인

VeriSign은 .com 도메인과 .net 도메인이 NSEC3 실험의 목적으로 등록될 수 있도록 하는 파일럿 프로젝트를 실행했습니다.2009년 2월 24일, [40]24개월 이내에 모든 최상위 도메인(.com, .net 등)에 DNSSEC를 도입한다고 발표했으며, 같은 해 11월 16일에는 구현의 기술적 [41]측면으로 인해 지연된 후 2011년 1분기까지 .com 도메인과 .net 도메인이 서명될 것이라고 밝혔습니다.이 목표는 예정대로[42] 달성되었으며, Verisign의 DNSSEC 부사장인 Matt Larson은 DNSSEC를 [43][44]발전시키는 데 기여한 공로로 InfoWorld의 2011년 기술 리더십 상을 수상했습니다.

DNS 루트에서의 전개

DNSSEC는 [45]2010년7월 15일에 루트레벨로 처음 도입되었습니다.루트 신뢰 앵커를 사용하여 루트로부터의 완전한 신뢰 체인을 가진 모든 DNSSEC 존을 검증할 수 있기 때문에, 이것에 의해 DNSSEC 리졸바 전개가 큰폭으로 심플화될 것으로 예상됩니다.신뢰 체인을 검증하려면 중단 없이 신뢰할 수 있는 루트로 트레이스해야 하므로 위의 존 중 하나가 안전하지 않은 경우에도 신뢰 앵커를 시큐어 존으로 설정해야 합니다.예를 들어 존 "signed.example.org"은 보호되지만 "example.org" 존이 보호되지 않은 경우 ".disc" 존과 루트가 서명되어 있어도 존을 검증하기 위해 신뢰 앵커를 배치해야 합니다.

뿌리채택을 둘러싼 정치적 이슈는 주로 다음과 같은 몇 가지 핵심 이슈에 관한 지속적인 관심사였다.

  • 다른 나라들은 인터넷에 대한 미국의 통제에 대해 우려하고 있으며, 이러한 이유로 중앙 집중식 키 입력을 거부할 수 있습니다.
  • 일부 정부에서는 DNSSEC가 지원하는 암호화 키 배포를 금지하려고 할 수 있습니다.

계획.

2008년 9월에는 ICANN과 VeriSign이 각각 구현 제안을[46] 발표했으며, 10월에는 NTIA(National Telecommunications and Information Administration)가 대중에게 의견을 [47]요청했습니다.접수된 코멘트가 최종 도입 계획의 설계에 영향을 미쳤는지는 불명확하다.

2009년 6월 3일, 미국 국립표준기술원(NIST)은 ICANN, VeriSign [48]및 NTIA와 함께 2009년 말까지 루트에 서명할 계획이라고 발표했습니다.

2009년 10월 6일 제59회 RIPE Conference 회의에서 ICANN과 VeriSign은 루트존에 [49]DNSSEC를 도입하기 위한 도입 예정 일정을 발표했습니다.회의에서는 2009년 12월 1일부터 매월 1개의 루트네임 서버에 단계적으로 도입하여 최종 루트네임 서버는 2010년7월 1일에 DNSSEC 서명존을 제공하고 루트존은 RSA/SHA256 DNSKEY로 [49]서명할 예정입니다.증분 롤아웃 기간 동안 루트존은 더미 키를 사용하는 고의적으로 유효하지 않은 루트존(DURZ)을 처리합니다.[50]최종 DNSKEY 레코드는 2010년7월 1일까지 배포되지 않습니다.이는 존 사용에 서명하기 위해 사용된 키가 의도적으로 검증할 수 없음을 의미합니다.이 배치의 이유는 DNSSEC 자원 레코드를 요구하는 쿼리에 대한 응답이 커짐에 따라 발생하는 트래픽패턴의 변화를 감시하기 위해서입니다.

.org 탑레벨 도메인은 2010년6월에 DNSSEC와 체결된 후 2010년과 [51][52]2011년에 .com, .net 및 .edu가 체결되었습니다.국가 코드 최상위 도메인은 2010년 [53]5월부터 키를 보관할 수 있었다.2011년 11월 현재 최상위 도메인의 25% 이상이 DNSSEC에 [54]서명되어 있습니다.

실행

2010년 1월 25일, L(ell) 루트 서버는 의도적으로 유효하지 않은 루트 존(DURZ)의 서비스를 개시했습니다.존에서는 RFC 5702에서 [55][56][57]정의된 대로 RSA 알고리즘을 사용하여 작성된 SHA-2(SHA-256) 해시의 시그니처가 사용됩니다.2010년 5월 현재 13대의 루트 서버 모두 DURZ [50]서비스를 시작했습니다.2010년 7월 15일 첫 번째 루트 풀 프로덕션 DNSSEC 루트 존이 SOA 시리얼 2010071501과 함께 서명되었습니다.루트 트러스트 앵커는 [45]IANA에서 사용할 수 있습니다.

TLD 레벨에서의 도입

루트 아래에는 완전한 DNSSEC 배치를 실현하기 위해 서명해야 하는 대규모 최상위 도메인 세트가 있습니다.인터넷 최상위 도메인 목록은 서명된 기존 최상위 도메인 중 루트에 링크된 도메인에 대한 세부 정보를 제공합니다.

DNSSEC 룩사이드 검증 - 이력

2006년 3월에 Internet Systems Consortium은 DNSSEC Lookaside Validation [58]레지스트리를 도입했습니다.DLV는 루트 신뢰 앵커가 없는 경우에 DNSSEC를 보다 쉽게 도입할 수 있도록 하기 위한 것입니다.당시에는 검증자가 DNS의 [59]서명된 서브트리에 대응하는 다수의 신뢰 앵커를 유지해야 한다고 생각되었습니다.DLV의 목적은 검증자가 신뢰 앵커 저장소를 관리하는 작업을 신뢰할 수 있는 서드파티에 오프로드할 수 있도록 하는 것이었습니다.DLV 레지스트리는 각 검증자가 자체 목록을 유지하는 작업을 반복하는 대신 신뢰 앵커의 중앙 목록을 유지합니다.

DLV를 사용하려면 DLV 존의 신뢰 앵커를 사용하여 BIND나 Unbound 등의 DLV를 지원하는 검증자가 필요했습니다.이 존에는 DLV [60]레코드가 포함되어 있습니다.이러한 레코드는 DS 레코드와 완전히 같은 형식이었지만 위임된 서브존을 참조하는 대신 DNS 트리 내의 다른 존을 참조했습니다.검증자가 루트로부터 체크하려고 하는 RRset에 대한 신뢰 체인을 검출할 수 없었던 경우, 다른 신뢰 [61]체인을 제공할 수 있는 DLV 레코드를 검색했습니다.

서명되지 않은 최상위 도메인이나 DNSSEC 위임을 지원하지 않는 레지스트라 등 신뢰 체인의 갭은 하위 도메인의 관리자가 DLV를 사용하여 DLV를 사용하도록 설정된 리졸바에서 DNS 데이터를 검증할 수 있음을 의미합니다.이로 인해 레지스트라 및 TLD 레지스트리에서 DNSSEC를 적절히 지원하도록 압력을 경감함으로써 DNSSEC 배치를 방해할 수 있습니다.또한 DLV는 DNSSEC 검증을 위해 액터 및 코드 경로를 추가함으로써 복잡성을 증가시켰습니다.

ISC는 2017년에 [62]DLV 레지스트리를 폐기했습니다.DLV 지원은 BIND 9.12에서 폐지되어 BIND 9.[63]16에서 완전히 삭제되었습니다.Unbound 버전 1.5.4(2015년 7월)는 예제 구성 [64]및 설명서 페이지에서 DLV를 사용 중지됨으로 표시했습니다.Not Resolver 및 PowerDNS Recurrent 또는 DLV를 구현하지 않았습니다.

2020년 3월에 IETF는 표준 DLV를 폐기하고 RFC 4432 및 RFC 5074를 "Historic" [65]상태로 변경하면서 RFC 8749를 발표했습니다.

미국 연방 정부에 의한 DNSSEC 배치 이니셔티브

미국 국토안보부(DHS) 과학기술국(Technology Directorate)은 "DNSEC 배치 이니셔티브"를 후원합니다.이 이니셔티브는 "모든 섹터가 공공 및 민간 부문의 많은 국가 및 조직이 참여하는 글로벌 협력 노력의 일환으로 인터넷의 명명 인프라의 보안을 향상시키는 보안 조치를 자발적으로 채택하도록 장려한다." DHS는 또한 DNSSEC를 성숙시키고 이를 미국 연방에 도입하기 위한 노력에 자금을 대기도 한다.알 정부

미 국토안보부는 2007년 3월 30일 DNS 루트존을 미국 정부의 수중에 확실히 서명할 수 있는 열쇠를 가지자고 제안한 것으로 알려졌다[66].그러나 회의실에는 미국 정부 당국자가 없었고 기사를 촉발시킨 발언은 다른 당사자에 의해 나왔다.DHS후 commented[67][68]왜 그들이 다른 사람들의 잘못된 결론은 미국 정부 이런 제안은 자신이 만든에게 말하였다.`그 미국 국토 안보부의 DNSSec을 시행하기 위한 기술 계획의 전개를 지원하고 있으며, 지난 10월 국제 전문가들의 com을 위해 긴 목록에 초기 초안을 배포했다 믿는 지에 대해.ments.초안에는 루트 존 키의 소유자 또는 "운영자"가 될 수 있는 일련의 선택권이 제시되어 있으며, 기본적으로는 정부 기관이나 건설업자에게 귀속됩니다.국토안보부의 사이버 보안 연구 개발 매니저인 마우건은 "이제 우리는 이 문서에서 루트 키 오퍼레이터의 신상에 대해 어떠한 제안도 하고 있다"고 말했다.

미국 연방정부에서의 DNSSEC 배치

NIST(National Institute of Standards and Technology)는 2006년 5월 16일 NIST Special Publication 800-81 Secure Domain Name System(DNS; 보안 도메인 네임 시스템) 도입 가이드와 함께 DNSSEC 도입 방법을 발표했습니다.NIST는 이 도입 가이드를 참조하여 NIST SP800-53-R1의 새로운 DNSSEC Federal Information Security Management Act(FISMA) 요건을 발표하려고 했습니다.미국 기관은 NIST SP800-53-R1의 최종 발행 후 이러한 새로운 FISMA [69]요건을 충족하기 위해 1년의 기간을 갖게 된다.다만, 그 시점에서는 NSEC3가 완료되지 않았습니다.NIST는 분할 도메인을 사용할 것을 제안했는데, 이 기법은 가능한 것으로 알려져 있지만 올바르게 배치하기 어려우며 위에서 언급한 보안 취약점이 있다.

2008년 8월 22일 관리예산국(OMB)은 미국 연방기관에 .gov 사이트에 DNSSEC를 배치하도록 요구하는 각서를 발표했습니다. .gov 루트는 2009년 1월까지, .gov 아래의 모든 서브도메인은 2009년 [70]12월까지 서명해야 합니다.이 메모는 .gov 사이트에 초점을 맞추고 있지만, 미 국방정보시스템국은 또한 .mil (미군) 도메인에서도 OMB DNSSEC의 요구사항을 충족시킬 것이라고 말한다.Network World의 Carolyn Duffy Marsan은 DNSSEC가 "고전적인 치킨 앤 에그 딜레마에 시달리고 있기 때문에 널리 도입되지 않았습니다.OMB의 명령으로 달걀이 [71]깨지고 있는 것 같다."

리졸바에서의 전개

여러 ISP가 DNSSEC 검증 DNS 재귀 리졸바 전개를 시작했습니다.Comcast는 2010년 10월[72][73] 18일에 그 의도를 발표하고 2012년 [74]1월 11일에 도입을 완료함으로써 미국에서 최초로 주요 ISP가 되었습니다.

APNIC의 조사에 따르면 DNSSEC 검증을 수행하는 DNS 리졸바만을 사용하는 클라이언트의 비율은 2013년 [75]5월에 8.3%로 증가했습니다.이 고객들 중 절반 가량은 구글의 공개 DNS 리졸버를 사용하고 있었다.

2015년 9월, Verisign은 무료 퍼블릭 DNS 리졸바 [76]서비스를 발표해, 보도 자료에는 기재되어 있지 않지만, DNSSEC 검증도 실시하고 있습니다.

APNIC의 모니터링에 따르면 2016년 초까지 DNSSEC 검증을 수행하는 DNS 리졸바만을 사용하는 클라이언트의 비율은 약 15%[77]로 증가했습니다.

DNSSEC 지원

Google의 공개 재귀 DNS 서버는 2013년 [78]5월 6일 DNSSEC 검증을 활성화했습니다.

가장 일반적인 DNS 관리 소프트웨어인 BIND는 버전9.5 이후 디폴트로 DNSSEC 지원을 이노블로 합니다.

Quad9 퍼블릭 재귀 DNS는 2016년 5월 11일 설립된 이후 메인 9.9.9 주소에 대해 DNSSEC 검증을 수행했습니다.Quad9은 주로 [79]디버깅을 위해 DNSSEC 검증을 수행하지 않는 대체 서비스도 제공합니다.

IETF 매뉴얼

  • RFC2535 도메인네임 시스템보안 확장
  • DNSSEC의 리졸바 지원을 나타내는 RFC 3225
  • RFC 3226 DNSSEC 및 IPv6 A6 Aware Server/Resolver 메시지사이즈 요건
  • RFC 3833 도메인네임 시스템의 위협 분석
  • RFC 4033 DNS 보안 개요 및 요건(DNSEC-bis)
  • RFC 4034 DNS 보안 확장(DNSEC-bis) 자원 레코드
  • RFC 4035 DNS 보안 확장 프로토콜 변경(DNSEC-bis)
  • RFC 4398 도메인네임 시스템(DNS)에서의 증명서 저장
  • RFC 4431 DNSSEC Lookaside Validation(DLV; 룩사이드 검증) DNS 리소스 레코드
  • RFC 4470 NSEC 레코드 및 DNSSEC 온라인 서명 최소 적용
  • RFC 4509 DNSSEC 위임 서명자(DS) 자원 레코드(RR)에서의 SHA-256 사용
  • RFC 4641 DNSSEC의 운용 프랙티스
  • RFC 4955 DNS 보안(DNSEC) 실험
  • RFC 5011 DNS 보안(DNSEC) 신뢰 앵커의 자동 갱신
  • RFC 5155 DNSSEC 해시된 존재 거부
  • RFC 5702 DNSKEY 및 DNSSEC용 RRSIG 리소스 레코드에서의 SHA-2 알고리즘 사용
  • RFC 6605 DNSSEC용 타원곡선 디지털 서명 알고리즘(DSA)
  • RFC 6725 DNS Security(DNSSEC) DNSKEY 알고리즘 IANA 레지스트리 업데이트
  • RFC 6781 DNSSEC 동작 프랙티스 버전2
  • RFC 6840 DNS 보안에 관한 설명 및 구현 노트(DNSEC)
  • RFC 7129 DNS에서의 인증된 존재 거부
  • RFC 7344 DNSSEC 위임 신뢰 유지 보수 자동화
  • RFC 7583 DNSSEC 키 롤오버 타이밍 고려 사항
  • RFC 8080 DNSSEC용 Edwards-Curve Digital Security Algorithm(EdDSA)
  • RFC 8624 DNSSEC 알고리즘 구현 요건 및 사용 가이드라인
  • RFC 8749 DNSSEC Lookaside Validation(DLV; 룩사이드 검증)을 이력 상태로 이행

도구들

DNSSEC 를 도입하려면 , 서버와 클라이언트측의 소프트웨어가 필요합니다.DNSSEC 를 서포트하는 툴에는, 다음과 같은 것이 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Draft-ietf-dnsop-SVCB-HTTPS-10 - Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRS)".
  2. ^ "Draft-ietf-TLS-esni-14 - TLS Encrypted Client Hello".
  3. ^ Dan Kaminsky와의 DNSSEC 인터뷰 (2009년 6월 25일)Kaminsky 인터뷰: DNSSEC는 조직 간 신뢰와 보안에 대처합니다.
  4. ^ "Domain Name System Security (DNSSEC) Algorithm Numbers". IANA. 2010-07-12. Retrieved 2010-07-17.
  5. ^ Wouters, Paul; Surý, Ondřej (June 2019). "RFC-8624". IETF.
  6. ^ "RFC-4035". IETF.
  7. ^ a b "Understanding DNSSEC in Windows". Microsoft. October 7, 2009. The Windows DNS client is a stub resolver...
  8. ^ a b "DNS Security Extensions (DNSSEC)". Microsoft. October 21, 2009. The DNS client in Windows Server 2008 R2 and Windows® 7 is a non-validating security-aware stub resolver.
  9. ^ Conrad, D. "Indicating Resolver Support of DNSSEC". Internet Engineering Task Force. Retrieved 27 April 2017.
  10. ^ "Root DNSSEC".
  11. ^ "Computing - the UK's leading source for the analysis of business technology".
  12. ^ 로즈, 스콧, 라슨, 맷, 매시, 댄, Austein, 롭;Arends, 로이(2005년 3월)."RFC4033:DNS보안 도입과 요구 사항".그 인터넷 협회:11.정의는 재귀적 이름 서버에 DNS확인 시의 작품의 대부분의 보유를 줄임에 재귀 쿼리 모드를 사용하는 스텁 resolvers, 공히 최소 DNSresolvers.( 도와 주)이보다 앞서 정의는 이전 RFC에:로버트 브레이든(1989년 10월)이 주어졌다{{ 들고 일기}}:Cite저널 journal=이 필요하다."RFC 1123 - Requirements for Internet Hosts -- Application and Support".IETF(인터넷 엔지니어링 태스크 포스):74."스터브 확인자"는 재귀 이름 서버[...]{{ 들고 일기}의 서비스 위에}:Cite저널journal=( 도와 주)을 요구한다 의존하고 있다.
  13. ^ a b c Rose, Scott; Larson, Matt; Massey, Dan; Austein, Rob; Arends, Roy (March 2005). "RFC 4033: DNS Security Introduction and Requirements". The Internet Society: 12. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  14. ^ Muñoz Merino, Pedro J.; García-Martínez, Alberto; Organero, Mario Muñoz; Kloos, Carlos Delgado (2006). Meersman, Robert; Tari, Zahir; Herrero, Herrero Martín (eds.). Enabling Practical IPsec Authentication for the Internet (PDF). On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops. Vol. 1. Springer. Archived from the original (PDF) on 2012-04-26.
  15. ^ 뿌리째 뽑다
  16. ^ IETF: 이름 있는 엔티티의 DNS 기반 인증(데인)
  17. ^ "ImperialViolet". Retrieved 2011-11-26.
  18. ^ "chromium git". Retrieved 2013-03-09.
  19. ^ "DNSSEC/TLSA Validator".
  20. ^ Bugzilla@Mozilla: Bug 672600 - 증명서 체인 검증 시 TLS 핸드쉐이크에 스테이플러로 고정되는 DNSSEC/DANE 체인 사용
  21. ^ Steve Bellovin, 1995년 "시스템 침입을 위한 도메인 네임 시스템 사용"
  22. ^ "NSEC5: Provably Preventing DNSSEC Zone Enumeration".
  23. ^ Authenticated Denial of Existence in the DNS. doi:10.17487/RFC7129. RFC 7129.
  24. ^ a b "Economical With The Truth: Making DNSSEC Answers Cheap". 2016-06-24.
  25. ^ "Black Lies". Compact DNSSEC Denial of Existence or Black Lies. sec. 2. I-D draft-valsorda-dnsop-black-lies.
  26. ^ "DNSSEC Done Right". 2015-01-29.
  27. ^ 사이버 공간 확보를 위한 미국의 국가전략, 2003년 2월 30일 페이지
  28. ^ Metzger, Perry; William Allen Simpson & Paul Vixie. "Improving TCP security with robust cookies" (PDF). Usenix. Retrieved 2009-12-17.
  29. ^ https://ccnso.icann.org/de/node/7603[베어 URL PDF]
  30. ^ 전자 프라이버시 정보 센터 (EPIC) (2008년 5월 27일)DNSSEC
  31. ^ RIPE NCC DNSSEC 정책 2007년 10월 22일 웨이백 머신에 아카이브
  32. ^ ARIN DNSSEC 배치 계획
  33. ^ Eklund-Löwinder, Anne-Marie (12 February 2012). "[dns-wg] Swedish ISP TCD Song Adopts DNSSEC". dns-wg mailing list. RIPE NCC. Retrieved 2 December 2012.
  34. ^ dns-wg 아카이브: 서명된 존 리스트 2007년 3월 5일 Wayback Machine에서 아카이브됨
  35. ^ ISC가 DLV 레지스트리를 기동하여 세계 각국의 DNSSEC 도입을 개시.아카이브는 2008년 11월 18일, Wayback Machine에서 행해집니다.
  36. ^ 중간 신뢰 앵커 저장소
  37. ^ .ORG는 DNSSEC에서 서명된 첫 번째 오픈 TLD입니다.
  38. ^ Sean Michael Kerner. ".ORG the Most Secure Domain?". www.internetnews.com. Retrieved 2008-09-27.
  39. ^ ".ORG Registrar List — with DNSSEC enabled at the top". Retrieved 2010-06-23.
  40. ^ VeriSign: 2011년도의 DNS 시큐러티를 서포트합니다.2009년 3월 3일, Wayback Machine에서
  41. ^ VeriSign: 2011년까지 주요 인터넷 보안 업데이트
  42. ^ .com 도메인이 드디어 안전해졌다
  43. ^ Verisign의 Matt Larson이 2011 InfoWorld Technology Leadership Award 수상
  44. ^ InfoWorld 2011 테크놀로지 리더십 어워드
  45. ^ a b "Root DNSSEC Status Update, 2010-07-16". 16 July 2010.
  46. ^ Singel, Ryan (October 8, 2006). "Feds Start Moving on Net Security Hole". Wired News. CondéNet. Retrieved 2008-10-09.
  47. ^ "Press Release: NTIA Seeks Public Comments for the Deployment of Security Technology Within the Internet Domain Name System" (Press release). National Telecommunications and Information Administration, U.S. Department of Commerce. October 9, 2008. Retrieved 2008-10-09.
  48. ^ "Commerce Department to Work with ICANN and VeriSign to Enhance the Security and Stability of the Internet's Domain Name and Addressing System" (Press release). National Institute of Standards and Technology. 3 June 2009.
  49. ^ a b "DNSSEC for the Root Zone" (PDF).
  50. ^ a b Hutchinson, James (6 May 2010). "ICANN, Verisign place last puzzle pieces in DNSSEC saga". NetworkWorld. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  51. ^ "DNSSEC to become standard on .ORG domains by end of June". Archived from the original on 2010-03-15. Retrieved 2010-03-24.
  52. ^ 문의자:Verisign은 .com TLD에 DNSSEC를 전개합니다.
  53. ^ 루트 DNS 서버의 보안 강화 Heise Online, 2010년 3월 24일
  54. ^ Circle ID: Dakar의 ICANN 42에서 DNSSEC 업데이트
  55. ^ "DNSSEC Root Zone High Level Technical Architecture" (PDF).
  56. ^ RFC 5702, § 2.1. "RSA/SHA-256에서 사용하는 RSA 공용 키는 알고리즘 번호8 의 DNSKEY Resource Record(RR; DNSKEY 리소스 레코드)에 저장됩니다."
  57. ^ RFC 5702, § 3.1. "RSA/SHA-256 시그니처는 알고리즘 번호8의 RRSIG 자원 레코드(RR)를 사용하여 DNS에 저장됩니다."
  58. ^ ISC가 DLV 레지스트리를 기동하여 전 세계 DNSSEC 도입을 개시.2011년 6월 14일 Wayback Machine에서 아카이브 완료
  59. ^ RFC 5011, "DNSSEC(Automated Updates of DNS Security) Trust Anchors" (DNSSEC) 신뢰 앵커 자동 업데이트)
  60. ^ RFC 4431 "DNSEC Lookaside Validation(DLV) DNS 리소스 레코드"
  61. ^ RFC 5074 "DNSEC Lookaside Validation (DLV)"
  62. ^ "DLV Replaced With Signed Empty Zone - Internet Systems Consortium". www.isc.org. 30 September 2017. Retrieved 2020-06-05.
  63. ^ "BIND 9.16.0, Stable Branch for 2020 and Beyond - Internet Systems Consortium". www.isc.org. 20 February 2020. Retrieved 2020-06-05.
  64. ^ "Unbound 1.5.4 Changes". NLnet Labs. Retrieved 2020-06-05.
  65. ^ Mekking, W.; Mahoney, D. (March 2020). Moving DNSSEC Lookaside Validation (DLV) to Historic Status. IETF. doi:10.17487/RFC8749. RFC 879. Retrieved 3 June 2020.
  66. ^ 국토안보부는 2007년 4월 6일 Wayback Machine Heise News에서 DNS 아카이브 마스터 키를 요구하고 있습니다.
  67. ^ 분석: 인터넷 UPI 키 소유, 2007년 4월 21일
  68. ^ UPI 분석: 인터넷 키 소유 2011년 3월 24일 - 첫 번째 링크가 다운되었습니다.이것은 같은 내용으로 생각됩니다.
  69. ^ DNSSEC 도입 이니셔티브 뉴스레터 - 2007년 11월 22일 Wayback Machine에서 제1권, 제2호 아카이브 완료, 2006년 6월
  70. ^ 2008년 9월 16일 대통령 Wayback Machine Executive Office of The President-Management and Budget, 2008년 8월 22일 최고정보책임자(CTO)에 대한 메모
  71. ^ Feds는 .gov의 보안을 강화했습니다.아카이브 2008년 9월 25일 Wayback Machine Network World, 2008년 9월 22일
  72. ^ Comcast 블로그 - DNS 보안 롤아웃 시작, 2010년 10월 18일
  73. ^ Comcast DNSSEC 공공 서비스 발표 비디오 2010-10-21 Wayback Machine 아카이브, 2010년 10월 18일
  74. ^ Comcast, DNSSEC 도입 완료, 2012년 1월 11일
  75. ^ Geoff Huston: DNS, DNSSEC 및 Google의 퍼블릭 DNS 서비스(Circle)아이디)
  76. ^ Verisign Public DNS 소개
  77. ^ 월드용 DNSSEC 검증(XA) 사용
  78. ^ Google Public DNS는 이제 DNSSEC Validation Google Code Blog, 2013년 6월 1일
  79. ^ "Quad9 FAQ". Quad9. Retrieved July 7, 2018.
  80. ^ Seshadri, Shyam (11 November 2008). "DNSSEC on Windows 7 DNS client". Port 53. Microsoft.
  81. ^ Windows Server에서의 DNSSEC

추가 정보

외부 링크