|
|
|
|
“네트워크 규모에 따라 네임서버 운영 대수 결정해야” |
| DNS(Domain Name System) |
 |
2008년 05월 13일 00:00:00 |
데이터넷
|
 |
|
|
“네트워크 규모에 따라 네임서버 운영 대수 결정해야”
DNS는 분산구조 네임 체계 … ‘dig’ 이용한 DNS 진단 대세
DNS(Domain Name System)는 인터넷 정보를 담고 있는 거대한 분산 데이터베이스 시스템이고, 하나의 인터넷 정보를 다른 형태의 정보로 변환해주는 기능을 수행한다고 얘기한바 있다. 지난 호에서는 DNS란 무엇이고 DNS의 침해사례를 통해 중요성과 그에 따른 보안 취약점 대응책을 살펴봤다, 이번 호에서는 좀 더 구체적인 DNS의 구조와 DNS 서버의 취약점 진단, 구성 및 설정상의 베스트 프랙티스(Best Practice)에 대해 살펴본다. <편집자>
연재순서
1회 : DNS 중요성과 보안 취약점 대응책
2회 : DNS 서버 취약점 진단과 베스트 프랙티스(이번호)
3회 : IP 기반 네트워크 환경 도래에 따른 선결과제
4회 : 핵심 네트워크 서비스에 대한 효율적 관리방안
정재원 // 엑스퍼넷 기술3팀 대리jwjung@expernet.co.kr
DNS는 분산구조의 네임 체계다. 이는 분산된 구조의 도메인 데이터베이스를 형성하며 도메인 데이터베이스도 분산 관리 체계로 운영하고 있다. 이러한 분산된 도메인 데이터베이스의 구성과 분산 관리체계를 위해 위임(delegation)이 적용된다.
루트 도메인은 하위의 최상위 도메인(TLD : Top Level Domain)으로 해당 도메인의 관리를 위임한다. 그리고 최상위 도메인은 다시 2단계 도메인(SLD : Second Level Domain)을 생성해 그 관리를 위임한다. .kr 도메인의 경우에는 루트 도메인으로부터 국가별 도메인인 .kr 도메인의 위임을 받고 그 하위에 co.kr, or.kr, go.kr, ne.kr 등의 도메인을 생성해 도메인 위임을 하고 co.kr 도메인은 다시 국내 기업기관을 대상으로 필요한 도메인 등록과 그 위임을 하는 구조를 형성하고 있다.
이러한 위임에 있어 필요한 개념이 존(zone)이다. 이는 상위 도메인으로부터 위임받은 도메인을 기준으로 하위 노드를 생성, 관리하고 다시 서브 도메인을 생성 위임 및 관리할 수 있는 도메인 영역을 의미한다. 각 도메인의 관리자는 해당 도메인의 하위 영역을 독자적으로 관리하는 권한을 지닌다. 즉 위임은 도메인 네임의 생성, 유지, 삭제 등을 할 수 있는 일정한 영역의 도메인에 대한 관리 권한을 위임하는 것을 의미한다.
DNS는 이러한 위임체계를 통해 전 세계 각 사이트에서 위임 받은 도메인 영역에 대한 분산된 관리체계를 유지하고 있다. 도메인 등록시, 이 도메인에 대한 일정 기간 동안의 사용권과 함께 해당 도메인 하위의 모든 도메인 네임의 생성 유지, 삭제 등에 대한 전적인 관리 권한을 위임 받게 된다. 도메인 존은 도메인 트리 구조에서 특정 노드와 그 하위 노드를 포함하는 일정한 영역을 지칭한다.
루트(Root) 네임서버는 ccTLD(KR/JP 등)와 gTLD(COM/NET/ORG 등) 모두를 포함한다. 한 최상위 도메인의 네임서버 정보를 포함하고 있다. 현재 전 세계 13개의 루트 네임서버가 운영되고 있다. 이중 10개는 미국에서 운영되고, 나머지 3개는 다른 나라에서 운영된다. M서버의 경우 아시아에서 유일하게 일본에서 운영되고 있다.
최상위 도메인 현황
최상위 도메인은 일반 도메인(generic domain), 국가 도메인(country code domain), 인터넷 인프라 도메인(infrastructure domain)으로 구분할 수 있다. 최상위 도메인 중 일반 도메인은 gTLD(generic TLD)라하고, 국가 도메인은 ccTLD(country code TLD)라고 한다. 또 인터넷 인프라 도메인은 특수한 도메인으로써 ARPA 도메인을 지칭한다.
● gTLD(general Top Level Domain)
초기 인터넷에서 사용됐던 최상위 도메인으로 국가를 표기하지 않고, 도메인의 성격에 맞는 TLD를 가지게 된다. 최근에 여러 형태의 새로운 gTLD들이 ICANN의 허가를 통해 추가돼 그 개수가 상당히 많아졌다.
현재 등록한 가능한 도메인 16개(aero, asia, biz, cat, com, coop, info, jobs, mobi, museum, name, net, org, pro, tel, travel)가 있으며, 제한적으로 등록이 가능한 4개(gov, edu, mil, int)가 있다. 그 이외에 ARPAnet에서 유래된 .arpa(the Address and Routing Parameter Area domain)가 있다. http://www.iana.org/arpa-dom/에 보면 e164.arpa, in-addr.arpa, ip6.arpa, iris.arpa, uri.arpa, urn.arpa 형태의 2차 도메인(second-level domain)을 가지고 있는 것을 확인할 수 있다.
● ccTLD(country code Top Level Domain)
국가별로 인터넷을 운영하기 위한 도메인으로 ISO 3166의 2자리 국가코드로 TLD로 표기하는 방법이다. 즉 대한민국의 경우 ‘KR’ 이라는 ISO 3166(www.iso.org/iso/iso-3166-1_decoding_table) 코드를 이용해 ‘nida.or.kr’과 같이 도메인을 구성하는 것이다. 단, 영국의 경우 ISO 3166의 국가코드인 GB가 아닌 UK(United Kingdom)를 사용하고 있다.
네임서버 종류
네임서버는 DNS 질의에 응답한다. 네임서버의 종류로는 오쏘러테이티브 서버(Authoritative Server), 캐싱 네임서버, 오쏘러테이티브+캐싱 네임서버 등이 있다.
● 오쏘러테이티브 서버
1) 한 개 혹은 그 이상의 존들에 대해 권한이 있는(author itative) 응답을 제공한다.
2) 프라이머리(마스터) 서버는 해당 도메인을 관리하는 주 네임서버이고, 일반적으로 존 파일에서 자료를 로딩한다.
3) 세컨드리(슬레이브) 서버는 특정 도메인에 대한 백업 카피를 유지하는 서버다(존 전송(Zone Transfer)을 통해 마스터 서버로부터 복제된 자료를 전송받는다). 세컨드리는 프라이머리가 비정상으로 운행될 때와 부하 분산을 위해 운용하며, 다수가 존재할 수 있다. 세컨드리는 원칙적으론 외부 네트워크에 위치시켜 정전 등의 사태로 프라이머리가 다운됐을 때를 대비한다. 따라서 도메인을 운영하기 위해서는 최소 2대(프라이머리×1, 세컨드리×n) 이상의 네임서버가 요구된다.
4) 스텔스(Stealth) 서버는 세컨드리 서버와 같이 복제된 자료를 사용하지만 네임서버 목록에 나타나지 않는다.
● 캐싱 서버
캐싱 서버는 리졸버로부터 받은 DNS 질의를 분석 후 해당 자료를 저장하고 있는 오쏘러테이티브 서버들에게서 정보를 찾는 역할을 수행한다. 즉 도메인에 대한 데이터를 관리하지는 않고, 리졸빙(resolving)만을 처리한다. 또한 캐싱 서버는 오쏘러테이티브 서버들에게서 찾은 정보에 ‘Not Authoritative’ 표시를 한 후 리졸버에게 반환하고, 성능향상을 위해 한번 응답된 정보는 일정 기간 동안 메모리에 캐싱된다.
몇 개의 네임서버를 운영할 것인가?
몇 개의 네임서버가 충분한 것일까에 대한 정답은 없다. 다만 네트워크 규모를 기반으로 결정해야 할 것이다. 몇 가지 도움이 될 만한 지침을 살펴보자.
· 네트워크나 서브 네트워크는 직접 이용할 수 있는 네임 서버를 적어도 하나 이상 운영한다면 대다수 호스트가 하나 이상의 네트워크에 연결돼 있어 라우터가 고장이 나더라도 전체가 문제시 되는 일이 없어질 것이다.
· 네임서버를 가까운 곳에서 운영한다. 그렇다고 사용자가 붐비는 곳에서 운영할 필요는 없다. 사용자는 수많은 질의를 발생시키므로 관리자가 많은 사용자가 몰리는 호스트를 항상 잘 운영하기란 힘들 것이다. 그렇더라도 많은 사람이 접근하는 시스템에서는 네임 서버의 운영상 위험과 요구 사항이 조화를 이뤄야 한다.
· 하나의 네임서버를 사이트 외부에서 운영한다. 그러면 네트워크에 장애가 발생하더라도 데이터를 이용할 수 있다. 호스트에 도달할 수가 없는 상황에서의 주소 탐색은 쓸모없는 일이라고 주장할 수도 있다. 하지만 이런 경우는 어떨까? 네트워크도 살아있고 사이트 외부에 있는 네임 서버도 이용 가능하지만 다른 네임 서버는 모두 다운돼 있는 상황도 발생할 수 있을 것이다. 아울러 네임서버와 메일서버, 웹서버 등을 여러 장비로 분산해 운영하는 것이 바람직하다. 사이트 내의 네임서버가 다운된 경우 만일 사이트 외부에서 슬레이브를 하나 더 운영하지 않았더라면 네트워크와 웹 서버가 멀쩡하더라도 수많은 사람들이 웹서버 도메인 네임에 대한 주소 레코드를 얻지 못하므로 IP주소를 모르면 웹 서버를 방문할 수 없어 쇼핑 사이트의 경우 엄청난 손해가 발생할 것이다.
베스트 프랙티스
컴퍼니(company.com)라는 가상의 회사를 통해 최적의 DNS 인프라를 구축해 봤다. 다음 <그림 3>은 베스트 프랙티스에서 구성할 전체 구성도다. 각각의 구성에 대해 세부적으로 살펴보자.
- 본사
· 대략 2천명 임직원 근무
· 모든 제품은 호스트 기반의 애플리케이션(예 : SAP), 주 연결은 인터넷
· 대부분 사무직
· 본사 자원은 company.com 밑에 호스트, 프린터 존재
컴퍼니의 익스터널(external) DNS를 구조를 보면 적어도 100개 이상의 도메인을 등록해 놨다. 여기서는 인포블럭(Infoblox)이라는 DNS 전용장비를 통해 HA(High Availability)를 구성한 1개의 프라이머리 서버와 3개의 세컨드리로 구성하는 예를 들고자 한다.
우선 프라이머리는 회사의 방화벽 뒤에 위치하게 해 인터넷으로부터 보호될 수 있게 구성해야 한다. 방화벽 룰은 세컨드리 서버로 쿼리와 존 전송 이외의 어떤 외부 트래픽도 허용하지 않도록 하며 히든이라고 덧붙인 의미는 외부 존에서 네임서버 레코드가 나타나지 않도록 숨겨뒀다는 것이다. 3개중 2개의 세컨드리는 회사의 DMZ 구간에 존재하며 외부와 내부 방화벽 사이에 샌드위치 돼 있다. 이러한 구성을 통해 네임 변환 트래픽(name resolution traffic)을 최소화시키고, 포워더(Forwarder)를 둠으로써 인터넷 도메인명 변환을 빨리 처리하고 지연을 최소화시켜 인터넷에 보다 빨리 연결할 수 있게 했다.
컴퍼니의 인터널 DNS 구조를 보면 리졸버로부터 오는 쿼리에 대한 응답을 하고, company.com 존에 대한 권한을 가진다. 이 데이터는 본사의 모든 컴퓨터를 포함한다(프린터, 라우터, 허브, 서버 및 다른 네트워크 자원까지). 프라이머리는 숨겨져 있어 네임서버 레코드는 외부에 보이지 않지만 존 DB를 가지고 있으므로 세컨드리 서버로 존 전송을 하고, 각 세컨드리 서버에서 쿼리에 대한 응답을 하는 역할을 하게 한다.
- 지방 사무소
· 200명 이하의 임직원 근무
· 지방사무소 자원은 region.company.com 아래로 관리
· 네트워크 연결은 본사로, 다른 2개의 지방사무소로 연결
지방사무소는 리전(region)이라는 서브 도메인으로 운영한다. 프라이머리는 역시 숨겨져 있어 네임서버 레코드는 외부에 보이지 않지만 존 DB를 가지고 있어 세컨드리 서버로 존 전송을 하고, 각 세컨드리 서버에서 쿼리에 대한 응답하는 역할을 한다. 여기서는 금액적인 부담으로 세컨드리 서버는 HA로 구성하지 않았다.
- 계열사
· 12명 이상의 임직원 근무
· 각 지사는 지방사무소와 연계, region.company.com 아래로 관리
· 네트워크는 지방 사무소로 연결
계열사는 지방사무소의 한 파트로 리전 서브 도메인인 단일의 세컨드리 서버로 운영한다. 스텔스의 의미는 네임서버 레코드를 외부로 보여주지 않고 불필요한 다른 네임서버로부터의 쿼리를 방지하기 위해 만들어졌다. 리졸버는 계열사를 로컬 네임서버로 설정해 먼저 쿼리하도록 하고, 응답이 없으면 지방사무소 네임서버를 통해 쿼리하도록 설정돼 있다.
‘nslookup’ 이용한 DNS 설정 확인
인터넷 상에는 수많은 네임서버(DNS 서버)들이 있다. 이 네임서버에는 수많은 도메인들이 설정돼 있는데 제대로 설정됐는지 확인하기 위해 통상적으로 ‘nslookup’이라는 프로그램을 사용한다. 사용자가 디폴트 서버를 지정해 도메인을 IP로 바꾸는 것처럼 ‘nslookup’은 이 서버에게 쿼리를 하게 되고, 이 네임서버는 답변을 주게 된다. 만약 이 프로그램이 없다면 각각의 네임서버로 찾아가 직접 확인해 볼 수밖에 없다.
네임서버를 운영하고 관리하는데 있어 문제를 발견하고 해결하기 위해 리졸버의 입장으로 네임서버를 시험해볼 필요가 있다. 대부분의 시스템에 기본으로 설치돼 있는 ‘nslookup’은 ‘dig’와 함께 가장 널리 사용되는 네임서버 질의 도구다.
‘nslookup’은 기본적으로 입력된 도메인에 대해 A 레코드를 검색하고, IP주소(in-addr.arpa)에 대해서는 PTR 레코드를 검색한다. set type=RR 설정을 통해 A 레코드 이외의 레코드 또한 검색할 수 있으며 RR(Resource Record)에는 A, ANY, CNAME, HINFO, MX, NS, PTR, SOA, TXT 등이 올 수 있다.
· A(address) : 인터넷 호스트 주소
· PTR(domain name pointer) : IP주소에 대한 호스트명
· MX(mail exchanger) : 메일을 최종적으로 수신할 컴퓨터 호스트 이름
· NS(Name Server) : 도메인에 대한 네임서버
· SOA(Start Of Aauthority) : 리소스 레코드의 타입
· ANY : 도메인에 등록된 모든 레코드들을 출력하라는 약속 기호
네임서버에서 찾아온 IP주소는 네임서버의 캐시에 저장하게 된다. 다시 같은 도메인을 쿼리할 경우 캐시를 먼저 찾기 때문이다. 그렇다면 캐시에 남아있는 시간은 얼마나 될까? 이는 각 도메인 설정 시 지정한 TTL 값에 의해 달라진다.
도메인 설정 시 캐시에 남아있는 시간(TTL)을 임의로 설정할 수 있다. 다음의 예는 네임서버 kns.kornet.net에서 이전에 찾았던 www.expernet.co.kr의 IP주소를 얼마나 더 캐시에 가지고 있을 것인지 확인한 것이다. 이 시간이 지나면 처음 쿼리를 처리하는 것처럼 이름분석을 실행하게 된다.
> server 168.126.63.1 : 디폴트 서버로 변경
> set debug : 쿼리 결과를 디버그 모드로 보여주도록 설정
> www.expernet.co.kr : www.expernet.co.kr이 168.126.63.1 네임서버의 캐시에 얼마나 남아있는지 확인하기 위해 입력
ANSWERS:
→ ttl = 25분 37초 : 앞으로도 캐시에 남아있게 되는 시간
DIG이용한 DNS 설정 확인
DIG(Domain Information Groper)는 BIND DNS 배포 패키지에 기본으로 포함된 DNS 진단용 유틸리티로 DNS 룩업(lookup) 유틸리티의 일종이다. 그간 널리 사용돼 왔던 ‘nslookup’을 대체할 전망이다. BIND DNS의 배포처인 ISC(Internet Systems Consortium)은 ‘nslookup’을 향후 배포 패키지에서 제외할 예정이며, dig 사용을 권고하고 있다.
● dig는 어떤 경우 사용하나
DNS 네임서버 구성과 도메인 설정이 완료된 후, 일반 인터넷 사용자의 입장에서 설정한 도메인네임에 대한 DNS 질의응답이 정상적으로 이뤄지는 지를 확인 점검하는 경우에 사용한다. 이외에도 ISP 네트워크 관리자가 ADSL/VDSL 가입자의 장애현상에 대한 원인파악을 위해 DNS 네임서버 문제여부를 진단하는 용도로 사용되기도 한다.
dig는 ‘nslookup’에 비해 DNS의 추가 표준사항을 충실히 반영한 진단도구로 BIND DNS 네임서버의 알고리즘을 사용해 동작한다. 특히 ‘nslookup’ 보다 정확한 진단동작을 수행하는 관계로 관리자 측면에서 많이 사용되고 있다.
● dig 질의결과 출력내용
다음은 dig를 사용한 DNS 질의 결과로 기본 형식의 출력 예제다. dig 출력내용은 DNS 메시지의 헤더, 퀘스쳔 섹션, 엔서 섹션, 오쏘리티 섹션, 에디션 섹션의 구조에 맞춰 출력된다. 이에 부가해 끝 부분에 dig가 첨가하는 부가적인 정보로써의 DNS 응답소요 시간, DNS 응답서버 정보, DNS 메시지 사이즈 정보 등을 출력하고 있다.
DNS 점검
요즘 온라인상에서도 DNS를 점검할 수 있는 사이트와 자료가 많이 제공되고 있다. 그 중 유용한 사이트와 소프트웨어를 각각 하나씩 선정해 소개하고자 한다.
● 크리켓 류 DNS 어드바이저 소프트웨어
DNS 어드바이저 프로는 인포블럭과 DNS 산업의 1인자인 크리켓 류(Cricket Liu)가 디자인한 MS 윈도우 기반의 소프트웨어로, 70개 이상의 항목을 인터널 DNS 환경에서 테스트 할 수 있게 제공하고 있다. 이 프로그램은 다음과 같이 크게 5가지로 구분해 운영중인 DNS 서버를 테스트 한다.
- 정합성(Consistency) : 리졸루션 시간 및 상호 중복성 여부에 대한 모순 등을 확인
- 설정정보(Configuration) : 도메인 설정 등에 대한 오류 확인
- 성능(Performance) : 루트 서버로 쿼리 시 응답시간 체크
- 보안(Security) : 보안 취약점에 대한 분석 및 확인
- 컴플라이언스(Compliance) : 네임서버가 현재 프로토콜을 지원하는가에 대한 테스트.
이 소프트웨어는 프리웨어로 인포블럭 사이트(www. infoblox.com/services/dns-advisor-pro.cfm)에서 다운로드 받아 사용할 수 있다.
● 한국인터넷 진흥원
한국인터넷진흥원에서 제공하는 DNS 점검을 이용하면 도메인 설정 상의 많은 오류 사례로 인해 DNS 서비스의 불안정성을 유발할 가능성이 높은 사항들을 점검하거나 네임서버와 도메인의 안정적인 운영을 위해 권고하는 안정성 관련 사안들에 대해서도 점검할 수 있다.
다음 호에서는 IP 기반 네트워크 환경의 도래에 따른 선결과제로서의 DNS 서버뿐만 아닌 IP주소 관리, DHCP, RADIUS, VoIP 및 TFTP 서버운영 등의 점점 늘어나는 인프라 관리 방안에 대해 살펴보도록 하겠다. |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
