DNS 개관, 역사, 표준

• 초기 DNS의 개발과 계층 도메인으로의 이동
  • 1981년 9월 발표된 RFC 799, "Internet name domains"이 처음으로 이 개념을 도입
    • 실제로 도메인 자체보다는 도메인 간의 이메일 전송 방법을 다룸
    • 평면적인 도메인 구조를 가정하고 있으며 계층 구조는 향후에 개발될 가능성이 있다는 정도로만 언급
  • RFC 881, "Domain names plan and schedule"
    • 새로운 DNS 구현과 관련한 문제와 호스트 테이블 체계로부터의 전환방법을 다룸
  • RFC 882, "Domain names: Concepts and facilities"
    • DNS의 개념과 기능적 요소를 매우 자세히 설명
    • 네임 공간과 자원 레코드뿐 아니라 네임 서버와 변환기의 동작 방법에 대한 논의도 포함
  • RFC 883, "Domain names: Implementation specification"
    • DNS 메시징과 동작의 구체적인 핵심 내용을 다룸

• DNS의 표준화와 초기 표준 정의
  • RFC 1032, "Domain Administrators Guide"
    • 도메인 운영에 필요한 관리 절차와 정책을 설명
  • RFC 1033, "Domain Administrators Operations Guide"
    • DNS의 분산 데이터베이스 각 부분을 관리하는 방법을 포함해 DNS 서버의 동작에 대한 기술적인 세부 사항을 제공
  • RFC 1034, "Domain Names - Concepts and Facilities"
    • RFC 882 대체
    • DNS의 소개와 개념적인 설명을 다룸
  • RFC 1035, "Domain Names - Implementation and Specification"
    • RFC 883의 개정판
    • 자원 레코드에 대한 정의, 메시지 유형, 마스터 파일 형식, 변환기와 네임 서버의 상세한 구현을 포함한 DNS의 동작 원리를 자세히 설명

• DNS의 발전과 중요한 추가 표준들
  • RFC 1183, "New DNS RR Definitions"
    • 실험적인 자원 레코드 타임에 대해 정의
  • RFC 1794, "DNS Support for Load Balancing"
    • DNS 서버의 성능향상을 위한 부하 분산에 대해 다룸
  • RFC 1995, "Incremental Zone Transfer in DNS"
    • 효율성을 위해 일부 구역(zone)만을 2차 네임 서버로 전송하는 새로운 기능을 제안
  • RFC 1996, "A Mechanism for Prompt Notification of Zone Changes(DNS NOTIFY)"
    • 기본(중앙 관리) DNS 서버가 2차 서버에게 메인 데이터베이스의 새로운 변경 사항을 전달해줄 수 있는 DNS 메시지 타입을 추가함
  • RFC 2136, "Dynamic Updates in the Domain Name System(DNS UPDATE)"
    • 동적으로 DNS 데이터베이스의 자원 레코드를 변경하는 기술에 대해 다룸
    • Dynamic DNS라 불리기도 함
  • RFC 2181, "Clarifications to the DNS Specification"
    • RFC 1034와 1035에서 정의한 주요 DNS 표준과 관련한 여러 문제를 다룸
  • RFC 2308, "Negative Caching of DNS Queries(DNS NCACHE)
    • 네거티브 캐싱의 동작에 대해 설명
    • 더 이상 존재하지 않는 네임 정보를 서버가 좀더 효율적으로 유지하게 해주는 기능

• 인터넷 프로토콜 버전 6으로의 DNS 적용

앞에서 우리는 Hostname을 IP Address로 풀이(Name resolution)하는 방법으로 hosts.txt파일을 이용했을 때 생기는 몇가지 문제점을 살펴 보았다. 이름중복이라는 문제점을 해결하고, 현재상태의 컴퓨터의 호스트이름들을 반영할 수 있어야 하고, 관리적인 측면에서도 가장 손쉽게 접근할 수 있는 방법이라면 어떤 방법을 이용해야 할까? 이 점이 해결해야 할 중점과제이다. <?XML:NAMESPACE PREFIX = O />

 

