NSLOOKUP

DNS 클라이이언트를 리졸버(resolver)라고 하며 nslookup은 리졸버가 질의하는 것과 같은 방법으로 질의를 진행하여 네임서버의 운영을 테스트하는 용도로 사용된다. nslookup은 리졸버의 행동을 그대로 흉내지만 네임 서버의 행동을 흉내내어 네임 서버가 사용하는 것과 동일한 질의를 이용해 다른 서버에게 질의를 한다. 그리고 네임 서버처럼 영역 정보를 얻어올 수 있다. 결론적으로 nslookup은 리졸버나 네임 서버를 흉내내어 네임 서버의 테스트와 장애 처리 도구로 사용할 수 있다.

그러면 먼저 nslookup과 리졸버가 행동하는 것이 어떻게 다른 가부터 알아보도록 하겠다. 리졸버의 경우 다수의 네임 서버를 등록하여 첫 번째 네임 서버로 질의를 시도하여 다음 서버에게 질의하고 다시 처음 서버에게 질의를 하는 작업을 반복하는 반면 nslookup은 등록된 첫 번째 네임 서버로 질의를 시도해 네임 서버를 포기할 때까지 계속 재시도한다. 그런 다음 다음 서버에게 질의를 시도한다. 일단 응답을 얻으면 해당 네임 서버로 고정시키고 다른 네임 서버로는 질의를 시도하지 않는다.

nslookup은 네임 서버와도 다른 행동을 한다. 예를 들어 nslookup은 슬레이브 서버처럼 영역 전송을 하지만 일련 번호(serial)를 확인하지 않기 때문에 일련 번호의 확인 책임은 테스터에게 있다.

nslookup은 대화식과 비대화식 실행을 지원한다. 먼저 대화식으로 실행해보자.

1. C:\> nslookup
2. > exit

비 대화식 실행은 nslookup 명령과 질의하려는 호스트 이름을 지정한다.

1. C:\> nslookup www.jeongsam.net

옵션

현재 설정된 옵션을 보기 위해서 set all 명령을 입력한다.

[no]debug

디버깅 기능 사용 여부를 지정한다. 디버깅 기능이 켜져 있으면 네임 서버는 시간 초과를 보여주고 응답 패킷을 출력한다.

[no]defname

점이 없는 호스트 이름의 뒤에 로컬 도메인 이름의 자동 추가 여부를 결정한다.

[no]search

search 옵션이 켜져 있을 경우 defname 옵션을 적용하며 search 목록의 DNS 접미사를 자동으로 추가한다.

[no]recurse

재귀적인 도메인 이름 찾기 가능 여부를 결정한다. norecurse로 설정시 다른 네임 서버에 비재귀적 질의를 전송한다.

[no]d2

레벨 2의 디버깅을 켜면 질의 메세지를 정규 디버깅 출력과 함께 보낸다.

[no]vc

nslookup은 기본적으로 TCP를 이용한 가상 회선(virtual circuit) 대신 UDP 패킷을 이용하여 질의를 만든다.

[no]ignoretc

nslookup은 기본적으로 잘려진 메시지를 무시하지 않는다. UDP 응답 데이터그램으로 데이터를 온전히 수신하지 못할 경우 TCP을 이용하여 재시도하여 온전한 메시지를 수신할 수 있도록 시도한다.

port=53

DNS 서비스의 기본 포트 지정.

querytype=A

nslookup의 질의 형식을 지정. 기본값으로 A가 설정되어 있다.

class=IN

현재 현실적으로 지원되는 클래스는 Internet밖에 없다.

timeout=5

네임 서버가 5초이내로 응답하지 않을 경우 질의를 재 전송하고 시간 초과 값을 2배 증가시킨다.

retry=4

응답 실패시 시간 초과값을 2배씩 증가시키면서 4회 재전송후 포기한다.

root=A.ROOT-SERVERS.NET.

디폴트 루트 네임 서버 지정. 재귀적 질의시 루트 도메인 서버로부터 시작하여 하위 도메인을 탐색하여 목표한 도메인 네임 서버를 찾아 질의의 응답을 요청한다.

domain=JEONGSAM.NET

기본 도메인 이름 지정.

srchlist=JEONGSAM.NET

