DNS ( Domain Name System )

https://www.nic.or.kr

한국인터넷정보센터(KRNIC)

도메인 네임 시스템(Domain Name System)은 네트워크 계층이 이해하는 IP 주소와 사람이 이해하고 쉽게 기억할 수 있는 네임(name)을 상호 변환해주는 분산 데이터베이스 시스템으로 인터넷의 모태가 되었던 ARPANET의 발전과정에서 탄생하였다.

ARPANET의 본래 목적은 비싼 컴퓨팅 자원을 공유할 수 있게 하는 것이었는데, 초창기 소수의 호스트들만 연결되었던 환경에선 각 호스트에 대해 숫자 형식의 네트워크 주소를 직접 사용하였다. 그러나 점차 호스트의 수가 늘어나면서 보다 이해하기 쉽고 기억하기 쉬운 호스트 니모닉(mnemonic)의 사용이 도입되었다.

이는 보다 광범위한 범주에서 사용될 수 있는 도메인 네임 체계로 발전하여 현재의 인터넷 네임 체계인 DNS가 등장하는 계기가 된다.

 

DNS 프로토콜

 

DNS 프로토콜은 네트워크를 경유하여 DNS 구현요소 간에 DNS 질의(DNS query)와 응답(DNS response)을 수행하기 위한 서버-클라이언트 모델의 애플리케이션 프로토콜이다. DNS 프로토콜은 그림과 같이 {TCP,UDP}/IP 프로토콜 스택 위에 존재한다.

DNS 프로토콜은 TCP 및 UDP 포트 번호 53번을 사용한다. 네임서버는 TCP와 번 UDP 53 포트를 디폴트 포트(default port)로 하여 네트워크 상의 요청에 대기한다.

DNS 질의의 대부분은 UDP 포트 53을 사용하여 질의와 응답이 이루어진다.

그러나 UDP 헤더 이후의 DNS 헤더를 포함한 DNS 메시지 영역의 길이가 512 바이트를 초과하는 경우, TCP 53번 포트를 사용하는 TCP 연결을 통한 DNS 질의응답이 이루어지는 메커니즘이 존재한다. 이외에 TCP가 사용되는 경우는 동일한 도메인 존(domain zone)을 가지고 있는 네임서버간의 도메인 존(domain zone) 데이터 송수신을 위한 존 트랜스퍼(zone transfer)를 수행하는 경우이다. 이 경우에는 많은 데이터의 전송이 필요하므로 TCP를 사용한 연결을 통해 데이터 전송요청이 이루어진다.

DNS 프로토콜은 네임서버와 리졸버 간, 그리고 리졸버와 스터브 리졸버 간에 사용된다. 스터브 리졸버와 응용 프로그램은 프로그래밍 인터페이스를 사용하며 DNS 프로토콜을 사용치 않는다.

DNS 서버구조

(1) ICANN

ICANN(Internet Corporation for Assigned Names & Numbers)은 미국 캘리포니아주법에 근거하여 1998년 11월 탄생한 비영리 국제기구입니다. 인터넷상에서의 도메인 이름과 IP 주소, 프로토콜의 범주와 포트번호를 할당하는 업무와 새로운 최상위 도메인을 인가하기도 합니다.

ICANN의 중요한 임무 중 하나는 루트서버(root server)의 안정적 운영을 보장하는 것입니다. 루트서버란 com, net, kr, jp 등과 같은 최상위도메인(Top Level Domain, TLD)을 관리하고 있는 서버가 어디에 있는지에 대한 정보를 저장해 놓고 있는 서버로, 인터넷의 모든 주소 찾기가 시작되는 서버입니다. 이 서버가 제대로 관리되고 이 서버에 저장되어 있는 Zone 파일에 오류가 없어야 인터넷 상에서 각 도메인으로 제대로 연결될 수 있습니다.

ICANN은 산하에 도메인지원기구(DNSO; Domain Name Supporting Organization), 주소지원기구(ASO; Address Supporting Organization), 프로토콜지원기구(PSO; Protocol Supporting Organization)를 두고 있는데 도메인지원기구는 인터넷 컴퓨터에 어떤 범위의 숫자를 할당할 것인가를 결정짓는 기구이며, 프로토콜지원기구는 인터넷에 통용되는 기술적 표준들에 대한 업무를 관장하는 기구로, 각 표준 간의 호환성을 다룹니다. 또한 주소지원기구는 인터넷 도메인이름의 할당 및 관리를 담당하는 기구입니다.

 

(2) Registry