한가지 예를 들어본다. 회사에는 수많은 부서가 존재한다. 그렇듯 부서를 나누는 이유는 무엇일까? 물론 여러 가지 이유가 있겠지만 관리적인 측면을 무시할 수 없을 것이다. 모든 사원들을 사장이 혼자 관리하는 것보다는 당연히 부서를 나누고 부서장이 관리를 하다면, 보다 효율적인 관리를 할 수가 있을 것이다. 또 부서가 없는 경우에 한 개인은 "000"라는 형식으로 개개인의 이름을 가지지만, 부서로서 개인을 조직하게 되면 "00부서의 000"로서 불리우게 될 것이다. 한 회사에 "<?XML:NAMESPACE PREFIX = ST1 /><?XML:NAMESPACE PREFIX = ST2 />송원석"이라는 이름을 가진 사람이 둘이 있다고 하자. 부서의 개념이 없을 때는 단순히 "송원석"하고 부르면 누구를 가리키는 것인지 헷갈릴 수밖에 없다. 하지만 그들을 구별해 주는 부서가 있다면 "00부서의 송원석"이라는 식으로 어긋나지 않게 원하는 사람을 구별할 수 있게 된다.

 

앞에서 문제가 되었던 이름중복은 조금만 생각을 바꾸면 해결이 가능한다. 이름을 평면적인(flat) 이름으로 사용하는 것 대신에 부서처럼 다른 이름을 하나쯤 더 붙이면 되지 않을까? 예를 들면 "www"라는 이름 대신에 "A회사의 www"로서 등록을 한다는 것이다. 그렇다면 모든 회사의 웹서버가 "www"라는 이름을 사용하더라도 더 이상 이름의 충돌은 염려하지 않아도 될 것이다.

 

hosts파일크기의 증가로 인한 네트워크 트래픽을 줄이고, 빠른 업데이트를 가능하게 하기 위해서는 관리를 분산시킬 수 있는 구조가 최선이라는 해결책을 찾고 결국 호스트들을 그룹화하는 작업을 하게 되었다. 그 그룹을 바로 "도메인(domain)"이라고 부른다. 여기서의 도메인은 Microsoft가 사용하는 도메인이라는 용어와는 구별을 해야 한다. Microsoft의 도메인은 어디까지나 마이크로소프트의 NT라는 운영체제가 제공하는 보안의 경계영역을 구분하는 회사의 작업그룹인 반면에, DNS에서의 도메인은 전 세계에서 구분할 수 있는 작업그룹이다.

 

DNS의 도메인은 수없이 많은 종류가 있을 수 있다. 대표적으로는 여러분들이 속해 있는 회사를 생각할 수 있고, 국가를 구분할 수도 있고, 특별한 단체를 구분지을 수도 있다. 인터넷에 연결되고 자신들의 집단을 구분할 수 있는 이름을 가지고자 한다면 어느 누구라도 도메인이라는 하나의 작업그룹을 할당받을 수 있다는 이야기다. 추가로 이러한 그룹 역시 또 다른 그룹에 소속되어 있고, 최상위에 모든 그룹은 하나의 그룹으로 묶이게 된다. 회사의 조직구조와 비슷한다. 회사안에는 몇 개의 사업본부가 있고, 사업본부 안에는 몇 개의 부서가 있고, 부서 아래에 팀이 있고, 팀 안에 팀원들이 소속되어 있는 구조와 같다. 실제 구조를 살펴보면 우리가 윈도우 탐색기를 통해서 볼 수 있는 폴더구조와 흡사한다. 최상위에 root(c:)가 있고, 그 밑에 폴더가 있으며 폴더밑에는 또 다른 폴더가 있고, 최종적으로 폴더 밑에는 파일이 들어있다. 이러한 형태의 구조를 우리는 계층구조라고 부른다. DNS는 계층구조로 구성되어 있다.

 

결국 최종적으로 만들어진 DNS의 구조를 살펴보면 아래의 <그림5-8>과 같다. 

 

 

<그림5-8. Domain Name Space의 계층구조>

 