searchlist 지정. 복수의 도메인 지정시 '/'를 이용하여 설정한다.

권한 있는 응답과 권한 없는 응답

로컬 네임 서버로부터 로컬 도메인 영역 정보를 응답받은 경우 권한 있는 응답이라고 하며 다른 도메인 네임 서버로부터 도메인 영역 정보를 응답받은 경우 권한 없는 응답으로 표시된다.

네임 서버 변경

lserver와 server 명령을 이용하여 기본 네임 서버를 변경할 수 있으며, 두 명령의 차이점은 서버의 IP 주소를 찾을 때 nslookup에서 변경된 네임 서버를 이용할 지 아니면 nslookup이 동작 중인 호스트의 기본 네임 서버를 이용할 지의 차이가 있다.

예를 들어 lserver나 server 명령을 이용하여 기본 네임 서버를 www.jeongsam.net으로 변경하였다면, www.jeongsam.net에 네임 서버가 설치되어 있지 않을 경우 server 명령을 이용한 변경 명령은 IP 주소를 찾지 못하는데 반하여 lserver 명령을 이용할 경우 원래의 기본 네임 서버를 이용하여 IP 주소를 찾아준다.

디버깅

1. c:\> nslookup
2. > set debug
3. >

디버깅을 켰을 경우 nslookup이 수신하는 응답을 보여주며 set d2 명령으로 레벨 2 디버깅을 켰을 경우 전송하는 질의도 표시한다.

질의와 응답 메시지인 DNS 패킷을 자세히 살펴보면 헤더 부분, 질의 부분, 응답 부분, 권한 부분, 기타 부분 등 5개 부분으로 구성되어 있다.

헤더 부분(header section)

nslookup에서 opcode는 항상 query로 표시되며 네임 서버의 경우 notify, update 등 opcode를 지원한다. rcode는 no error(에러 없음), server failure(서버 장애), name error(이름이 틀렸음), not implemented(구현되지 않음), refuse(응답 거부) 중 하나의 값을 갖는다.

질의 부분(question section)

DNS 메시지는 요청할 이름과 형식, 클래스로 구성되어 있다.

응답 부분(answer section)

응답 리소스 레코드가 출력된다.

권한 부분(authority section)

네임 서버의 SOA 리소스 레코드가 출력된다.

기타 부분(additional section)

앞서 다룬 4가지 부분에 있는 정보의 추가적인 완전한 정보를 표시한다.

네임 서버 흉내 내기

set norecurse와 set nosearch 명령으로 네임 서버가 도메인 영역 정보를 검색하는 것을 흉내 낼 수 있다.

1. C:\> nslookup
2. > set norec
3. > set nosearch
4. > www.jeongsam.net
5. (현재 기본 네임 서버가 www.jeongsam.net의 도메인 영역 정보를 모르기 때문에 루트 도메인 서버를 찾아 다음 질의할 준비를 한다.)
6. > server a.gtld-server.net
7. > www.jeongsam.net
8. (루트 네임 서버에 질의를 보내 jeongsam.net 영역 정보를 가지고 있는 네임 서버를 찾는다.)
9. > server ns14.dnsever.com
10. > www.jeongsam.net
11. (jeongsam.net 영역 정보를 이용하여 www.jeongsam.net 호스트의 IP 주소르 찾는다.)

영역 전송

슬레이브 서버를 흉내내어 주 마스터 서버(primary master server)로부터 영역 정보를 수신한다.

1. C:\> nslookup
2. > ls -d jeongsam.net
3. (해당 도메인 영역 정보를 가지고 있는 주 마스터 네임 서버가 전송을 허락한 경우 전체 영역 정보를 수신할 수 있다.)

이 글은 스프링노트에서 작성되었습니다.

NSLOOKUP

DNS 클라이이언트를 리졸버(resolver)라고 하며 nslookup은 리졸버가 질의하는 것과 같은 방법으로 질의를 진행하여 네임서버의 운영을 테스트하는 용도로 사용된다. nslookup은 리졸버의 행동을 그대로 흉내지만 네임 서버의 행동을 흉내내어 네임 서버가 사용하는 것과 동일한 질의를 이용해 다른 서버에게 질의를 한다. 그리고 네임 서버처럼 영역 정보를 얻어올 수 있다. 결론적으로 nslookup은 리졸버나 네임 서버를 흉내내어 네임 서버의 테스트와 장애 처리 도구로 사용할 수 있다.

