도메인 네임 시스템

3. 구조

도메인 이름 공간은 트리 형태로 구성된다. 트리의 각 노드는 0개 이상의 ''리소스 레코드(resource record)''를 가진다. 트리는 루트 존에서 시작하여 여러 개의 하위 존으로 나뉜다. 각 DNS 존은 하나의 권한 있는 ''네임 서버''에 의해 관리되는 노드들의 집합이다. 하나의 네임 서버가 여러 개의 존을 관리할 수도 있다.

관리 권한은 분할되어 새로운 존을 형성할 수 있다. 이때, 기존 도메인 이름 공간의 일부분이 서브도메인 형태로 다른 네임 서버에 권한이 ''위임''된다. 그리고 기존 존은 새로운 존에 대한 권한을 잃게 된다.

도메인 이름 형성 규칙은 RFC 1035, RFC 1123, RFC 2181에 정의되어 있다. 도메인 이름은 점으로 구분된 레이블(label)로 이루어지며, 가장 오른쪽 레이블은 최상위 도메인을 의미한다. 예를 들어 `www.example.com`에서 `com`이 최상위 도메인이다. 도메인의 계층은 오른쪽에서 왼쪽으로 내려가며, 왼쪽 레이블은 오른쪽 레이블의 서브도메인이다. 예를 들어, `example`은 `com` 도메인의 서브도메인이고, `www`는 `example.com`의 서브도메인이다.

각 레이블은 최대 63자, 전체 도메인 이름은 최대 253자까지 가능하다. 도메인 이름은 기술적으로 옥텟으로 표현 가능한 모든 문자를 사용할 수 있지만, 실제로는 ASCII 문자 집합의 일부(알파벳 a-z, A-Z, 숫자 0-9, 하이픈)만 허용된다. 이를 LDH 규칙이라고 한다. 도메인 이름은 대소문자를 구분하지 않으며, 레이블은 하이픈으로 시작하거나 끝날 수 없다.

3. 1. 도메인 이름 공간

3. 2. 도메인 이름 형성

• 가장 오른쪽 레이블은 최상위 도메인을 의미한다. 예를 들어, 도메인 이름 `www.example.com`은 최상위 도메인 `com`에 속한다.
• 도메인의 계층 구조는 오른쪽부터 왼쪽으로 내려간다. 왼쪽의 레이블은 오른쪽의 서브도메인이다. 예를 들어, 레이블 `example`은 `com` 도메인의 서브도메인이며, `www`는 `example.com`의 서브도메인이다. 서브도메인은 127단계까지 가능하다.^[20]
• 각 레이블은 최대 63개 문자를 사용할 수 있고, 전체 도메인 이름은 253개 문자를 초과할 수 없다.^[15] 실제로는 도메인 레지스트리에 더 짧은 제한을 가질 수 있다.
• 도메인 이름은 기술적으로 옥텟으로 표현할 수 있는 모든 문자를 사용할 수 있다. 그러나 DNS 루트 존과 대부분의 서브도메인에서는 제한된 형식과 문자들만 허용한다. 레이블에 사용될 수 있는 문자는 ASCII 문자 집합의 부분집합과 알파벳 a부터 z, A부터 Z, 숫자 0부터 9와 하이픈(-)을 포함한다. 이 규칙은 letter(문자), digit(숫자), hyphen(하이픈)의 첫글자를 따서 LDH 규칙이라고 한다. 도메인 이름은 대소문자 구분없이 해석되고, 레이블은 하이픈으로 시작하거나 끝날 수 없다.

3. 3. 네임 서버

3. 3. 1. 권한 있는 네임 서버

4. 작동 방식

DNS는 사람이 이해하기 쉬운 호스트 이름을 IP 주소로 변환하는 "이름 해석(해결)"을 수행한다. 예를 들어, `www.example.com`이라는 호스트 이름은 (IPv4) 및 (IPv6) 주소로 변환될 수 있다.^[3] 이 과정을 수행하는 클라이언트 측 구조나 프로그램을 "리졸버" 또는 "네임 리졸버"라고 한다.