레지스트리(Registry)는 각 최상위 도메인의 등록기관으로, gTLD를 관리하는 Verisign, PIR, Neulevel 등과 ccTLD를 관리하는 세계 각 나라의 NIC이 이에 포함됩니다. 레지스트리의 역할은 등록된 도메인을 관리하는 것이며 도메인 네임서버를 운영하여 도메인 이름을 안정적이고 신속하게 찾을 수 있도록 합니다. 대표적인 레지스트리는 Verisign(com, net), PIR(org), Afilias(info), NeuLevel(biz), NIDA(kr), CNNIC(cn), JPNIC(jp), DENIC(de) 등입니다.

 

(3) Registrar

레지스트라(registrar)는 ICANN 및 레지스트리로부터 인가를 받은 도메인 등록대행업체를 말합니다. 레지스트라는 일반 사용자들로부터 도메인 등록을 받고 사용자에 대한 구체적인 정보를 관리하는 업무를 수행합니다.

gTLD의 주요 레지스트라는 NetSol, GoDaddy, Tucows, Asadal 등이며, kr 도메인의 레지스트라는 NIDA에 의해 등록대행자로 선정된 아사달, 가비아, 후이즈, 아이네임즈 등입니다.

 

(4) Reseller

리셀러(reseller)는 레지스트라의 관리를 받아 일반 사용자들로부터 도메인 등록을 받는 도메인 등록 재판매업체나 판매대행자를 말합니다.  도메인 이름을 등록하기 위해서는 도메인 등록을 대행하는 서비스 업체에 신청하면 됩니다. 전문 도메인 서비스 업체는 Registry와 계약을 맺어 서비스를 대행해주는 업체(Registrar)와 Registrar와 계약을 맺어 등록해 주는 재판매업체(Reseller)로 구분할 수 있습니다.

===========================================================================================

DNS 서비스만을 위한 방화벽 정책

네임서버는 다른 용도로 사용하지 않고 방화벽에서 네임서비스에 필요한 포트(Port)만 개방함에 따라 캐시오염(Cache Poisoning) 등의 침해의 가능성을 줄일 수 있다. 이에 따라 DNS 만을 위한 별도의 네트워크를 구축하고 DNS 서비스에 필요한 포트만 개방함으로써 보다 안전하게 DNS 서버를 관리할 수 있다. DNS 서비스에 필요한 포트는 일반적인 질의의 경우 UDP 53과 1024 ~ 65535의 포트를 사용하며, UDP의 메시지가 512Byte 초과 시 또는 Zone Transfer 시에는 TCP 로 질의할 수 있다.

 

Description	Source IP	Source Port	Destination IP	Destination Port
Queries from clients	Internal network	>1023/udp, >1023/tcp	Name server	53/udp, 53/tcp
Replies to clients	Name server	53/udp, 53/tcp	Internal network	>1023/udp, >1023/tcp
Outbound recursive queries	Name server	53/udp, 53/tcp, >1023/udp, >1023/tcp	Any	53/udp, 53/tcp
Replies to recursive queries	Any	53/udp, 53/tcp	Name server	53/udp, 53/tcp, >1023/udp, >1023/tcp

[표 4-33] 네임서비스를 위한 방화벽 정책 예시

출처: https://drake.kr/76047 [DRAKE]

출처: https://drake.kr/76047 [DRAKE]

 

1. Name Server 유형

네임서버는 Primary, Secondary, Cache only server로 구분된다.

Primary server는 해당 도메인을 관리하는 주 네임서버이고, Secondary server는 특정 도메인에 대한 back-up copy를 유지하는 서버이다. Secondary는 Primary가 비정상 운행될 때와 부하를 분산시키기 위해 운용하며, 다수가 존재할 수 있다.

보통 도메인을 관리하기 위해서는 Primary, Secondary 서버가 필요하게 되며, Secondary는 원칙적으론 외부 네트웍에 위치시켜 정전 등의 사태로 Primary가 다운되었을 때를 대비한다. 따라서, 도메인을 운영하기 위해서는 최소 2대(Primary * 1, Secondary * n) 이상의 네임서버가 요구된다.(기술적으로 Resolver의 입장에서는 Primary와 Secondary가 구분되지 않기에 Primary 만으로도 운영은 가능하나 권고되진 않는다)

Cache only server는 도메인에 대한 데이터를 관리하지는 않고, resolving만을 처리해 준다. 만약, 본사와 지사가 있고 이 회사의 Primary, Secondary Name server가 모두 본사에 위치한다고 할 때, 지사에 위치한 네트워크 유저들은 Local DNS server가 없게 된다. 이럴 경우 도메인 resolving이 요구될 때마다 다른 네트워크(본사)로 접속을 시도하게 되므로 약간의 딜레이가 생기게 되며, 본사 네트워크가 단절 되었을시 지사도 실질적으로 인터넷 사용이 불가능한 단점이 있다. 이럴 때 지사에 Cache only server를 운용하면 효과적으로 문제를 해결할 수 있다.

 

 

2. DNS 오류 수정 도구