그러면 먼저 nslookup과 리졸버가 행동하는 것이 어떻게 다른 가부터 알아보도록 하겠다. 리졸버의 경우 다수의 네임 서버를 등록하여 첫 번째 네임 서버로 질의를 시도하여 다음 서버에게 질의하고 다시 처음 서버에게 질의를 하는 작업을 반복하는 반면 nslookup은 등록된 첫 번째 네임 서버로 질의를 시도해 네임 서버를 포기할 때까지 계속 재시도한다. 그런 다음 다음 서버에게 질의를 시도한다. 일단 응답을 얻으면 해당 네임 서버로 고정시키고 다른 네임 서버로는 질의를 시도하지 않는다.

nslookup은 네임 서버와도 다른 행동을 한다. 예를 들어 nslookup은 슬레이브 서버처럼 영역 전송을 하지만 일련 번호(serial)를 확인하지 않기 때문에 일련 번호의 확인 책임은 테스터에게 있다.

nslookup은 대화식과 비대화식 실행을 지원한다. 먼저 대화식으로 실행해보자.

1. C:\> nslookup
2. > exit

비 대화식 실행은 nslookup 명령과 질의하려는 호스트 이름을 지정한다.

1. C:\> nslookup www.jeongsam.net

옵션

현재 설정된 옵션을 보기 위해서 set all 명령을 입력한다.

[no]debug

디버깅 기능 사용 여부를 지정한다. 디버깅 기능이 켜져 있으면 네임 서버는 시간 초과를 보여주고 응답 패킷을 출력한다.

[no]defname

점이 없는 호스트 이름의 뒤에 로컬 도메인 이름의 자동 추가 여부를 결정한다.

[no]search

search 옵션이 켜져 있을 경우 defname 옵션을 적용하며 search 목록의 DNS 접미사를 자동으로 추가한다.

[no]recurse

재귀적인 도메인 이름 찾기 가능 여부를 결정한다. norecurse로 설정시 다른 네임 서버에 비재귀적 질의를 전송한다.

[no]d2

레벨 2의 디버깅을 켜면 질의 메세지를 정규 디버깅 출력과 함께 보낸다.

[no]vc

nslookup은 기본적으로 TCP를 이용한 가상 회선(virtual circuit) 대신 UDP 패킷을 이용하여 질의를 만든다.

[no]ignoretc

nslookup은 기본적으로 잘려진 메시지를 무시하지 않는다. UDP 응답 데이터그램으로 데이터를 온전히 수신하지 못할 경우 TCP을 이용하여 재시도하여 온전한 메시지를 수신할 수 있도록 시도한다.

port=53

DNS 서비스의 기본 포트 지정.

querytype=A

nslookup의 질의 형식을 지정. 기본값으로 A가 설정되어 있다.

class=IN

현재 현실적으로 지원되는 클래스는 Internet밖에 없다.

timeout=5

네임 서버가 5초이내로 응답하지 않을 경우 질의를 재 전송하고 시간 초과 값을 2배 증가시킨다.

retry=4

응답 실패시 시간 초과값을 2배씩 증가시키면서 4회 재전송후 포기한다.

root=A.ROOT-SERVERS.NET.

디폴트 루트 네임 서버 지정. 재귀적 질의시 루트 도메인 서버로부터 시작하여 하위 도메인을 탐색하여 목표한 도메인 네임 서버를 찾아 질의의 응답을 요청한다.

domain=JEONGSAM.NET

기본 도메인 이름 지정.

srchlist=JEONGSAM.NET

searchlist 지정. 복수의 도메인 지정시 '/'를 이용하여 설정한다.

권한 있는 응답과 권한 없는 응답

로컬 네임 서버로부터 로컬 도메인 영역 정보를 응답받은 경우 권한 있는 응답이라고 하며 다른 도메인 네임 서버로부터 도메인 영역 정보를 응답받은 경우 권한 없는 응답으로 표시된다.

네임 서버 변경