DNS는 분산 데이터베이스 시스템으로, 인터넷상의 여러 DNS 서버에 정보가 분산되어 저장된다. 각 도메인은 존(zone)이라는 관할 구역으로 나누어 관리된다. 존은 도메인 네임 스페이스상의 어떤 부분에 해당하며, 각각의 존은 독립적인 DNS 콘텐츠 서버에 의해 관리된다.^[16] DNS 콘텐츠 서버는 관리하는 존의 호스트 이름과 IP 주소의 조합을 담은 데이터베이스를 가지며, 클라이언트(또는 DNS 캐시 서버)의 요청에 따라 해당 호스트 이름에 대응하는 IP 주소를 반환한다.

DNS는 클라우드 서비스 및 콘텐츠 전송 네트워크와 같은 분산 인터넷 서비스에서 핵심적인 역할을 수행한다.^[3] 사용자가 URL을 사용하여 이러한 서비스에 접근하면, URL의 도메인 이름은 사용자에게 가까운 서버의 IP 주소로 변환된다. 이때 서로 다른 사용자가 동시에 동일한 도메인 이름에 대해 서로 다른 변환을 받을 수 있다는 점이 중요하다.^[4] 이는 사용자에게 더 빠르고 안정적인 응답을 제공하는 데 기여한다.

DNS 클라이언트는 루트 서버에서 시작하여 여러 DNS 서버를 거치며 최종적인 호스트 이름의 IP 주소를 얻는다 (DNS 재귀 검색).^[11][12] 예를 들어, `ja.wikipedia.org`라는 호스트 이름의 IP 주소를 검색하는 과정은 다음과 같다.

# 클라이언트는 우선 루트 서버 중 하나(예: `A.ROOT-SERVERS.NET`, `198.41.0.4`)에 `org` 도메인의 네임 서버를 문의한다.

# 루트 서버는 `org` 도메인의 네임 서버 중 하나(예: `a7.nstld.com`, `192.5.6.36`)를 알려준다.

# 클라이언트는 `org` 도메인의 네임 서버에 `wikipedia.org` 도메인의 네임 서버를 문의한다.

# `org` 도메인의 네임 서버는 `wikipedia.org` 도메인의 네임 서버(예: `dns34.register.com`, `216.21.226.87`)를 알려준다.

# 클라이언트는 `wikipedia.org` 도메인의 네임 서버에 `ja.wikipedia.org`의 IP 주소를 문의하여 최종 응답을 받는다.

이러한 과정은 #주소 확인 메커니즘에서 더 자세히 설명된다.

4. 1. 주소 확인 메커니즘

4. 1. 1. 재귀 및 캐싱 네임 서버

4. 2. DNS 리졸버

• '''비재귀 쿼리''': DNS 리졸버가 해당 서버가 권한을 가지고 있는 레코드를 제공하거나, 다른 서버를 쿼리하지 않고 부분적인 결과를 제공하는 DNS 서버에 쿼리를 보내는 방식이다. 캐싱 DNS 리졸버의 경우, 로컬 DNS 캐시에 대한 비재귀 쿼리는 결과를 제공하며, 상위 DNS 서버로부터 초기 응답을 받은 후 일정 기간 동안 DNS 리소스 레코드를 캐싱하여 상위 DNS 서버의 부하를 줄인다.

• '''재귀 쿼리''': DNS 리졸버가 단일 DNS 서버에 쿼리를 보내며, 이 서버는 요청자를 대신하여 다른 DNS 서버에 다시 쿼리를 보낼 수 있는 방식이다. 예를 들어, 홈 라우터에서 실행되는 간단한 스텁 리졸버는 일반적으로 사용자의 ISP에서 운영하는 DNS 서버에 재귀 쿼리를 보낸다. DNS 서버는 필요에 따라 다른 네임 서버에 쿼리를 보내어 쿼리에 완전히 응답한다. 일반적인 작동 방식에서 클라이언트는 캐싱 재귀 DNS 서버에 재귀 쿼리를 발행하고, 이 서버는 그 후 응답을 결정하기 위해 비재귀 쿼리를 발행하여 클라이언트에 단일 응답을 다시 보낸다. 리졸버 또는 리졸버를 대신하여 재귀적으로 작동하는 다른 DNS 서버는 쿼리 헤더의 비트를 사용하여 재귀 서비스의 사용을 협상한다. DNS 서버는 재귀 쿼리를 지원할 필요는 없다.