2.1 NSLOOKUP

네임서버를 운영하고 관리하는데 있어 문제를 발견하고 해결하기 위해 Resolver의 입장으로 네임서버를 시험해볼 필요가 있다. 대부분의 시스템에 기본 설치되어 있는 nslookup은 dig와 함께 가장 널리 사용되는 네임서버 질의 도구로써, 도메인 메니저의 기본 무기중 하나이다.

    $ nslookup     Default Server:  ns.nobreak.com     Address:  210.105.79.2     > exit 

nslookup

은 실행후 대화형 프롬프트 '>'를 표시하고

/etc/resolv.conf

에 정의된 첫 번째 네임서버를 기본 질의 서버로 설정한다.

nslookup

은 BIND와 달리 하나의 서버만을 질의에 사용하기 때문에 'Default NS -> Timeout -> Error'와 같이 동작한다.

---

2.2. 도메인 네임 검색

nslookup

은 기본적으로 입력된 도메인에 대해 A 레코드를 검색하고, IP 주소(in-addr.arpa)에 대해서는 PTR 레코드를 검색한다.

set type=RR

설정으로 A 레코드 이외의 레코드 또한 검색할 수 있으며, RR(Resource Record)에는 A, ANY, CNAME, HINFO, MX, NS, PTR, SOA, TXT 등이 올 수 있다. 이중 ANY는 관련된 레코드들을 모두 출력하라는 약속 기호이다.

    > www.kr.freebsd.org.                 # IP 검색     Name:    www.kr.freebsd.org     Address:  150.183.110.39          > ftp.kr.freebsd.org.     Name:    www.kr.freebsd.org           # ftp는 www의 CNAME     Address:  150.183.110.39     Aliases:  ftp.kr.freebsd.org          > 150.183.110.39                      # 도메인 검색     Name:    www.kr.freebsd.org     Address:  150.183.110.39          > set type=MX                         # MX 레코드 검색     > kr.freebsd.org.     kr.freebsd.org  preference = 10, mail exchanger = mail.kr.freebsd.org          > set type=NS                         # NS 레코드 검색     > kr.freebsd.org.                     # 도메인 위임 확인     kr.freebsd.org     nameserver = ns.kr.freebsd.org     kr.freebsd.org     nameserver = ns2.kr.freebsd.org     ns.kr.freebsd.org  internet address = 150.183.110.2     ns2.kr.freebsd.org internet address = 150.183.110.3          > 46.102.39.in-addr.arpa.             # 인버스 도메인 위임 확인     kr.freebsd.org     nameserver = ns.kr.freebsd.org     kr.freebsd.org     nameserver = ns2.kr.freebsd.org     ns.kr.freebsd.org  internet address = 150.183.110.2     ns2.kr.freebsd.org internet address = 150.183.110.3 

2.3 기본 쿼리 서버 변경

nslookup은 기본적으로 recurse 모드로 동작하기 때문에, 때론 해당 도메인의 Authority를 갖는 특정 네임서버에 직접 질의를 하여 Authoritative 응답(네임서버의 캐쉬에서가 아닌)을 확인 할 필요가 있다. server, lserver 명령으로 기본 질의 서버를 변경 할 수 있다. 두 명령은 주어진 네임서버의 주소(쿼리가 아닌)를 찾을 때 사용할 질의 서버의 차이인데, server 는 현재의 기본 서버를 통하고, lserver 는 시스템 기본 서버(nslookup 구동시 초기 설정되는)를 사용함이 다르다. lserver 명령은 타 네임서버로 스위칭 한 후, 다시 다른 네임서버로 스위칭하려 하는데, 현재의 네임서버가 동작하지 않아 해당 네임서버의 주소를 검색하지 못할 때 사용한다. 다음을 보자.

    $ nslookup     Default Server:  ns.nobreak.com     Address:  210.105.79.2 

nslookup 구동시의 기본 서버 ns.nobreak.com 이 lserver 명령에서 주어진 NS의 주소를 찾기위한 질의 서버가 된다.

    > server ns.jp.freebsd.org.        # 기본 서버 변경     Default Server:  ns.jp.freebsd.org     Address:  199.100.7.25          > server ns.nobreak.com.     *** Can't find address for server ns.nobreak.com: Non-existent host/domain 

ns.jp.freebsd.org를 통해 ns.nobreak.com을 찾을 수가 없다. 이때에는

lserver

명령으로 시스템 기본 서버를 통해 ns.nobreak.com 의 주소를 검색한다.

    > lserver ns.nobreak.com.     Default Server:  ns.nobreak.com     Address:  210.105.79.2 

루트 네임서버를 질의 서버로 하고자 할 때는, 간단히 root 명령을 사용할 수 있다.

    > root     Default Server:  a.root-servers.net     Address:  198.41.0.4 