lserver와 server 명령을 이용하여 기본 네임 서버를 변경할 수 있으며, 두 명령의 차이점은 서버의 IP 주소를 찾을 때 nslookup에서 변경된 네임 서버를 이용할 지 아니면 nslookup이 동작 중인 호스트의 기본 네임 서버를 이용할 지의 차이가 있다.

예를 들어 lserver나 server 명령을 이용하여 기본 네임 서버를 www.jeongsam.net으로 변경하였다면, www.jeongsam.net에 네임 서버가 설치되어 있지 않을 경우 server 명령을 이용한 변경 명령은 IP 주소를 찾지 못하는데 반하여 lserver 명령을 이용할 경우 원래의 기본 네임 서버를 이용하여 IP 주소를 찾아준다.

디버깅

1. c:\> nslookup
2. > set debug
3. >

디버깅을 켰을 경우 nslookup이 수신하는 응답을 보여주며 set d2 명령으로 레벨 2 디버깅을 켰을 경우 전송하는 질의도 표시한다.

질의와 응답 메시지인 DNS 패킷을 자세히 살펴보면 헤더 부분, 질의 부분, 응답 부분, 권한 부분, 기타 부분 등 5개 부분으로 구성되어 있다.

헤더 부분(header section)

nslookup에서 opcode는 항상 query로 표시되며 네임 서버의 경우 notify, update 등 opcode를 지원한다. rcode는 no error(에러 없음), server failure(서버 장애), name error(이름이 틀렸음), not implemented(구현되지 않음), refuse(응답 거부) 중 하나의 값을 갖는다.

질의 부분(question section)

DNS 메시지는 요청할 이름과 형식, 클래스로 구성되어 있다.

응답 부분(answer section)

응답 리소스 레코드가 출력된다.

권한 부분(authority section)

네임 서버의 SOA 리소스 레코드가 출력된다.

기타 부분(additional section)

앞서 다룬 4가지 부분에 있는 정보의 추가적인 완전한 정보를 표시한다.

네임 서버 흉내 내기

set norecurse와 set nosearch 명령으로 네임 서버가 도메인 영역 정보를 검색하는 것을 흉내 낼 수 있다.

1. C:\> nslookup
2. > set norec
3. > set nosearch
4. > www.jeongsam.net
5. (현재 기본 네임 서버가 www.jeongsam.net의 도메인 영역 정보를 모르기 때문에 루트 도메인 서버를 찾아 다음 질의할 준비를 한다.)
6. > server a.gtld-server.net
7. > www.jeongsam.net
8. (루트 네임 서버에 질의를 보내 jeongsam.net 영역 정보를 가지고 있는 네임 서버를 찾는다.)
9. > server ns14.dnsever.com
10. > www.jeongsam.net
11. (jeongsam.net 영역 정보를 이용하여 www.jeongsam.net 호스트의 IP 주소르 찾는다.)

영역 전송

슬레이브 서버를 흉내내어 주 마스터 서버(primary master server)로부터 영역 정보를 수신한다.

1. C:\> nslookup
2. > ls -d jeongsam.net
3. (해당 도메인 영역 정보를 가지고 있는 주 마스터 네임 서버가 전송을 허락한 경우 전체 영역 정보를 수신할 수 있다.)

이 글은 스프링노트에서 작성되었습니다.

DNS 서비스의 동작

네임 서버 구조와 분산 네임 데이터베이스

DNS 서비스는 부하를 집중시키지 않도록 하위 도메인을 관리하는 여러 등록 권한 기관을 두어 분산시킨다. 등록 권한 기관이 분산되어 있는 것과 마찬가지로 도메인에 대한 정보 또한 분산 데이터베이스를 구성하여 네임 변환 수행시 부하를 분산시킨다.

도메인 네임 공간에 대한 정보를 관리하는 DNS 권한 구역은 도메인 구조와 마찬가지로 계층적 구조를 이루며 각 DNS 서버는 자신의 네임 공간에 대한 정보와 하위 도메인 네임 공간에 대한 정보를 저장한다. 관리자는 DNS 마스터 파일을 이용하여 특별한 형태의 자원 레코드(RR; Resource Record)에 데이터를 저장하는 방법으로 네임 공간내의 하위 도메인과 호스트와 같은 객체에 대한 정보를 저장한다.