위의 그림에서 볼 수 있는 것처럼 DNS는 뚜렷한 계층구조를 가지고 있다. 최상위에는 모든 도메인의 근본이 되는 루트도메인을 두고, null라벨(공백의 문자, "  ")로서 이름을 할당하였다. 이것을 가리켜서 루트-레벨 도메인이라고 부른다. 루트-레벨 도메인의 아래에는 top-level domain을 두는데, 우리에게 친숙한 이름이 보일 것이다. kr, com, net, org등이 그것이다. 각각의 top-level domain은 특별한 원칙을 가지고 있다. 어느 집단이 사용을 하는 이름인지를 알아볼 수 있게 만든 것이다. 현재 약 250여개 정도의 top level domain이 사용되고 있다.

 

< Top-level 도메인 이름 구조> -      com : 영리목적의 기관 (Commercial organization) -      net : 네트워크 기관 (dacom, hitel 등이 사용하고 있다) -      org : 비영리 기관 -      gov : 정부 기관 -      mil : 군사 기관 -      edu : 교육 기관 -      kr (Korea), jp (Japan), au (Australia) 등 : 국가 이름

 

이들 루트 도메인과 탑 레벨 도메인은 우리가 등록해서 사용할 수 있는 이름이 아니다. InterNIC에서는 이미 전세계의 도메인들의 밑바탕이 될 이름을 등록하였고, 실제로 우리가 사용하게 될 이름은 이들 탑 레벨 아래의 도메인부터라고 할 수 있다. <그림5-8>에서 볼 수 있는 것과 같이 탑 레벨 도메인 아래에는 세컨드 레벨 도메인이 있고, 거기에서 실제로 우리나라 회사의 이름을 반영하는 이름들을 찾아볼 수 있게 된다. 우리가 도메인 등록을 한다고 이야기를 하면 바로 그러한 이름을 이야기하는 것이다. 물론 COM이나 Net과 같은 도메인 아래에 여러분의 회사를 등록하다면 바로 세컨드 레벨에서 등록하는 것이 가능하겠지만, 우리나라를 가리키는 Kr도메인 아래에 회사를 등록하고자 하다면, 우리는 한단계 더 아래로 내려갈 수밖에 없다. Kr아래에 또 다시 영리회사를 가리키는 "co"라는 이름이 second level로서 등록되고, 여러분이 원하는 회사이름은 그 아래에 등록되어야 하기 때문이다. 왜 그래야 할까? 답은 뻔하지 않은가! 미국에서 만들어서 사용하고 그들이 발전시켜 오고 있는 것이기 때문에 우리는 그들이 할당해준 kr이라는 top level domain을 우리나라 입장에서는 root로 삼고, 다시 그 안에서 분리작업을 해야 하기 때문인 것이다. 아쉬운 일이지만 힘을 키우는 도리밖에 어쩔 수가 없는 노릇이다.

 

이러한 계층구조를 가진 분산데이타베이스 구조를 가리켜서 DNS (Domain Name Space혹은 Domain Name System)라고 부른다. 그렇다면 이들 DNS는 실제로 어디에 존재하는 것일까? 질문이 너무 막연해 보인다. 여러분이 즐겨찾는 인터넷이라는 공간을 가리켜 우리는 사이버공간이라고 부른다. 실체는 없는 가상공간이라는 뜻이다. 실제로 존재하는 것은 클라이언트 시스템으로서 사용하는 PC가 있고, 그들이 접속해서 사용하는 서버라는 것이 있다. 전세계에 네트워크에 연결된 이들 모든 컴퓨터들이 어우러져서 인터넷이라고 부르는 하나의 커다란 가상공간이 존재하게 된 것이다. DNS역시 마찬가지이다. 어느 한곳에 DNS라는 이름이 기록되고 관리되고 있는 형태는 아닌 것이다. 실체로 본다면 역시 물리적인 시스템인 서버가 존재하겠지만, 이들 모든 서버들이 만들어 내고 있는 하나의 가상공간인 셈이고, 이러한 가상공간을 제공하는 서비스를 DNS를 관리하는 서버, 바로 DNS Server가 이루어놓고 있는 것이다. 결국 <그림5-8>에서 각각의 그룹을 가리키는 도메인이라는 녀석이 존재하고 있었는데, 그 도메인의 중심에는 바로 DNS Server라고 하는 컴퓨터가 차지하고 있게 된다.

 