• '''반복 쿼리''': DNS 리졸버가 하나 이상의 DNS 서버 체인에 쿼리를 보내는 과정이다. 각 서버는 요청을 완전히 확인할 수 있을 때까지 체인의 다음 서버를 클라이언트에게 참조한다. 예를 들어, www.example.com의 가능한 확인은 글로벌 루트 서버, "com" 서버, 마지막으로 "example.com" 서버에 쿼리를 보낼 것이다.

4. 3. 순환 종속성 및 글루 레코드

4. 4. 레코드 캐싱

4. 5. 역방향 조회

4. 6. 클라이언트 조회

4. 6. 1. 손상된 리졸버

5. 주요 DNS 목록

DNS를 잘못 설정할 경우 인터넷 이용에 문제가 생길 수 있으므로, 신뢰할 수 있는 DNS 서버만 이용하는 것이 권장된다.

기본적으로 통신사가 제공하는 DNS는 서버가 한국에 소재하여 빠른 응답 속도를 보여준다.

구글과 시만텍의 DNS는 한국에 서버가 소재하진 않지만, 인접국인 일본에 서버가 소재하고 있어, 40ms 미만의 응답 속도를 보여준다.

클라우드플레어의 DNS는 한국에 서버를 두어 응답속도가 3~5ms정도의 응답속도를 보인다.^[61][62][63]

6. 보안 문제

초기 도메인 네임 시스템(DNS) 설계는 보안을 주요 고려 사항으로 삼지 않았다. 이는 네트워크가 일반 대중에게 개방되지 않았기 때문이다. 그러나 1990년대 인터넷이 상업 부문으로 확장되면서 데이터 무결성과 사용자 인증을 보호하기 위한 보안 조치가 필요하게 되었다.^[44]

DNS 캐시 포이즈닝과 같은 여러 취약성 문제가 발견되고 악용되었다. DNS 응답은 전통적으로 암호화 서명을 갖지 않아 많은 공격 가능성을 야기했다. 도메인 네임 시스템 보안 확장(DNSSEC)은 암호화된 서명이 포함된 응답을 지원하도록 DNS를 수정한다. 전방 확인 역방향 DNS와 같은 기술도 DNS 결과를 검증하는 데 사용될 수 있다.

DNS는 대부분의 인터넷 사용자가 평소에 의식하지 못하는 투명한 시스템이지만, 그 역할은 매우 중요하다. 어떤 도메인을 관리하는 DNS 서버가 정지되면 해당 도메인 내의 호스트를 나타내는 URL이나 이메일 주소의 이름 해결 등이 불가능해져, 네트워크가 사용자와 연결되어 있어도 해당 도메인 내의 서버에는 사실상 접근할 수 없게 된다. 따라서 중요한 DNS 서버는 이중화되는 경우가 많다.

또한 DNS 스푸핑을 통해 정보를 쉽게 도청 및 위조할 수 있다. 정보 레코드의 부정한 수정을 방지하기 위해 콘텐츠 서버의 마스터(프라이머리)는 인터넷(외부)에서 숨기고, 인터넷에는 특정 마스터의 복사본(존 전송)을 받는 슬레이브(세컨더리)를 공개하는 등의 구성을 통해 방어 수단을 강구한다.

6. 1. DNS 스푸핑

6. 2. DNSMessenger

7. 개인 정보 및 추적 문제

원래 공개적이고 계층적이며 분산된, 그리고 캐싱이 많이 되는 데이터베이스로 설계된 DNS 프로토콜은 기밀성 제어가 없다. 사용자 쿼리 및 네임서버 응답은 암호화되지 않은 상태로 전송되어 네트워크 패킷 스니핑, DNS 하이재킹, DNS 캐시 포이즈닝 및 중간자 공격을 가능하게 한다.^[50] 이러한 결함은 사이버 범죄자와 네트워크 운영자가 마케팅 목적으로, 캡티브 포털 및 검열의 사용자 인증에 흔히 사용된다.^[50]

DNS 관련 개인 정보 문제를 해결하기 위해 사용되는 주요 접근 방식은 다음과 같다.