DNS 서버의 일반적인 기능

• 네임 공간의 정보를 저장하고 DNS 클라이언트의 질의에 응답한다.
• 다른 서버와의 상호작용을 통해 DNS 요청의 유형에 따라 DNS 클라이언트가 되어서 다른 서버로 질의를 요청한다.
• 마스터 서버와 슬레이브 서버 사이에 수행되는 구역 전달을 위한 기능을 수행한다.
• DNS 네임 서버 질의의 성능 향상을 위해 네임 서버 응답을 캐싱하여 DNS 클라이언트의 응답 효율을 높인다.

DNS 네임 서버

자원 레코드의 관리

RR 필드

DNS 클라이언트의 요청에 대해 네임 서버는 DNS 메시지에 RR을 담아 보냄으로 질의에 대한 응답을 한다.

마스터 파일

전송의 효율을 위해 관리자는 아스키 텍스트로 만들어진 DNS 마스터 파일을 편집하여 RR을 등록하거나 수정하며 DNS 서버는 이를 이진 파일로 변환하여 질의/응답에 사용한다.

RR 타입

[표1. RR 타입과 설명]

RR 클래스

DNS가 다양한 프로토콜을 지원할 수 있도록 제공하였으나 현재 TCP/IP 이외의 사용 프로토콜이 없으므로 TCP/IP 프로토콜을 의미하는 'IN'만이 사용된다. 보통 생략하면 IN을 사용하는 것으로 간주한다.

DNS 서버의 종류와 역할

마스터(1차) 서버와 슬레이브(2차) 서버

DNS 구역(zone)마다 1개 이상의 DNS 서버가 존재하여야 하며 DNS 서버는 해당 DNS 구역의 정보를 기술하는 RR 전체를 포함하고 있다. 마스터 서버는 관리자가 해당 도메인 공간(name space)의  정보를 RR 형태로 관리하는 ASCII 텍스트 파일인 DNS 마스터 파일을 가지고 있으며 슬레이브 서버는 이 DNS 마스터 파일을 마스터 서버로부터 복사하여 DNS질의에 대한 응답 자료로 사용한다. 슬레이브 서버는 마스터 서버의 장애에 대비하거나 부하 분산 등의 목적으로 운영되며 보통 1개 이상의 슬레이브 서버를 운영한다.

마스터 서버와 슬레이브 서버는 또한 다른 DNS 영역의 정보를 얻기 위한 DNS 클라이언트의 역할도 수행하여 자신을 DNS 서버로 지정한 다수의 DNS 클라이언트를 대신하여 도메인 이름 찾기 서비스를 대행하기도 한다.

Microsoft에서는 주 영역 서버와 보조 영역 서버로 분류한다. 기본적으로 주 영역 파일은 zone_name.dns라는 이름이 지정되어 서버의 %windir%\System32\Dns 폴더에 저장된다.

캐싱 전용 서버 (Caching only)

다른 DNS 서버로부터 DNS 영역 정보를 읽어오는 역할만을 한다. 네트워크 관리자는 지역 네트워크 사용자들의 DNS 요청을 분산시킬 목적으로 지역 네트워크마다 캐싱 전용 서버를 두어 지역 사용자들이 신속한 DNS 질의에 대한 응답을 얻을 수 있도록 운영할 수 있다. 서버 구성시 루트 힌트만을 구성하면 캐싱 전용 서버로 동작한다.

[그림1. Windows 2003 Server의 DNS 서버 구성 선택 창]

DNS 도메인 책임자

관리 책임자

도메인을 전체적으로 관리하며 보통 도메인 소유자인 개인이나 단체가 관리 책임자가 된다.

요금 책임자

도메인의 요금을 담당하는 책임자를 말하며 소규모 기관에서는 관리 책임자가 요금 책임자를 겸한다.

기술 책임자

도메인의 세부적인 기술 사항을 관리하는 담당자이며 호스팅 업체에 의뢰한 경우 호스팅 업체의 기술 담당이 기술 책임자로 등록 되기도 한다.

영역 전송

슬레이브 서버는 마스터 서버의 SOA 레코드의 필드값을 확인하여 도메인 영역을 갱신할 것인지를 결정한다.

