혁신

DNSSEC (DOMAIN NAME SYSTEM SECURITY EXTENSION)

엔드-투-엔드로 인터넷 인증

DNSSEC에 대한 공통적인 질문들

DNSSEC의 기능은 무엇인가요?

DNSSEC는 공개키 암호화를 사용해 권한 영역 데이터에 디지털 서명을 함으로써 위조된 DNS 데이터로부터 인터넷 커뮤니티를 보호합니다. 사용자들은 DNSSEC 확인을 통해 데이터가 알려진 소스로부터 나온 것이며 전송 중에 변형되지 않았다는 것을 알고 안심할 수 있습니다. DNSSEC는 도메인 네임이 존재하지 않는 것도 확인할 수 있습니다.

DNSSEC가 DNS 보안을 강화시켜 주기는 하지만 완전한 해결책은 아닙니다. DDoS(분산 서비스 거부) 공격을 차단하거나 데이터 교환의 기밀성을 보장하거나 웹 사이트 데이터를 암호화하거나 IP 주소 스푸핑 및 피싱을 차단하지는 않습니다. DDoS 완화, 보안 인텔리전스, SSL (Secure Sockets Layer) 암호화 및 사이트 유효성 검사, 이원 인증 등의 다른 보호 방법도 보다 안전한 인터넷을 만드는 데 매우 중요합니다. 이러한 메커니즘이 DNSSEC와 함께 사용되어야 합니다.

DNSSEC는 누구에게 혜택을 주나요?

DNSSEC는 인터넷 인프라 생태계 내에 있는 모든 구성원에 영향을 미칩니다. DNSSEC를 효과적으로 배포하려면 인터넷 커뮤니티 내의 많은 이해 당사자들의 참여가 필요합니다. 레지스트리, 레지스트라, 도메인 네임 등록자, 하드웨어 및 소프트웨어 벤더, ISP 정부 기관 및 일반 인터넷 사용자들 모두 성공을 보장하고 인터넷 보안의 핵심적 측면을 강화하는 데 있어 각자의 역할을 수행해 주어야 합니다. DNSSEC의 장점:

  • 인터넷 커뮤니티는 서명된 영역 내의 보안을 향상시킬 수 있습니다.
  • 레지스트라는 고객들에게 도메인 서명 서비스를 제공할 수 있습니다.
  • ISP는 고객들에게 돌아오는 데이터의 보안을 강화할 수 있습니다.
  • 사용자들은 캐시 중독이나 MITM 공격 같은 DNS 취약점으로부터 스스로를 보호할 수 있습니다.

DNSSEC는 어떻게 작동하나요?

DNSSEC의 각 영역에는 한 쌍의 공개/개인 키가 있습니다. 영역의 공개 키는 DNS를 사용하여 게시되는 반면, 영역의 개인 키는 안전하게 오프라인으로 보관됩니다(이상적임). 영역의 개인 키는 해당 영역에서 개별 DNS 데이터에 서명하여, DNS와 함께 게시되는 디지털 서명을 만듭니다. DNSSEC는 엄격한 신뢰 모델을 사용하며 이 신뢰 체인은 상위 영역에서 하위 영역으로 이동합니다. 높은 레벨(상위) 영역이 낮은 레벨(하위) 영역의 공개 키에 사인(보증)합니다. 이 영역들의 ANS (authoritative name server)는 레지스트라, ISP 웹호스팅업체 또는 웹사이트 운영자(등록자)가 관리할 수 있습니다.

일반 사용자가 어떤 웹사이트에 액세스하고자 하는 경우, 해당 사용자의 OS 내에 있는 스텁 리졸버(stub resolver)가 ISP에 위치해 있는 RNS (recursive name server)에 도메인 네임 기록을 요청합니다. 이 레코드를 요청한 후 서버는 또한 해당 영역에 연결된 DNSSEC 키를 요청합니다. 서버는 이 키를 사용해 받은 정보가 ANS 상에 있는 정보와 일치한다는 사실을 확인할 수 있습니다.

주소 레코드가 ANS (authoritative name server)에서 전송되었는지 그리고 전송 중에 변경되지 않았는지 RNS (recursive name server)가 확인하면 도메인 네임이 결정되고 사용자는 사이트에 액세스할 수 있습니다. 이 프로세스를 유효성 검사(validation)라고 부릅니다. 주소 레코드가 수정되었거나 지정된 소스로부터 온 것이 아닌 경우 RNS (recursive name server)는 사용자가 이 사기성 주소에 액세스하는 것을 허용하지 않습니다. DNSSEC는 도메인 네임이 존재하지 않는 것도 확인할 수 있습니다.