• DNS 확인을 VPN 운영자에게 이전하고 로컬 ISP로부터 사용자 트래픽을 숨기는 VPN
• 익명 .onion 도메인으로 기존 DNS 확인을 대체하여 양파 라우팅 감시를 통해 이름 확인과 사용자 트래픽을 모두 숨기는 Tor
• 실제 DNS 확인을 제3자 제공업체로 이전하는 프록시 및 공개 DNS 서버. 이들은 일반적으로 요청 로깅을 거의 또는 전혀 수행하지 않으며 DNS 수준 광고 또는 음란물 차단과 같은 선택적 추가 기능을 제공한다.
• *공개 DNS 서버는 기존 DNS 프로토콜을 사용하여 쿼리할 수 있으며, 이 경우 로컬 감시로부터 보호 기능을 제공하지 않거나, 이러한 보호 기능을 제공하는 DNS over HTTPS, DNS over TLS 및 DNSCrypt를 사용할 수 있다.

8. 도메인 이름 등록

도메인 이름을 사용할 권한은 인터넷 주소 자원 관리 기구(ICANN) 또는 인터넷의 이름 및 번호 시스템을 감독하는 OpenNIC과 같은 다른 기관의 인증을 받은 도메인 이름 등록 기관에 의해 위임된다. ICANN 외에도 각 최상위 도메인(TLD)은 레지스트리를 운영하는 관리 조직에 의해 기술적으로 유지 관리되고 서비스된다. ''레지스트리''는 권한 있는 영역 내의 이름 데이터베이스를 운영할 책임이 있지만, 이 용어는 TLD에 가장 자주 사용된다. ''등록자''는 도메인 등록을 요청한 개인 또는 조직이다.^[17] 레지스트리는 각 도메인 이름 ''등록 기관''으로부터 등록 정보를 받으며, 등록 기관은 해당 영역의 이름을 할당할 권한(인증)을 받으며 WHOIS 프로토콜을 사용하여 정보를 게시한다. 2015년 현재 RDAP 사용이 고려되고 있다.^[51]

ICANN은 TLD, TLD 레지스트리 및 도메인 이름 등록 기관의 전체 목록을 게시한다. 도메인 이름과 관련된 등록자 정보는 WHOIS 서비스를 사용하여 접근할 수 있는 온라인 데이터베이스에 유지 관리된다. 290개 이상의 국가 코드 최상위 도메인(ccTLD)의 경우 대부분 도메인 레지스트리가 WHOIS(등록자, 네임 서버, 만료 날짜 등) 정보를 유지 관리한다. 예를 들어, DENIC, 독일 NIC는 DE 도메인 데이터를 보유한다. 2001년경부터 대부분의 일반 최상위 도메인(gTLD) 레지스트리는 이른바 ''두꺼운'' 레지스트리 방식을 채택했다. 즉, WHOIS 데이터를 등록 기관 데이터베이스가 아닌 중앙 레지스트리에 보관한다.

COM 및 NET의 최상위 도메인의 경우 ''얇은'' 레지스트리 모델이 사용된다. 도메인 레지스트리(예: GoDaddy, BigRock 및 PDR, VeriSign 등)는 기본 WHOIS 데이터(즉, 등록 기관 및 네임 서버 등)를 보유한다. 반면에 ORG를 사용하는 조직 또는 등록자는 공익 레지스트리에 독점적으로 있다.

일부 도메인 이름 레지스트리는 종종 ''네트워크 정보 센터''(NIC)라고 불리며 WHOIS 데이터 세트에 대한 접근을 제공하는 것 외에도 최종 사용자에게 등록 기관 역할을 한다. COM, NET 및 ORG 도메인과 같은 최상위 도메인 레지스트리는 많은 도메인 이름 등록 기관으로 구성된 레지스트리-등록 기관 모델을 사용한다.^[52] 이 관리 방식에서 레지스트리는 도메인 이름 데이터베이스와 등록 기관과의 관계만 관리한다. ''등록자''(도메인 이름 사용자)는 등록 기관의 고객이며, 경우에 따라 재판매인의 추가 하청을 통해 이루어진다.

9. 관련 표준

