도메인 네임 시스템

섬네일을 만드는 중 오류 발생:

도메인 네임 시스템(Domain Name System, DNS)은 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하기 위해 개발되었다. 특정 컴퓨터(또는 네트워크로 연결된 임의의 장치)의 주소를 찾기 위해, 사람이 이해하기 쉬운 도메인 이름을 숫자로 된 식별 번호(IP 주소)로 변환해 준다. 도메인 네임 시스템은 흔히 "전화번호부"에 비유된다. 인터넷 도메인 주소 체계로서 TCP/IP의 응용에서, www.example.com과 같은 주 컴퓨터의 도메인 이름을 192.168.1.0과 같은 IP 주소로 변환하고 라우팅 정보를 제공하는 분산형 데이터베이스 시스템이다.

인터넷은 2개의 주요 이름공간을 관리하는데, 하나는 도메인 네임 계층^[1], 다른 하나는 인터넷 프로토콜(IP) 주소 공간이다.^[2] 도메인 네임 시스템은 도메인 네임 계층을 관리하며 해당 네임 계층과 주소 공간 간의 변환 서비스를 제공한다. 인터넷 네임 서버와 통신 프로토콜은 도메인 네임 시스템을 구현한다.^[3] DNS 네임 서버는 도메인을 위한 DNS 레코드를 저장하는 서버이다. DNS 네임 서버는 데이터베이스에 대한 쿼리의 응답 정보와 함께 응답한다.

역사

호스트의 숫자 주소 대신 더 단순한, 더 기억하기 쉬운 이름을 사용하는 일은 ARPANET 시절로 거슬러 올라간다. 스탠퍼드 연구소(현재의 SRI 인터내셔널)는 ARPANET의 컴퓨터들의 숫자 주소와 호스트 이름을 매핑하는 HOSTS.TXT라는 이름의 텍스트 파일을 관리하였다.^[4]^[5] 할당 번호 목록(Assigned Numbers List)이라 불리던 숫자 주소들은 서던캘리포니아 대학교의 정보과학연구소 소속(소속팀은 SRI와 함께 밀접하게 일했음) 존 포스텔에 의해 관리되었다.^[6]

구조

도메인 이름 공간

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

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

도메인 이름 형성

도메인 이름 형성에 관한 규칙은 RFC 1035, RFC 1123, RFC 2181에 정의되어 있다. 도메인 이름은 한 개 이상의 부분(레이블)로 이루어지고, 점으로 구분하여 붙여 쓴다.(예: example.com)

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

주요 DNS 목록

DNS를 잘못 설정할 경우 인터넷 이용에 문제가 생길 수 있다. 신뢰할 수 없는 DNS는 해킹, 파싱 등에 노출되므로, 신뢰할 수 있는 DNS 서버만 이용하는 것이 권장된다.

운영주체	기본 DNS	보조 DNS	기타
KT	168.126.63.1	168.126.63.2	열린 주소창이 작동하던 주소였으나 현재는 열린 주소창이 작동하지 않음.
KT	211.45.150.201	211.45.151.201	열린 주소창이 작동하지 않는 주소였음. 현재는 사용 불가.
LG유플러스	164.124.101.2	203.248.252.2
SK브로드밴드	210.220.163.82	219.250.36.130
CJ헬로비전	180.182.54.1	180.182.54.2
구글	8.8.8.8	8.8.4.4	구글 Public DNS
시만텍	199.85.126.10	199.85.127.10	노턴 ConnectSafe DNS
코모도	8.26.56.26	8.20.247.20	코모도 Secure DNS
Cloudflare	1.1.1.1	1.0.0.1	Cloudflare DNS
IBM Quad9	9.9.9.9	149.112.112.112	IBM Quad9 DNS
SprintLink	206.228.179.10	144.228.254.10, 144.228.255.10	SprintLink DNS
	213.206.128.130	217.147.96.130, 217.149.32.130
	203.222.32.130	203.222.36.130, 203.222.38.130
	204.117.214.10	199.2.252.10

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

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

클라우드플레어(cloudeflare)의 DNS는 한국에 서버를 두어 응답속도가 3~5ms정도의 응답속도를 보인다

같이 보기

각주

↑ RFC 1034, Domain Names - Concepts and Facilities, P. Mockapetris, The Internet Society (November 1987)
↑ RFC 781, Internet Protocol - DARPA Internet Program Protocol Specification, Information Sciences Institute, J. Postel (Ed.), The Internet Society (September 1981)
↑ RFC 1035, Domain Names - Implementation and Specification, P. Mockapetris, The Internet Society (November 1987)
↑ RFC 3467, "Role of the Domain Name System (DNS)", J.C. Klensin, J. Klensin (February 2003).
↑ Liu, Cricket; Albitz, Paul (2006). 《DNS and BIND》 5판. O'Reilly Media. 3쪽. ISBN 978-0-596-10057-5.
↑ IEEE Annals [3B2-9] man2011030074.3d 29/7/011 11:54 Page 74

외부 링크

섬네일을 만드는 중 오류 발생: 위키미디어 공용에 [{{fullurl:Commons:모듈:WikidataIB 508번째 줄에서 Lua 오류: attempt to index field 'wikibase' (a nil value).|uselang=ko}} 도메인 네임 시스템] 관련 미디어 분류가 있습니다.

모듈:Authority_control 159번째 줄에서 Lua 오류: attempt to index field 'wikibase' (a nil value).

[rfc1034-1] RFC 1034, Domain Names - Concepts and Facilities, P. Mockapetris, The Internet Society (November 1987)

[rfc781-2] RFC 781, Internet Protocol - DARPA Internet Program Protocol Specification, Information Sciences Institute, J. Postel (Ed.), The Internet Society (September 1981)

[rfc1035-3] RFC 1035, Domain Names - Implementation and Specification, P. Mockapetris, The Internet Society (November 1987)

[rfc2467-4] RFC 3467, "Role of the Domain Name System (DNS)", J.C. Klensin, J. Klensin (February 2003).

[5] Liu, Cricket; Albitz, Paul (2006). 《DNS and BIND》 5판. O'Reilly Media. 3쪽. ISBN 978-0-596-10057-5.

[6] IEEE Annals [3B2-9] man2011030074.3d 29/7/011 11:54 Page 74

[1]

[2]

[3]

[4]

[5]

[6]