DNSSEC는 인터넷 보안의 전반적인 문제를 얼마나 잘 해결하나요?

인터넷 보안이라는 퍼즐을 맞추는 데는 많은 조각들이 필요합니다. DNSSEC는 MITM 공격이나 캐시 중독 등에 의한 보안 우려를 완화시킬 수 있지만 전체적인 보안 해결책은 아닙니다. DNSSEC는 스푸핑이나 피싱 같은 가장 흔한 인터넷 보안 위협의 많은 부분을 해결하지 못합니다. 그렇기 때문에, 모두에게 안전한 인터넷을 만드는 데 있어 SSL 인증이나 이원 인증 등과 같은 다른 보호층이 반드시 필요합니다.

사용자가 어떻게 공격을 알 수 있나요?

인터넷 커뮤니티는 아직 사용자들에게 공격을 알려 주는 표준화된 시스템을 고안해 내지 못했습니다. 한 가지 가능한 해결책은 사용자들이 인증된(authneticated) 목적지로 라우팅된 경우 그 사실을 사용자들에게 알려주는 "DNSSEC 인식(DNSSEC -aware)" 브라우저를 개발하는 것입니다.

Verisign은 DNSSEC를 적용하기 위해 무엇을 하고 있나요?

2010년 7월, Verisign은 IANA (Internet Assigned Numbers Authority ) 및 미상무부 (DoC)와 협력하여 루트 영역(DNS 계층 구조의 출발점)에서 DNSSEC 배치를 완료했습니다. 또한 EDUCAUSE 및 DoC와의 협력을 통해 2010년 7월에 DNSSEC를 .edu에 채택한 Verisign은 2010년 12월에 .net 및 2011년 3월에 .com에서 DNSSEC를 채택했습니다.

Verisign의 DNSSEC 배포 전략은 무엇인가요?

Verisign의 DNSSEC 배포 전략은 우선 작은 영역부터 시작해서 각 배포를 평가해 시사점을 확인한 후 다음 영역으로 넘어가는 것입니다. .com 영역이 가장 크기 때문에 가장 마지막에 서명했습니다. 전세계 인터넷 기반 상거래와 커뮤니케이션의 상당수를 처리하는 도메인을 공략하기 전에 당사는 최대한 많은 경험을 축적하고자 했습니다.

DNSSEC 성공을 위해 무엇이 필요한가요?

DNSSEC가 성공적으로 배포될 경우, 전자상거래, 온라인 뱅킹, 이메일, VoIP, 온라인 소프트웨어 보급 등, 수많은 인터넷 활동에 대한 신뢰성을 높임으로써 전세계 인터넷 커뮤니티가 혜택을 볼 수 있습니다. 하지만 DNSSEC를 성공적으로 이끌기 위해서는 전체 인터넷 커뮤니티가 함께 책임감을 가지고 노력해야 할 것입니다. 성공을 위해서는 레지스트리, 레지스트라, 등록자, 호스트업체, 소프트웨어 개발업체, 하드웨어 업체, 정부, 인터넷 기술 전문가 및 연합 등의 적극적이고 체계적인 참여가 필요합니다.

누가 DNSSEC를 채택 또는 배포하고 있나요?

인터넷 루트 영역, 즉, .gov, .org, .museum 및 국가 코드 TLD(ccTLD) 등과 같은 최상위 도메인(TLD)들은 해당 관리 대상 영역에 대해 서명을 했습니다. .edu, .net, .com 등과 같은 다른 TLD들의 경우 2010/2011년도에 DNSSEC를 실행했습니다. 이러한 TLD들은 DNSSEC가 서명된 차상위 도메인 네임을 승인했습니다. Comcast 같은 대형 ISP들은 사용자 쿼리에 응답하는 RNS (recursive name server)에 대한 유효성 검사(validation)을 했고, 일부 레지스트라의 경우 로드맵에 DNSSEC 시행을 포함시키고 있습니다. 또한, ICANN (Internet Corporation for Assigned Names and Numbers)이 새 TLD 신청 접수를 개시했으며, DNSSEC 구현 계획 수립이 새 TLD 요청 수락 요건이 될 가능성이 큽니다.

