DNS
DNS(디앤에스)는 "Domain Name System"의 약자로서, 도메인 이름과 아이피(IP) 주소를 연결해 주는 시스템을 말한다. 도메인 네임 시스템 또는 네임서버(Name Server)라고도 한다. 포트 번호는 53번이다.
 .jpg) |
목차
개요[편집]
DNS는 할당된 도메인 영역에 대한 정보를 가지고 있는 서버로, 주로 도메인을 IP 주소로 변환하는 역할을 하는 분산 데이터베이스 시스템이다. DNS는 도메인 네임 시스템(Domain Name System)의 약자로 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하기 위해 개발되었다. 특정 컴퓨터나 네트워크로 연결된 임의의 장치 주소를 찾기 위해 사람이 이해하기 쉬운 도메인 이름을 숫자로 된 식별 번호인 IP 주소로 변환해준다. 즉, 인터넷 도메인 주소 체계로서 TCP/IP의 응용에서, "wiki.hash.kr"과 같은 주 컴퓨터의 도메인 이름을 "192.168.1.0"과 같은 IP 주소로 변환하고 라우팅 정보를 제공하는 분산형 데이터베이스 시스템이다.
인터넷은 두 개의 주요 이름 공간을 관리하는데, 하나는 도메인 네임 계층, 다른 하나는 인터넷 프로토콜 주소 공간이다. 도메인 네임 시스템은 도메인 네임 계층을 관리하며 해당 네임 계층과 주소 공간 간의 변환 서비스를 제공한다. 인터넷 네임 서버와 통신 프로토콜은 DNS 시스템을 구현한다. DNS 네임 서버는 도메인을 위한 DNS 레코드를 저장하는 서버이며, 데이터베이스에 대한 쿼리의 응답 정보와 함께 응답한다.[1]
등장배경[편집]
DNS의 기원은 1960년대부터 올라온다. 1960년대 말 미국의 아르파넷(ARPANET)이 등장한다. 아르파넷은 미국의 주요 연구기관을 연결한 광역 컴퓨터망으로써 미국 국방부의 ARPA(Advanced Research Project Agency)가 투자하여 개발하였다. 1980년대 초 TCP/IP 프로토콜이 개발되었다. IP는 인터넷 프로토콜(Internet Protocol)의 약자로서 산재한 컴퓨터 네트워크 간에 상호 연동을 하기 위한 프로토콜이다. TCP/IP 프로토콜은 빠른 속도로 아르파넷에서 컴퓨터 네트워킹의 표준 프로토콜이 되었는데, 이 당시만 해도 DNS는 존재하지 않았다. UC버클리 대학의 BSD Unix에 TCP/IP 프로토콜이 탑재되는 동시에 아르파넷에 연결된 호스트 수가 급격하게 증가했다. 1974년 기준 아르파넷은 총 23개의 호스트만이 존재하고 있었는데, 1981년에는 213개, 1983년에는 562개, 1984년에는 1,024개, 1985년은 1,961개, 1987년에는 28,174개로 기하급수적인 증가세를 보였다.
이렇듯 TCP/IP를 기반으로 형성된 지역 및 광역 네트워크를 인터넷(Internet)이라 부르게 되었는데, TCP/IP 표준 프로토콜의 등장과 BSD Unix의 TCP/IP 지원으로 갑작스럽게 증가한 호스트로 인해 문제가 생겼다. 그것은 기하급수적으로 증가해버린 호스트 이름의 구성 및 관리이다. 초기 아르파넷 환경에서는 각 호스트의 주소를 모두 외울 수 있었고, 호스트 수가 증가함에 따라 니모닉(Nemonic)을 호스트별로 부여해 쉽게 기억할 수 있게 하였지만. 호스트의 이름이 변경되거나 호스트의 수가 증가함에 따라 이런 방법의 변경 및 분배는 한계에 달하게 되었다. 더불어 인터넷의 규모가 날로 커지면서 호스트 이름과 IP주소 레코드를 자동으로 관리하는 체계가 필요하게 되어 DNS가 등장했다.
- DNS 설계 목표와 목적
구조[편집]
DNS는 도메인 이름과 IP주소의 매핑을 위한 관리 체계로 크게 도메인 네임 스페이스, 네임서버, 리졸버로 구성된다.
도메인 네임 스페이스[편집]
도메인 네임 스페이스(Domain Name Space)는 거대한 분산 네이밍 시스템인 DNS가 저장 및 관리하는 계층적 구조를 말한다. 도메인 이름 공간은 도메인 이름이 트리 형태로 구성되어 있다. 트리의 각 노드는 리소스 레코드를 가지며 0개 이상의 레코드를 가질 수 있다. 트리는 최상위에 루트존에서 시작하여서 인터넷에 연결된 모든 노드가 연속해서 이어진 하위 존으로 나누어져 있다. 각 DSN 존은 하나의 권한 있는 서버에 의해 관리되는 노드들의 집합이다. 각 존과 도메인은 그 하위 도메인에 관한 정보를 관리한다. 하나의 네임 서버가 여러 개의 존을 관리할 수도 있다. 관리 권한은 분할되어 새로운 존을 형성할 수 있으며, 기존의 도메인 이름 공간의 일부분이 서브 도메인 형태로 다른 네임 서버에 권한이 위엄된다. 그리고 기존의 존은 새로운 존에 대한 권한을 잃게 된다.
도메인 네임 서버[편집]
숫자로 구성된 IP 주소와 함께 사용하기 편리하고 기억하기 쉬운 이유로 도메인 이름을 사용한다. 그러나 실제 웹 클라이언트와 웹 서버 간의 통신은 숫자로 표현된 IP 주소를 사용하여 통신한다. 이를 위해서 문자열로 표현된 도메인 이름을 컴퓨터가 통신할 때 사용하는 숫자로 변환시켜 주어야 한다. 이러한 동작을 위해 도메인 네임 스페이스의 트리 구조에 대한 정보가 필요하며, 이러한 정보를 가지고 있는 서버를 도메인 네임 서버라고 한다.
- 도메인 이름 형성에 관한 규칙으로 도메인 이름은 한 개 이상의 부분(레이블)으로 이루어지고, 점으로 구분하여 붙여 쓴다.
- 가장 오른쪽 레이블은 최상위 도메인을 의미한다. 예를 들어, 도메인 이름 www.example.com은 최상위 도메인 com에 속한다.
- 도메인의 계층 구조는 오른쪽부터 왼쪽으로 내려간다. 왼쪽의 레이블은 오른쪽의 서브도메인이다. 예를 들어, 레이블 example은 com 도메인의 서브도메인이며, www는 example.com의 서브도메인이다. 서브도메인은 127단계까지 가능하다.
- 각 레이블은 최대 63개 문자를 사용할 수 있고, 전체 도메인 이름은 253개 문자를 초과할 수 없다. 실제로는 도메인 레지스트리에 더 짧은 제한을 가질 수 있다.
- 도메인 이름은 기술적으로 옥텟으로 표현할 수 있는 모든 문자를 사용할 수 있다. 그러나 DNS 루트 존과 대부분의 서브도메인에서는 제한된 형식과 문자들만 허용한다. 레이블에 사용될 수 있는 문자는 아스키 문자 집합의 부분집합과 알파벳 a부터 z, A부터 Z, 숫자 0부터 9와 하이픈(-)을 포함한다. 이 규칙은 문자(letter), 숫자(digit), 하이픈(hyphen)의 첫 글자를 따서 LDH 규칙이라고 한다. 도메인 이름은 대소문자 구분 없이 해석되고, 레이블은 하이픈으로 시작하거나 끝날 수 없다.[1]
리졸버[편집]
리졸버(resolver)는 웹 브라우저와 같은 DNS 클라이언트의 요청을 네임 서버로 전달하고, 네임 서버로부터 도메인 이름과 IP 주소를 받아 클라이언트에게 제공하는 기능을 수행한다. 이 과정에서 리졸버는 하나의 네임 서버에게 DNS 요청을 전달하고, 해당 서버에 정보가 없으면 다른 네임 서버에게 요청을 보내 정보를 받아 온다. 이렇듯 리졸버는 수많은 네임 서버에 접근하여 사용자에게 요청 받은 도메인의 IP 정보를 조회하는 기능을 수행 할 수 있어야 한다.
하지만 이러한 리졸버의 모든 기능을 PC와 같은 클라이언트 호스트에 구현하는 것은 단말 시스템 자원의 한계와 같은 제약이 있다. 이에 따라 리졸버의 대부분의 기능을 DNS 서버에 구현하고, 클라이언트 호스트는 리졸버의 단순한 기능만을 지닌 리졸버 루틴을 구현하는 옵션이 제시되었다. 이러한 단순화된 기능의 리졸버를 스터브 리졸브라고 하며, 스터브 리졸버는 수많은 네임 서버의 구조를 파악할 필요 없이 리졸버가 구현된 네임 서버의 IP 주소만 파악하면 된다. 클라이언트 호스트에 설정하는 DNS 서버는 이와 같은 네임 서버를 의미하는 것으로, 도메인에 대한 질의를 받은 스터브 리졸버는 설정된 네임 서버로 DNS 질의를 전달하고 네임 서버로부터 최종 결과를 응답받아 웹 브라우저로 전달하는 인터페이스 기능만을 수행한다.
도메인 구성[편집]
국가 도메인[편집]
- kr, us : 각 국가별 사용을 위해 정의한 도메인으로 ISO3166에서 정의하는 국가 코드에 기반함
일반 도메인[편집]
- com : 기업과 같은 상용 조직을 위한 도메인
- edu : 교육 기관들을 위한 도메인
- net : 네트워크 서비스 제공자와 관련된 시스템을 위한 도메인
- org : 다른 TLD에 속하지 않는 비정부 단체를 위한 도메인
- int : 국제 협약에 의해 만들어진 조직을 위한 도메인
- gov : 본래 정부 기관이나 단체를 위한 도메인이었으나, 현재 미국의 주 정부를 비롯한 연방 정부만 등록하도록 결정된 도메인
- mil : 미국 국방성 관련 기관에서 사용하도록 정의한 도메인
특수 도메인[편집]
- arpa : IP 주소를 도메인 이름으로 매핑하기 위해 사용되는 특수 도메인
서버 종류[편집]
- 주 DNS 서버(Primary DNS servers)
- 가장 기본이 되는 DNS 서버로 도메인에 대한 기본적인 데이터베이스를 저장하고 있으며 네트워크 상의 클라이언트들의 쿼리(Query)에 대한 응답을 목적으로 한다. 자신의 데이터상에 질의에 대한 응답이 없다면 상위 도메인 서버에 다시금 질의하거나 클라이언트를 연결해 주는 재귀와 반복의 과정을 통하여 도메인 존에 대한 이름을 풀이 과정을 실행하게 된다.
- 보조 DNS 서버(Secondary DNS servers)
- 보조 DNS 서버는 주 DNS 서버의 백업 서버로 주 DNS 서버의 데이터를 계속적으로 복제하였다가 주 DNS 서버에 장애가 발생할 때 DNS 서버로서 역할을 하게 된다. 또다른 하나의 역할은 분산의 역할을 할 수 도 있는데 네트워크 내의 클라이언트의 수가 많다면 이들 클라이언트들의 주 DNS 설정을 보조 DNS 서버로 연결을 하는 방법으로 DNS 트래픽에 대한 분산을 할 수 있다.
- 캐싱 서버(Caching-only DNS servers)
- 네트워크상의 DNS 서버는 클라이언트로부터 질의된 이름 풀기 요청에 대한 정보를 제공할 때 자신의 정보 데이터베이스로부터 찾아서 보여준다. 이렇게 자신이 보유한 정보, 예를 들어서 www.kr.net 의 IP는 211.52.105.xxx 다 이런식의 정보를 자신이 가지고 있다면 문제가 없지만 이러한 정보가 없을 때는 상위 DNS 서버에게 다시금 질의를 하게 된다. 이렇게 외부 도메인 정보를 질문하게 되었을때 클라이언트들은 당연히 결과값을 더 느리게 받게 될 뿐만 아니라 네트워크 트래픽도 증가된다. 따라서 이렇게 외부 DNS 를 이용해야 하는 경우의 질의에 대해서 DNS 서버는 캐싱작업을 하게 되는데 이것은 마치 인터넷 익스플로러의 케싱 기능과 유사하다. 질의와 값을 모두 저장하게 되므로 네트워크상에서 다시금 같은 질의가 들어오게 되면 케싱상에 저장된 데이터를 바탕으로 그 즉시 결괏값을 전달하게 됨으로써 네트워크상에 트랙픽은 혁신적으로 줄어든다.
- 대부분의 구성에서 캐시 TTL 값은 영역의 권한 시작(SOA) 리소스 레코드에서 사용되도록 설정된 최소 TTL(Time-To-Live)로 지정된다. 기본적으로 최소 TTL은 3,600초, 즉 한 시간이지만 조정이 가능하며 필요하면 캐시에 대한 TTL은 수정이 가능하며, 케싱시간을 적게하고 길게 함에 따라서 각각의 장단점이 있다. 케싱시간을 너무 길게 잡게 되면 수정된 DNS 정보에 대한 올바른 적용이 더디게 되며 너무 작게 잡게 되면 트래픽이 증가된다. 케싱 기능은 DNS 서버에서 기본적으로 사용하는 기능으로 이러한 케싱기능을 전문으로 하는 케싱 서버를 구성할 수 도 있다. 윈도우 2000의 DNS 서버도 이러한 케싱 서버의 역할을 지원한다. 케싱 서버의 사용에서 주의할 점은 케싱 서버의 케싱된 정보는 서버가 재부팅하게 되면 사라진다는 것이다. 따라서 부팅 후에는 처음부터 다시금 캐시 백업을 만들어야만 한다.
- 전달 서버(Forwarding DNS servers)
- 일반적으로 DNS 서버들은 로컬 네트워크상의 클라이언트들이 질의한 요청에 대한 해결은 스스로 처리할 수 없을때 외부 DNS 서버에 다시금 질의를 요청하게 된다. 이렇게 자신이 처리할 수 없는 요청에 대하여 외부에 요청하게 될때 네트워크상에서 이러한 요청만을 전담하는 서버가 바로 전달 서버(Forwarding DNS server)이다. DNS 서버들의 외부로의 요청을 모두 전담하여 전달하기 때문에 마치 프록시(Proxy) 서버와 같은 역할을 한다.
- 엑티브 디렉터리 통합서버(AD integrated servers)
- 액티브 디렉터리 통합서버는 DNS 서버와는 다르게 윈도우 2000 에서 소개하고 있는 DNS 서버이다. 윈도우 2000 서버가 인터넷을 기반으로 하는 최대형 규모의 서버를 표방하면서 들고나온 카드가 바로 AD(Active Directory) 와 TCP/IP 를 기반으로 하는 네트워크킹이다. 인터넷을 기반으로 도메인을 조직하기 때문에 기존의 NT 상에서의 DNS와 윈도우 2000 서버상의 DNS의 그 중요성은 많은 차이를 보인다. 이것은 윈도우 2000 서버에서 네트워크상의 자원을 찾는 방식이 도메인을 기반으로 하기 때문이다. AD와 통합된 DNS 서버를 사용하여 얻는 이점으로는 여러 가지가 있는데 이중 가장 대표적인 이점이 결함 허용과 보안이다.
- 결함허용 : 일반적인 DNS 서버의 구성에서 주 DNS 서버의 데이터가 업데이트되면 보조 DNS 서버는 주 DNS 서버로 부터 변경된 내용을 복제하게 된다.. 이 과정에서 주 DNS 서버의 장애가 발생하게 되면 복제가 실패하게 되며 이로 인해서 DNS 서버를 다시 설치하게까지 되는 문제를 야기한다. 그러나 AD에 통합된 윈도우 2000 서버의 DNS 는 이러한 오류를 방지할 수 있다.
특징[편집]
- 관리의 위임 및 분산관리 시스템 : 기존의 중앙 집중적인 호스트 텍스트 파일의 한계점에 대한 대안으로 상위 도메인이 관리하는 부분과 하위 도메인이 관리하는 부분들은 서로 분산돼 계층적인 구조로 나뉘고 해상 서버가 자신의 관리 영역만을 관리하면 된다.
- 네트워크 확장을 위한 확장성 : DNS는 계층적인 트리구조의 형식을 갖고 있어 상당히 유연한 확장성을 가진다.
- 계층적이며, 직관적인 구성 : 계층적이면서도 직관적이고 알아보기 쉬운 구조로 설계되어 있다.[3]
- 인터넷상 대규모 자원에 대한 명칭 부여와 분산화 : Hierarchical, Distributed, Scalable 한 데이터베이스, 루트 노드로부터 최대 128개 레벨을 갖는 역 계층구조이다
- 복잡한 영문 이름을 쉽고 상징적인 하나 이상의 별칭(Alias)으로 관리 : 친숙한 영문 이름(www.wiki.hash.kr 등)을 컴퓨터가 이해하는 IP 주소로 변환이 가능하다.
동작원리[편집]
- DNS 쿼리(웹 브라우저 --> 로컬DNS) : 사용자의 요청(www.hash.kr)을 받은 웹 브라우저는 www.hash.kr 도메인에 대한 IP 주소를 알아내기 위해 DNS 쿼리 메시지를 로컬 DNS 서버에게 전달한다.
- DNS 쿼리(로컬 DNS --> 루트 DNS) : 웹 브라우저로부터 DNS 쿼리를 받은 로컬 DNS 서버는 자신이 해당 도메인에 대한 IP 정보가 없음을 인지하고, www.hasj.kr IP 주소를 알아내기 위해 로컬 DNS 서버에 미리 설정된 최상위 루트 DNS 서버에게 DNS 쿼리 메시지를 전달한다.
- DNS Response(루트 DNS --> 로컬 DNS) : 로컬 DNS 서버로부터 DNS 쿼리를 받은 루트 DNS 서버는 www.hash.kr의 IP 주소를 가지고 있지는 않지만, 자신이 관리하는 하위 레벨의 네임 서버들 가운데 kr 도메인을 관리하는 네임 서버들의 정보를 담아 보낸다.
- DNS 쿼리(로컬 DNS --> 도메인) : 루트 DNS 서버로부터 kr 도메인을 관리하는 네임 서버들의 정보를 알아낸 로컬 DNS 서버는 이 가운데 하나를 임의로 선택해 해당 네임서버에게 www.hash.kr 도메인에 대한 IP 주소를 알아내기 위해 DNS 쿼리 메시지를 전달한다.
- DNS Response(도메인 --> 로컬 DNS) : 요청 도메인을 관리하는 네임서버 역시 로컬 DNS 서버로부터 DNS 쿼리를 받은 IP주소를 가지고 있지 않지만, 자신이 관리하는 하위 레벨의 네임 서버들 가운데 hash.kr 도메인을 관리하는 네임 서버의 정보를 담아 보낸다.
- DNS 쿼리(로컨 DNS --> 도메인) : kr 도메인을 관리하는 네임 서버로부터 hash.kr 도메인을 관리하는 서버들의 정보를 알아낸 로컬 DNS 서버는 이 가운데 하나의 네임 서버를 임의로 선택해 해당 네임서버가 선택되며, www.hash.kr도메인에 대한 IP주소를 알아내기 위해 DNS 쿼리 메시지를 전달한다.
- DNS Response(도메인 --> 로컬 DNS) : hash.kr 도메인을 관리하는 네임 서버 역시 www.hash.kr IP주소를 가지고 있지 않지만, 로컬 DNS 서버가 요청한 도메인 이름이 www.q.hash.kr 별칭으로 사용되는 CNAME 정보와 자신이 관리하는 하위 레벨의 네임 서버들 가운데 www.q.hash.kr 도메인을 관리하는 네임 서버들의 정보를 DNS Response 메시지에 담아 보낸다.
- DNS 쿼리 (로컬 DNS --> 도메인) : hash.kr 도메인을 관리하는 네임 서버로부터 q.hash.kr 도메인을 관리하는 네임 서버 정보를 알아낸 로컬 DNS 서버는 이 가운데 하나의 네임 서버를 임의로 선택해 해당 네임 서버에게 www.hash.kr 도메인으 별칭인 www.q.hash.kr에 대한 IP 주소를 알아내기 위해 DNS 쿼리 메시지를 전달한다.
- DNS Response(도메인 --> 로컬 DNS) : q.hash.kr 도메인을 관리하는 네임 서버는 자신이 www.q.hash.kr의 IP주소를 가지고 있는 것을 확인하고, 해당 호스트 주소를 DNS Response 메시지에 담아 로컬 DNS 서버에 보낸다.
- DNS Response(로컬 DNS --> 웹 브라우저) : q.hash.kr 도메인을 관리하는 네임 서버로부터 www.q.hash.kr 도메인의 IP 주소를 알아낸 로컬 DNS 서버는 이제야 웹 브라우저로 IP 정보를 DNS Response 메시지에 담아 전달한다. 이 메시지에는 웹 브라우저가 요청했던 www.hash.kr.은 www.q.hash.kr이라는 별칭으로 사용된다는 CNAME 정보와 함께 해당 도메인의 IP 주소가 포함되어 있다.[5]
취약점[편집]
- 리커전 쿼리(Recursion Query)
- 도메인 네임 서버는 도메인을 IP 주소와 매핑하는 역할을 한다. 따라서, 접속하고자 하는 도메인이 있다면, 클라이언트는 일차적으로 자신의 캐시에서 해당 도메인의 IP 주소를 질의하고 만일 존재하지 않을 경우 설정한 네임 서버로 쿼리를 던진다. 쿼리를 받은 네임 서버는 자신이 운영하는 도메인인지 확인하고, 만일 아닌 경우 캐시에서 데이터를 검색하게 된다. 캐시에도 존재하지 않으면 상위 네임 서버에 질의하는 과정을 반복한다. 이렇게 순환적으로 질의하는 네임 서버 쿼리를 리커전 쿼리라고 한다.
- 도스 및 디도스(DoS & DDoS)
- 원래 네임 서버는 질의 요청을 받으면 자신이 운영하는 도메인들의 데이터를 검색하고, 자신이 운영하는 도메인이 아닌 경우에는 상위 네임 서버를 알려주고 해당 쿼리를 종료하여야 한다. 그렇게 되면 recurion이 여러 차례 발생하게 되어 그만큼 시간이 더 소요되므로 검색시간 단축을 위해 많은 네임 서버들이 리커전을 허용(opend DNS)하여 외부 네트워크에 속하는 서버 및 호스트에 대해서도 직접 조회하는 경우가 많다. 이러한 open DNS는 네임 서버로 들어오는 모든 쿼리에 대해 검색을 시도할 것이고, 따라서 수많은 질의가 한꺼번에 보내는 공격을 한다면 해당 네임 서버는 정상적인 요청을 처리하지 못하는 상태에 빠질 수 있다.
- 캐시 중독(Cache Poisoning)
- 공격자는 재귀 쿼리를 허용하고 있는 서버를 목표로 정한 후, 공격자 자신이 운영하는 네임 서버에 자신의 도메인을 비롯하여 특정 도메인의 잘못된 값 혹은 수많은 정상적 도메인들에 대한 잘못된 데이터를 저장해 두고 목표 서버를 사용하는 무작위 클라이언트가 자신의 도메인에 접속하도록 유도한다. 또는 공격자가 직접 재귀 쿼리가 허용된 목표 네임 서버에 자신의 도메인을 질의할 수도 있다. 목표 서버는 해당 도메인이 자신의 캐시에 없는 도메인이므로, 클라이언트의 질의에 대해 응답하기 위하여 공격자의 네임 서버로 질의를 하게 된다.
이 때 공격자의 네임 서버는 자신이 보유하고 있는 여러 위조된 도메인들도 계속적으로 질의하여 목표서버가 그 데이터를 전송받도록 한다. 따라서 새로운 위조 정보들로 캐시를 채우게 된다. 이러한 캐시 중독 공격이 위험한 이유는, 이로 인해 엉뚱한 사이트로 접속하게 하고 사적인 정보를 훔치는 파밍 공격을 유도할 수 있기 때문이다.[6]
각주[편집]
- ↑ 1.0 1.1 〈DNS〉, 《위키백과》
- ↑ Jung Woo, 〈도메인 네임 시스템(DNS)의 개관, 기능, 특징〉, 《블로그스팟》, 2014-08-18
- ↑ 3.0 3.1 〈DNS에 대해서〉, 《이글루스》, 2005-06-03
- ↑ 〈정보통신기술용어해설〉, 《ktword》, 2019-03-08
- ↑ 〈DNS 기본 동작 원리〉, 《넷매니아즈》
- ↑ 콩나물, 〈DNS문제점〉, 《네이버 블로그》, 2006-09-16
참고자료[편집]
- 고인돌SE, 〈DNS 개요〉, 《네이버 블로그》, 2004-07-28
- 〈DNS〉, 《위키백과》
- Netmanias teach,〈DNS 기본 동작 원리〉, 《넷 매니아즈》
- 로뚱쓰라이더, 〈DNS(Domain Name System)란?〉, 《네이버 블로그》, 2014-03-02
같이 보기[편집]