• 일련번호(Serial) : 마스터 서버에 있는 영역 데이터베이스의 버전 번호 역할을 하며 슬레이브 서버가 마스터 서버의 도메인 영역 정보의 갱신 여부를 판단하기 위한 기준 역할을 한다.
• 새로 고침 간격(Refresh) :  슬레이브 서버의 갱신 주기를 지정한다.
• 다시 시도 간격(Retry) : 마스터 서버의 응답 장애시 재시도 주기를 지정한다.
• 만료일(Expire) : 슬레이브 서버가 지속적으로 장애로 인해 마스터 서버의 도메인 영역 정보를 갱신하지 못했을 경우 만료일 경과시 자신의 정보를 무효한 것으로 간주하여 사용하지 않게 된다.

DNS 루트 네임 서버

DNS는 계층 구조로 구성되어 있으며 최상위 도메이의 상위 개념으로 루트 도메인이 존재한다. 도메인의 IP 주소 변환시 루트 노드에서 시작해야 하므로 DNS 루트를 위한 네임 서버 기능을 담당하는 네임 서버 집합이 존재하며 이를 DNS 루트 네임 서버라고 한다.

루트 네임 서버의 장애는 곧 인터넷 전체의 DNS 체계의 멈춤으로 이어지므로 각 지역별로 복수의 루트 네임 서버를 둠으로써 안정적이며 빠른 응답을 기대할 수 있도록 한다. 현재 13개의 루트 서버가 존재하며 각 루트 서버는 클러스터를 구성하여 복수의 하드웨어 서버로 구성되어 있다.

DNS 네임 서버 캐싱

DNS 서버는 자신이 관리하는 도메인 영역의 정보외의 다른 도메인 영역 정보를 DNS 서버간 질의와 응답을 통해 주소 변환이 이뤄지며 이런 결과를 캐시에 저장해 둠으로써 반복적인 DNS 클라이언트들의 질의에 대한 효율성을 높인다. 캐시 데이터의 지속성은 마스터 서버의 SOA 자원 레코드의 TTL 필드의 값에 의해 결정된다.

향상된 DNS 서버의 기능

구역 전달의 자동화: DNS 알림 (DNS Notify)

마스터 네임 서버의 영역 정보가 변경될 때 슬레이브 서버에게 통지함으로써 잦은 갱신으로 인한 불필요한 트래픽과 늦은 갱신으로 인한 영역 정보의 무효화를 방지할 수 있다.

점증적 전달: RFC 1995, Incremental Zone Transfer in DNS

마스터 네임 서버의 일부 자원 레코드의 변경만으로도 전체 영역 정보를 전송받아야 하는 슬레이브 서버의 동작을 개선하여 일부 변경된 자원 레코드만을 선별적으로 전송받아서 불필요한 갱신을 하지 않도록 한다.

DNS 동적 업데이트: 동적 IP 주소의 처리

기존의 DNS는 IP가 고정되어 있음을 가정하므로 큰 규모의 도메인으로 인한 잦은 변경 사항이나 동적 IP 주소를 사용한 변경들을 적용하기 위해서 관리자의 노력만으로는 이러한 변경 사항을 일일이 반영하기에 무리가 있다. 1997년 4월 RFC 2136, "Dynamic Updates in the Domain Name System(DNS UPDATE)"를 통해 DNS 정보를 동적으로 갱신할 수 있도록 갱신 방안을 기술하였고 이를 동적 DNS(DDNS; Dynamic DNS)라고 한다. 갱신 메시지라고 불리는 DNS 메시지를 통해 클라이언트의 변경 사항을 서버에 자동으로 반영된다.

이 글은 스프링노트에서 작성되었습니다.

DNS(Domain Name System) 개요

인터넷에 연결된 모든 컴퓨터는 고유한 IP주소를 갖고 있으며 IP주소를 알아야만 통신을 할 수 있다. 마치 전화를 걸기위해서는 상대편 전화번로를 알아야만 걸 수 있는 것과 마찬가지이다. 이렇게 전화 번호에 해당하는게 IP주소인데 문제는 사람은 숫자를 기억하는데 한계가 있다는 점이다. 그래서 대부분의 사람들은 주소록 기능을 이용하여 전화번호와 이름을 함께 저장하여 이름으로 전화번호를 찾아 전화 통화를 한다. 마찬가지로 숫자로 된 IP 주소 대신 기호체계인 이름으로 인터넷에 연결된 컴퓨터를 찾을 수 있도록 해주는게 도메인 이름이다.