DNS를 정리해보면 "각각 회사를 구분해주는 도메인이름을 관리하는 DNS Server들이 모여서 만들어낸 가상 이름 공간"이라고 요약을 해 볼 수 있겠다.

 

다음은 DNS의 표기법에 대해서 알아보겠다. 이름충돌의 문제를 해결하다는 예제를 가지고 생각해 보자. <그림5-8>에서 second level domain중에 "feelanet"라는 이름이 있고, 그 회사가 가지고 있는 서버중에 "www"라는 웹서버가 있다. 또한 secure라는 조직도 역시 "www"라는 웹서버를 가지고 있다. 이들은 어떻게 똑같은 이름을 가질 수가 있게 되는가? 바로 DNS에서 바라보는 서버의 이름체계가 이 문제점을 해결해 주고 있다. 이제 더 이상 인터넷에 연결된 서버들은 서로를 구분하는데 있어서 평면적인 www라는 형태의 단순한 이름체계로 사용되지는 않는다. 인터넷상에서 서버들의 이름은 다음과 같은 표기법을 사용하기 때문이다.

 

Fully Qualified Domain Name (FQDN)   DNS에서의 서버의 이름 = Host name + Domain Name 예> www+feelanet+com+(공백) 표기법) www.feelanet.com.   www.secure.pe.kr

 

 

결과적으로 feelanet의 웹서버인 www서버는 www.feelanet.com과 같이 표기되고, Secure의 웹서버는 www.secure.pe.kr과 같이 표기되고 구별되기 때문에 전혀 다른 이름을 가지게 된다. 예전에 사용했던 평면적인 이름체계에서 벗어나 계층구조의 이름을 가짐으로써 이름충돌에 대한 문제점을 해결하게 된 것이다.

한가지 고려사항은 여전히 남아있다. 같은 계층에 2개의 같은 도메인이 있을 수가 있을까? 라는 것이다. 정답은 NO. 예를 들면 com이라고 하는 도메인에 feelanet이라는 도메인이 등록되어 있다. 또 다른 회사에서 역시 그들도 feelanet이라는 이름을 사용하고자 하다면 당연히 허용해 주어선 안될 일이다. 이러한 문제 때문에 새로운 신기술이 나오면 서로 먼저 그 이름을 이용한 도메인을 등록하기 위해서 도메인전쟁이라고까지 표현되는 등록싸움이 발생하고 있는 것이다. 그렇다면 왜 도메인 등록을 하여야 할까? 그냥 우리가 사용하고 싶은 이름을 마음대로 쓰면 되는 것 아닌가? 라고 생각하다면 다음에 설명할 DNS의 이름풀이 과정을 이해하고 생각을 바꿀 수가 있을 것이다. 지금부터는 DNS Server가 어떤 과정을 통해서 이름풀이 과정을 진행하는 지에 대해서 설명하도록 하겠다.

 

<그림5-11>의 예제에서 DNS 클라이언트로 표기된 PC에 앉은 사용자는 하나로 통신 가입자이다. 이 사용자는www.feelanet.com이라는 이름을 가진 feelanet회사의 웹서버에 접근해서 웹서비스를 받고자 한다. 사용자가 www.feelanet.com의 IP Address를 알고 웹 브라우저를 통해서 이름이 아닌 IP주소로 접근을 했다면 간단하겠지만, 사용자가 그런 주소를 알 필요는 없다. 이 사용자의 PC는 하나로 통신DNS서버를 사용하는 DNS클라이언트로 셋팅이 되어 있다. DNS 클라이언트에 대한 부분은 앞장에서 확인한 바 있다.

 

< 그림5-11. DNS Name Resolution Process>

 