---

2.4 네임 서버처럼 질의하기

네임서버는 Resolver의 요청을 처리하기 위해, 네임스페이스를 검색하며, 여러 네임서버와 통신을 하는데, nslookup으로 동일한 과정을 밟아보도록 하자. 네임서버가 인터넷상에서 어떻게 동작하며, 네임서버들 간에는 어떤 사건들이 발생하고, 여러분을 위해 무엇을 하는지, 구체적인 느낌을 받을 수 있을 것이다.

Figure 8-1. 네임서버처럼 질의하기

    (1)     > set norecurse     # Iterative 모드로 전환     > www.kr.freebsd.org.     Server:  ns.nobreak.com     Address:  210.105.79.2          Name:    www.kr.freebsd.org     Served by:     - H.ROOT-SERVERS.NET               128.63.2.53               ORG     - B.ROOT-SERVERS.NET               128.9.0.107               ORG     ... 

ORG. 가 관리되는 루트 서버들의 목록을 레퍼런싱 해준다.

    (2)     > server h.root-servers.net.     > www.kr.freebsd.org.     Server:  h.root-servers.net     Address:  128.63.2.53          Name:    www.kr.freebsd.org     Served by:     - WHO.CDROM.COM               204.216.27.3               FREEBSD.ORG     - NS1.CRL.COM               165.113.1.36               FREEBSD.ORG     - NS2.CRL.COM               165.113.61.37               FREEBSD.ORG          (3)     > server who.cdrom.com.     > www.kr.freebsd.org.     Server:  who.cdrom.com     Address:  204.216.27.3          Name:    www.kr.freebsd.org     Served by:     - ns.kr.freebsd.org               150.183.110.2               kr.freebsd.org     - ns2.kr.freebsd.org               150.183.110.3               kr.freebsd.org          (4)     > server ns.kr.freebsd.org.     > www.kr.freebsd.org.     Server:  ns.kr.freebsd.org     Address:  150.183.110.2          Name:    www.kr.freebsd.org     Address:  150.183.110.39  

2.5 DIG

Dig(Domain Information Groper)의 사용법을 조금만 짚어보도록 하자.

nslookup

과의 기능적 차이는 크게 없지만, 사용이 간결하고, 출력이 상세하여, Shell Script등에서 주로 사용된다. 다음은 ns.kornet.ne.kr을 통해 www.nobreak.com의 A 레코드를 검색한 결과이다.

    $ dig [@네임서버] 도메인 [쿼리타입] [+쿼리옵션]     $ dig  @ns.kornet.ne.kr  www.nobreak.com  A     ;; ANSWER SECTION:     www.nobreak.com.        16h12m36s IN CNAME  ns.nobreak.com.     ns.nobreak.com.         1d19h12m27s IN A  210.105.79.2     ;; AUTHORITY SECTION:     nobreak.com.            22h17m35s IN NS  ns.nobreak.com.     nobreak.com.            22h17m35s IN NS  ns2.nobreak.com.     ;; ADDITIONAL SECTION:     ns.nobreak.com.         1d19h12m27s IN A  210.105.79.2     ns2.nobreak.com.        1d1h46m58s IN A  210.105.79.3 

DIG는 쿼리에 대한 결과를 ANSWER SECTION에, 해당 도메인의 인증을 갖는 네임서버 정보를 AUTHORITY SECTION에, 그리고, 글루레코드 등이 있을 경우 그에대한 정보를 ADDITIONAL SECTION에 출력하여 준다.

 

3 Iterative(Nonrecursive) & Recursive 네임서버

네임서버가 Recursive 모드로 동작할 때에는, 클라이언트(이를 Stub Resolver 라 한다)의 요청에 대해 Namespace를 검색한후 결과를 전달한다. 하지만 Iterative 모드에서는 알 수 없는 질의(자신이 관리하지 않는 도메인에 대한 요청)에 대해, 응답 가능한 NS의 목록을 전달한다. 대부분의 네임서버는 Recursive 모드로 동작하며, Iterative 모드는 루트서버와 같이 네임서버를 위한 네임서버(네임서버간의 통신에는 Iterative 모드가 사용됨)에서 과다한 트래픽을 막기위해 사용한다. 또한, 클라이언트는 Iterative 모드로 설정된 네임서버를 사용할 수 없으므로, 네임서버 목록(예:resolv.conf, 윈도우의 DNS 찾기목록)에 추가하여서는 안 된다. BIND-4에서는 부트파일에 'options no-recursion'을 추가함으로써, Iterative 모드로 전환할 수 있고, BIND-8의 경우엔 options 엔트리에 'recursion no;'를 설정한다.

 

[자료출처]

https://wiki.kldp.org/KoreanDoc/html/PoweredByDNS-KLDP/PoweredByDNS.html