DNSSEC가 배포된 후에도 SSL(Secure Sockets Layer)이 필요하나요?

DNSSEC와 SSL은 모두 공개 키 암호화를 바탕으로 하지만, 서로를 대체하기보다는 서로의 기능을 보완하는, 각기 다른 기능을 수행합니다.

아주 단순한 모델로 살펴보면, DNSSEC는 "어디"를 담당하는 반면, SSL은 "누구"와 "어떻게"를 맡고 있습니다.

  • 어디—DNSSEC는 디지털 서명을 사용해 DNS 데이터 무결성을 확인하고, 이를 통해 사용자가 원하는 IP 주소에 도달할 수 있도록 해줍니다. 사용자가 일단 원하는 주소에 도달하면 DNSSEC의 임무는 완료됩니다. DNSSEC는 해당 주소에 있는 개체의 신분은 확인하지 않으며 사용자와 해당 사이트 사이의 상호 작용은 암호화하지 않습니다.
  • 누구—SSL은 디지털 인증서를 사용해 사이트의 정체를 확인합니다. 이러한 인증서가 신뢰할 수 있는 외부 인증 기관(CA)이 발행한 인증서인 경우, SSL은 사용자에게 해당 웹사이트 소유자의 신원을 확인해 줍니다. 하지만, SSL은 사용자가 원하는 사이트에 도달하는 것을 보장해 주지 않기 때문에 사용자를 다른 곳으로 리디렉트하는 공격에 대해서는 적용되지 않습니다. 다시 말해, SSL 사이트 확인은 효과적이지만, 먼저 사용자가 올바른 목적지 사이트에 도달해야만 확인 기능이 효과를 발휘합니다.
  • 어떻게—SSL은 또 디지털 인증서를 사용해 사용자와 사이트 사이의 데이터 교환을 암호화함으로써 금융 거래, 통신 내용, 전자상거래, 기타 민감한 상호 작용의 기밀성을 보호해 줍니다.

함께 사용할 경우, DNSSEC 및 SSL은 다음과 같이 인터넷의 보안과 신뢰를 높입니다. 사용자들은 자신이 어디로 향하는지, 누구와 상호소통을 하는지, 자신의 거래가 얼마나 기밀로 처리되고 있는지 신뢰를 가지고 확인할 수 있습니다.

DNSSEC가 법적 또는 산업 표준으로서 필수적인가요?

미국의 경우, OMB(Office of Management and Budget: 미행정관리예산국)는 메모 08-23을 통해 2009년 1월까지 최상위 레벨 .gov 도메인에 DNSSEC를 사용하고, 2009년 12월까지 미연방정부기구들이 외부 사이트에 DNSSEC를 사용할 것을 규정하고 있습니다. .gov 레지스트리는 2009년 초에 서명되었습니다. DISA (U.S. Defense Information Systems Agency: 미국방정보시스템원)는 .mil 도메인에서도 OMB DNSSEC 요건을 충족시킬 계획입니다. 미연방정보보안관리법(FISMA: U.S. Federal Information Security Management Act) 규정은 2010년 중반까지 모든 연방 기관들이 인트라넷에서도 DNSSEC를 사용 개시할 것을 요구하고 있습니다. 현재, 공공 웹사이트 운영자들의 경우 도메인 보안을 위해 DNSSEC를 반드시 사용해야 한다는 요건은 없습니다.

DNSSEC는 어떻게 개발되어 왔나요?

1994년: 도입 가능 표준 첫 초안이 발표됨
1997년: RFC 2065 발표됨(DNSSEC는 IETF 표준) 

1999년: RFC 2535 발표됨(DNSSEC 표준 개정) 

2005년: 발표된 표준들의 총 개정
RFC 4033 (도입 및 요건) 
RFC 4034 (새로운 리소스 기록) 
RFC 4035 (프로토콜 변경) 

2010년 7월: 루트 영역 서명됨 

2010년 7월: .edu 서명됨 

2010년 12월: .net 서명됨 

2011년 2월: DNSSEC 구현 가능 .gov 레지스트리 업무가 Verisign으로 이관됨 

2011년 3월: .com 서명됨 

2011년 3월: Verisign Managed DNS 서비스가 DNSSEC 준수 완전 지원으로 개선됨 

2012년 1월: Comcast, 자사 고객들이 DNSSEC-인증 리졸버를 사용한다고 발표 

2012년 3월: 서명한 TLD가 90개로 증가