초기에는 개별 컴퓨터에 컴퓨터 이름과 IP 주소의 쌍으로 이뤄진 '호스트 테이블'이라는 텍스트 파일을 저장하여 사용하였으나 인터넷에 연결되는 컴퓨터의 숫자가 늘면서 이러한 방법으로는 통일된 이름의 부여가 어려워졌기 때문에 '도메인 네임 시스템'이라는 이름 찾기 서비스를 개발하였다.

도메인 이름 체계

도메인 이름은 중복되지 않는 이름으로 정해진 규칙에 의해 작성되어야 하며 도메인의 종류에 따라 관리하는 기관이 다르다. 하지만 모든 도메인은 논리적으로 하나의 단일한 트리 구조를 갖고 있으며 가상의 도메인 이름인 '루트 도메인(Root Domain)'으로부터 연결되어 가지를 벌여나가는 모양으로 구성되어 있다.

[그림1. 도메인 트리구조]

루트 도메인으로부터 벋어 나온 첫번째 단계의 도메인을 '최상위 도메인(TLD; Top Level Domain)'이라고 하며 최상위 도메인은 일반 최상위 도메인과 국가 최상위 도메인으로 나누며 '일반 최상위 도메인(gTLD; generic Top Level Domain)'은 각 분류와 목적에 맞춰 3자리로 지정된 도메인 이름으로 미국이나 외국의 영리 기관에서 관리하고 있으며 '국가 최상위 도메인(ccTLD; country code Top Level Domain)'은 각 국가별로 할당된 2자리의 이름을 지정하여 각 국가의 망정보센터(NIC; Network Information Center)에서 관리하고 있다. 이러한 최상위 도메인 이름은 ICANN(Internet Corporation for Assigned Names and Numbers)에 의해 만들어진 정책에 의해 결정된다.

일반 최상위 도메인(gTLD)

초기에는 com, org, net 등 7개의 이름만 사용되었으나 인터넷 이용 기관의 급증으로 com 등 도메인 이름의 소유에 관한 분쟁이 늘어나 이를 해소할 목적으로 biz, info 등의 최상위 도메인을 신설하게 되었다.

일반 최상위 도메인은 ICANN process의 global Internet community에 의해 만들어진 정책으로 'registry operators'에 의해 운영되는 'Unsponsored TLD'와 생성 목적에 맞춰 만들어진 이름을 갖는 'sponsors'에 의해 운영되는 'Sponsored TLD'가 있다.

Unsponsored TLD

.biz, .com, .info, .name, .net, .org, .pro

Sponsored TLD

.aero, .asia, .cat, .coop, .jobs, .mobi, .museum, .tel, .travel

[표1. 일반 최상위 도메인과 관리기관]

국가 최상위 도메인(ccTLD)

국제 도메인 이름(IDN; Internationalised Domain Names)은 ICANN process의 IDN WG(Internationalized Domain Names Working Group)의 정책으로 만들어지며 각 국가별로 할당된 2자리 코드로 지정되어 있다. IANA에서 제공하는 Root Zone Database(http://www.iana.org/domains/root/db/)를 통해 확인할 수 있다.

KR 도메인

1단계 도메인인 kr은 ISO 3166에 의한 인터넷상의 도메인체계에서 대한민국을 나타내는 국가 최상위 도메인이다. 현재 한국인터넷진흥원내의 한국인터넷정보센터(KRNIC)에서 관리하고 있다.

kr도메인은 '한글.kr도메인'과 '영문.kr도메인(퀵돔)'의 2단계.kr도메인과 nic.or.kr과 같은 3단계.kr도메인이 있다.

[표2. 2단계.kr도메인]

[표3. 3단계.kr도메인]

[표4. kr도메인 등록 자격]

[표4. 지역에 연고를 둔 .kr도메인]

※ 지역에 연고를 둔 법인이나 개인에 등록 자격 있음.

이 글은 스프링노트에서 작성되었습니다.