IETF(Internet Engineering Task Force)에서 RFC(Request for Comments) 문서 형태로 DNS 관련 표준을 발표한다.

다음은 주요 DNS 관련 RFC 문서들이다.

10. 관련 용어

• , ''DNS 용어''^[17]
• DNS 서버
• 동적 도메인 네임 시스템(Dynamic Domain Name System, DDNS)
• 리졸버
• djbdns - DNS 서버용 소프트웨어.
• BIND
• unbound - 오픈 소스 DNS 캐시 서버
• DNS 루트 존
• DNS 존 전송
• DNS 레코드 유형 목록
• MX 레코드
• SRV record|SRV 레코드^영어
• 글루 레코드
• DNSBL(DNS 블랙리스트)
• DNS 라운드 로빈
• Extension mechanisms for DNS|EDNS0^영어(DNS 확장 메커니즘 버전 0)
• 도메인 이름
• 최상위 도메인(TLD)
• 국제화 도메인 네임
• 정규화 도메인 이름(Fully Qualified Domain Name)
• 지역 인터넷 레지스트리
• 레지스트라
• TCP/IP
• 이름 확인
• 정방향 조회
• 역방향 조회
• 디렉터리 서비스
• DNS 스푸핑
• 생일 공격
• DNS-피닝(DNS 리바인딩DNS rebinding^영어)
• DNS 보안 확장(DNSSEC)
• 애니캐스트

참조