사용자는 웹 브라우저의 주소창에 http://www.feelanet.com 이라고 입력하고 <Enter>키를 누를 것이다. 이 요청은 http라는 프로토콜을 가지고 www.feelanet.com이라는 이름의 서버에 요청을 보내겠다는 뜻이다. 결국 웹서비스를 요청하는 메시지이다. 이 요청을 처리해 주기 위해서 사용자의 시스템은 먼저 www.feelanet.com의 IP Address를 알아야 한다. 하지만, 스스로 알 수 있는 방법이 없다. 그런데 DNS 클라이언트로 셋팅이 되어 있기 때문에 DNS Server로 셋팅된 서버에게 질문을 던질 수가 있다.

 

사용자의 시스템은 자신의 TCP/IP등록정보에 DNS Server로 셋팅된 IP Address의 서버에게 www.feelanet.com의 IP Address를 요청한다.(그림5-11-①) 이 요청을 가리켜서 resursive query(재귀적질의)라고 한다. resursive query라고 함은, 이 요청을 받은 서버가 '모 아니면 도' 둘중의 하나의 응답을 해야만 하는 Query를 말한다. IP Address를 가르쳐주거나, 에러메시지를 반납하거나의 선택을 뜻한다.

 

①의 요청을 받은 DNS Server는 응답을 해야 하는데, 자신 역시 자신이 관리하는 이름을 알 뿐이지 어디 있는지도 모르는 feelanet이라는 회사의 웹서버의 IP Address를 알 수가 없다. 그래서 먼저 DNS Server는 Cache라고 부르는 데이터베이스에서 클라이언트가 요청하는 정보가 있는지를 확인해 본 다음, 없다면 다른 DNS에게 질문을 던져서 클라이언트의 요청을 해결하려는 시도를 한다. Windows Server에서 DNS Service를 추가하고, DNS Server로 동작하게 되면 그 서버에는 한가지 정보가 기본적으로 추가된다. 바로 루트 도메인을 관리하고 있는 DNS Server들의 목록이다. 서버는 그 정보를 이용해서 루트 도메인의 DNS Server에게 클라이언트가 요청한 www.feelanet.com에 대한 이름풀이 요청을 보내게 된다. (그림5-11-②) 이 때의 Query를 가리켜서 Iterative Query (반복적 질의)라고 부른다. Recursive Query와는 조금 성격이 틀린 것을 알 수 있을 것이다.

 

루트네임서버는 요청을 받았으니 응답을 해야 할텐데, 자신 역시 모든 정보를 알고 있는 것은 아니다. 자신이 알고 있는 것은 "com"도메인을 관리하는 네임서버의 정보를 알고 있을 뿐이다. 그래서 하나로통신의 DNS Server가 원하는 것에 대한 100% 정답은 아닌, "com"도메인을 관리하는 네임서버의 정보를 제공해 주게 된다. (그림5-11-③)

 

하나로통신의 DNS Server는 한번의 query를 통해서 com도메인을 관리하는 네임서버의 정보를 알 게 되었다. 아직 완전한 정보는 얻지 못했기 때문에 계속해서 책임을 완수하고자 한다. 계속해서 "com"도메인의 네임서버에게 www.feelanet.com. 의 IP정보를 요청한다. (그림5-11-④)

 

하지만 'com'도메인의 네임서버 역시 하나로통신의DNS Server 가 요청한 호스트이름에 대한 IP정보를 알지는 못한다. 그렇지만 feelanet을 관리하고 있는 네임서버의 정보는 알고 있다. 자신이 관리하고 있는 하위도메인이기 때문이다. 그래서 요청에 대한 응답으로feelanet.com.의 정보를 알려 주게 된다. (그림5-11-⑤)

 

Feelanet.com.도메인의 네임서버정보를 얻은 하나로통신의 DNS Server는 feelanet.com의 네임서버에게 www.feelanet.com이라는 자신의 클라이언트가 요청했던 호스트에 대한 IP정보를 요청한다. (그림5-11-⑥)

 

이 요청을 받은 feelanet.com.의 네임서버는 요청한 FQDN이 자신이 관리하고 있는 도메인에 소속된 호스트이기 때문에 IP Address정보를 응답해 줄 수가 있다.(그림5-11-⑦)

 

몇 번의 query를 통해서 DNS 클라이언트가 요청한 정보를 알게 된 하나로통신의 DNS Server는 www.feelanet.com의 IP Address를 제공해 줄 수가 있게 되었다.(그림5-11-⑧)

 

그렇다면 이제 사용자는 DNS Server를 통해서 원하는 웹서버에 대한 IP Address를 알 게 되었기 때문에 TCP/IP통신을 할 수가 있게 되었다. http프로토콜로써 웹서버에게 서비스를 요청하고, 웹서버는 홈페이지를 서비스해 주게 되는 것이다.

 

글로써 기록하니 상당히 복잡해 보인다. 하지만 실제로 사용자 입장에서 본다면, 사용자는 웹 브라우저의 주소창에 친숙한 이름표기법에 따르는 이름을 입력했을 뿐이고, 내부사정은 잘 모르겠지만 어찌됐건 원하는 웹사이트의 홈페이지를 볼 수 있게 되었다. 이러한 작업을 가능하게 하기 위해서 DNS Server는 부지런히 발로(?) 뛰며 서비스를해 주고 있었던 것이다. DNS가 없었다면 이런 일이 가능했을까? 실로 DNS의 위력은 엄청나게 보이다. 필자는 감히 인터넷을 이끌어가고 있는 것은 바로 DNS라고 말하고 싶다. 그만큼 인터넷에 있어서 DNS의 기능은 필수적이기 때문이다. 하는 일은 크지 않지만 어떤 것보다도 중요한 역할을 담당하고 있다. 만일 DNS가 없다면 지금 우리가 사용하는 인터넷이라는 환경이 상당히 많이 다를 거라고 생각한다. TV에서 하고 있는 광고중의 상당수는 도메인이름을 알리는 광고를 하고 있다. DNS가 없다면 업체에서는 도메인이름을 알리는 광고가 아니라 IP Address를 알리는 광고를 해야만 할 것이다.

 

그렇다면 앞서서 가졌던 한가지 의문중에 "왜 반드시 원하는 도메인이름을 등록해야만 사용할 수 있을까"라는 것을 생각해 보자. <그림5-11>의 예제에서 웹서버 입장을 생각해 고려해 보겠다. Feelanet이라는 회사는 자신의 웹서버를 통해서 회사를 홍보하고, 몇가지 서비스를 판매하는 일을 하고 있다고 가정한다. 사용자가 자신의 웹서버의 IP Address를 알고 찾아오게 하는 일은 가장 중요한 일이라고도 할 수 있다. 그런데 앞에서 보았듯이 사용자가 자신의 웹서버의 IP주소를 알기 위해서는 어떤 과정이 있었는가? Feelanet의 DNS Server까지 요청이 와야 하는데, 그것보다 선행되었던 작업이 com도메인의 DNS Server를 찾는 과정이었다. 만일 com도메인의 DNS서버에 Feelanet의 도메인 정보가 등록되어 있지 않았다면 당연히 com도메인의 DNS Server는 하나로통신의 DNS서버의 요청에 대해 “그런 도메인의 정보는 없습니다”라는 에러메시지를 전송해야만 했을 것이다. 이 경우 당연히 하나로통신의 DNS Server는 이름풀이를 처리하지 못했기 때문에 사용자에게 에러메시지를 반송할 수밖에 없다.

 

그래서 ‘도메인등록’이라는 용어를 풀어본다면, "회사에서 사용하기를 희망하는 도메인 이름을 관리하는 DNS Server의 정보를 상위 도메인을 관리하는 DNS Server에 등록하는 작업"이라고 보여진다.

 

처음 볼 때는 상당히 번거로운 작업이라는 생각이 들 수도 있다. 하지만, 이러한 DNS의 진행과정은 2장에서 보았던 hosts.txt파일을 이용한 이름풀이의 과정이 가졌던 모든 문제점을 해결할 수 있는 방법이 되고 있다. 문제점과 비교해서 DNS의 이름풀이과정을 연관시켜서 정리해 보길 바란다.

출처 - http://www.secure.pe.kr/31 

http://wooguy-tcpip.blogspot.kr/2014/08/dns.html