_[1] 논문 Information fusion-based method for distributed domain name system cache poisoning attack detection and identification https://onlinelibrar[...] 2016
_[2] RFC Internet Protocol - DARPA Internet Program Protocol Specification The Internet Society 1981-09
_[3] 웹사이트 Globally Distributed Content Delivery https://people.cs.um[...] 2002-09-10
_[4] 논문 The Akamai Network: A Platform for High-Performance Internet Applications http://www.akamai.co[...] 2012-11-19
_[5] 웹사이트 DNS Abuse Handling https://conference.a[...] APNIC 2016-12-18
_[6] 서적 DNS and BIND O'Reilly Media
_[7] 문서 IEEE Annals 2011-07-29
_[8] 웹사이트 Why Does the Net Still Work on Christmas? Paul Mockapetris - Internet Hall of Fame 2012-07-23
_[9] 웹사이트 Elizabeth Feinler 2018-11-25
_[10] 웹사이트 Paul Mockapetris Internet Hall of Fame 2020-02-12
_[11] 웹사이트 Happy 30th Birthday, DNS! Internet Society 2015-12-18
_[12] 문서 IEEE Annals 2011-07-29
_[13] 컨퍼런스 The Berkeley Internet Name Domain Server 1984-06-12
_[14] 웹사이트 The History of BIND https://www.isc.org/[...] 2022-04-04
_[15] RFC Domain Names - Domain Concepts and Facilities IETF 1987-11
_[16] RFC Domain Names - Implementation and Specification IETF 1987-11
_[17] RFC DNS Terminology IETF 2015-12-18
_[18] RFC Domain Names - Domain Concepts and Facilities IETF 2015-12-17
_[19] RFC Domain Names - Domain Concepts and Facilities IETF 2015-12-17
_[20] 서적 International Domain Name Law: ICANN and the UDRP Bloomsbury Publishing
_[21] 논문 DNS Terminology https://www.rfc-edit[...] 2024-07-01
_[22] 서적 Linux Administration Handbook https://books.google[...] Addison-Wesley Professional 2006-10-30
_[23] 서적 e-Infrastructure and e-Services for Developing Countries: 8th International Conference, AFRICOMM 2016, Ouagadougou, Burkina Faso, December 6-7, 2016, Proceedings https://books.google[...] Springer 2017-10-09
_[24] 웹사이트 DNS zone https://www.ionos.co[...] 2022-01-27
_[25] 웹사이트 What is DNS propagation? https://www.ionos.co[...] 2022-04-22
_[26] 웹사이트 Providers ignoring DNS TTL? http://ask.slashdot.[...] Slashdot 2012-04-07
_[27] 웹사이트 Ben Anderson: Why Web Browser DNS Caching Can Be A Bad Thing http://dyn.com/web-b[...] 2014-10-20
_[28] 웹사이트 How Internet Explorer uses the cache for DNS host entries http://support.micro[...] Microsoft Corporation 2010-07-25
_[29] 웹사이트 Domain Name System (DNS) Parameters https://www.iana.org[...] IANA 2019-06-14
_[30] 서적 Computer Networking: A Top-Down Approach Pearson Educ. Limited
_[31] RFC Domain Name System (DNS) IANA Considerations 2008-11
_[32] RFC Domain Name System (DNS) IANA Considerations 2008-11
_[33] RFC The Role of Wildcards in the Domain Name System 2006-07
_[34] RFC Extension Mechanisms for DNS (EDNS0) 1999-08
_[35] 웹사이트 Privacy of DNS over HTTPS: Requiem for a Dream? https://raw.githubus[...] National University of Singapore 2021-02
_[36] IETF DNS over Dedicated QUIC Connections Internet Engineering Task Force 2022-05-01
_[37] 저널 Oblivious DNS: Practical Privacy for DNS Queries https://petsymposium[...] 2019-01-01
_[38] 웹사이트 Oblivious DNS Deployed by Cloudflare and Apple https://medium.com/n[...] 2022-07-27
_[39] 웹사이트 Oblivious DNS Over HTTPS https://datatracker.[...] IETF 2021-09-02
_[40] 웹사이트 "No Port 53, Who Dis?" A Year of DNS over HTTPS over Tor https://www.ndss-sym[...] Network and Distributed System Security Symposium 2021-02-01
_[41] 웹사이트 DNSCrypt – Critical, fundamental, and about time. https://umbrella.cis[...] 2011-12-06
_[42] 웹사이트 Anonymized DNSCrypt specification https://raw.githubus[...] DNSCrypt
_[43] 웹사이트 Oblivious DoH · DNSCrypt/dnscrypt-proxy Wiki https://github.com/D[...] DNSCrypt project 2022-07-28
_[44] 저널 Retrofitting Security into Network Protocols: The Case of DNSSEC https://ieeexplore.i[...] 2014-01-01
_[45] 웹사이트 Global Phishing Survey: Domain Name Use and Trends in 1H2010 http://www.apwg.org/[...] APWG 2010-10-15
_[46] 웹사이트 DNSMessenger (Malware Family) https://malpedia.caa[...] 2024-12-11
_[47] 웹사이트 New Fileless Malware Uses DNS Queries To Receive PowerShell Commands https://thehackernew[...] The Hacker News 2024-12-11
_[48] 웹사이트 Covert Channels and Poor Decisions: The Tale of DNSMessenger https://blog.talosin[...] 2024-12-11
_[49] Youtube It's DNS again 😢 Did you know this Malware Hack? https://www.youtube.[...] 2024-12-11
_[50] 저널 DNS Privacy and the IETF http://ipj.dreamhost[...] 2019-07-01
_[51] 웹사이트 Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars https://web.archive.[...] ICANN 2015-12-18
_[52] 웹사이트 Find a Registrar http://www.verisign.[...] VeriSign, Inc. 2015-12-18
_[53] 웹사이트 ISI Marks 20th Anniversary of Domain Name System https://www.isi.edu/[...] 2022-11-06
_[54] 웹사이트 インターネット用語1分解説～権威DNSサーバ(authoritative name server)とは～ https://www.nic.ad.j[...] 2022-11-06
_[55] 웹사이트 第7回 DNSの仕組みについて https://lpi.or.jp/lp[...] 2022-11-06
_[56] 웹사이트 重要技術　DNSの仕組み https://www.soumu.go[...] 2022-11-06
_[57] 문서 포트53을 사용하지 않고 포트443을 사용한다.
_[58] RFC Domain Names - Concepts and Facilities The Internet Society 1987-11-01
_[59] RFC Internet Protocol - DARPA Internet Program Protocol Specification The Internet Society 1981-09-01
_[60] RFC Domain Names - Implementation and Specification The Internet Society 1987-11-01
_[61] RFC Role of the Domain Name System (DNS) 2003-02-01
_[62] 서적 DNS and BIND O'Reilly Media
_[63] 문서 IEEE Annals [3B2-9] man2011030074.3d 29/7/011 11:54 Page 74