이번에 소개할 내용은 도메인 네임 서비스(Domain Name Service)이다. 대부분
의 독자가 익히 들어 본 단어인데 실제 어떻게 구성되는지 차근차근 숙지해 나
가도록 하자.
양종윤 : 인하 대학교 전자계산 공학과 전문가시스템 연구실
들어가며
이 글을 읽는 독자 여러분들은 ‘www.inha.ac.kr’과 같은 인터넷 사이트명에
대해 매우 익숙할 것이라고 생각되는데 이러한 인터넷 사이트명, 다시 말해 도
메인 네임이 내부적으로는 IP 주소로 변환되어 컴퓨터가 이를 이해한다는 정도
도 알고 있을 것이라 생각된다.
바로 이러한 일을 해 주는 것이 도메인 네임 서비스인데 이제부터 어떻게 그
많은 이름을 IP 주소로 매핑할 수 있는지 알아보기로 하자.
도메인 네임 서비스(Domain Name Service)란 무엇인가? 한문장으로 말한다
면 호스트이름과 IP주소를 서로 매핑해주고 전자우편에 대한 경로설정(routing)
정보를 제공하는 일을 수행하는 TCP/IP 기반의 응용 프로그램이 사용하는 분
산 데이터베이스이다.
RFC 1034에 그 개념과 제공되는 기능에 대해 나와 있고, RFC 1035에서는 그
구현과 사양이 자세히 소개되어 있다. 응용 프로그램의 입장에서 보면 데이
터베이스를 가지고 이를 이용해 도메인 이름을 IP 주소로 매핑시키는 프로세스
를 운영하는 호스트를 네임서버라 할 수 있고 이를 이용하는(질의하는) 호스트
를 리솔버(resolver)라 한다.
이러한 네임서버와 리솔버가 구현된 일반적인 예가 BIND(Berkeley Internet
Name Domain Server)이다.
DNS(Domain Name System)의 구성 요소
DNS의 구성은 크게 다음과 같이 5가지로 이루어진다.
① 호스트에 대한 계층적 네임 공간(namespace) 정의
② 분산 데이터베이스로서 구현된 호스트 테이블을 정의
③ 이 데이터베이스를 질의하기 위한 라이브러리 루틴
(BIND의 일부) 정의
④ 전자우편을 위한 개선된 라우팅 정의
⑤ naming 정보 교환을 위한 프로토콜을 정의
위의 내용들을 지금부터 하나하나 자세히 설명하겠다.
DNS 네임공간(Namespace)
인터넷에는 셀 수 없이 많은 컴퓨터들이 네트워크를 통해 연결되어 있다.
이렇게 많은 컴퓨터에 사람이 알기 쉽도록 이름을 붙인다고 생각해 보자.
무작위로 붙이면 어떨까? 그러면 아마도 원래의 목적에 부합되게, 즉 사람이
알기 쉽게 이름을 붙이는데도 실패할 것이고 또한 중복된 이름이 많이 생기게
될 것이다. 그래서 나온 방안이 이름을 계층적으로 부여하는 방법이다.
이 방법이 바로 도메인 네임 시스템(Domain Name System-DNS) 이다.
그러므로 DNS는 하나의 커다란 트리구조로 생각할 수 있는데 트리의 루트는
‘ . ’ 이고 그 밑은 최상위 단계 도메인(top level domain)이다.
이 최상위 단계 도메인은 역사적인 이유로 2개의 최상위 단계 도메인 그룹이
존재한다. 최초 인터넷의 전신인 ARPANET이 미국에서 시작하였기에 당시 부
여한 도메인 이름은 후에 인터넷으로 발전한 후에도 그대로 사용할 수밖에 없
어 이렇게 2개 그룹이 공존하게 된 것이다.
미국에서는 com, edu, gov, mil, net, org, int, arpa 등이고 미국 밖에서는 2문
자의 ISO 국가 코드를 사용한다(au, jp, kr, ca, dk, de, fi, fr, se, hk, ch 등).
하지만 근래 들어서는 gov, mil을 제외한 다른 도메인 명은 다른 나라에서도
많이 사용하고 있다.
---------------------------------------------------------------
최상위 단계 도메인 이름 의 미
---------------------------------------------------------------
com 미국내의 회사와 같은 상업적인 기관
edu 미국내의 교육기관
gov 미국내의 정부기관
mil 미국내의 군대 관련 기관
net 게이트웨이와 다른 관리 호스트에 대한 이름
org 이외의 기타 조직 기관
kr 한국
au 호주
ca 캐나다
ae 아랍 에미레이트 연합
zw 짐바브웨
---------------------------------------------------------------
미국 이외의 지역에서 쓰이는 국가코드 부여시 기관에 대한 구분은 다시
ac(academy), co(Commercial), re(Resea rch) 등의 이름을 그 이름 앞에 부여
함으로써 이루어진다. 이것이 두 번째 단계 도메인(Second level domain)이다.
‘www.lg.co.kr’이나 ‘www.inha.ac.kr’ 등의 인터넷 사이트 명을 생각하면
될 것이다.
또한 도메인 이름은 대소문자를 구분하지 않는다(case insensitive).
두 번째 단계 도메인들은 국외의 경우는 NIC(Network Info Center)에 의해 유
지되며 국내의 경우는 KRNIC(Korea Network Information Center)에서 담당한
다.
이러한 두 번째 단계 도메인 이름을 할당받기 위해서는 다음과 같은 일을 수행
해야 한다.
1. 도메인 이름 정하기
RFC1032에서는 두 번째 단계 도메인을 12자나 그 이하로 할 것을 추천하고
있다. 실제로는 64자까지 가능하다.
2. 두 번째 단계 도메인 이름 등록하기
미국의 경우는 Registration Services group of NIC에 신청하는데 신청 양식은
rs.internic.net에서 ftp로 구할 수 있다. 이 양식은 domain-template.txt라고 불
리고 template 디렉터리에 있다.
유럽의 경우는 RIPE(mcsun.eu.net)에 신청한다.
만약 인터넷에 처음 접속시키는 경우는 IP 주소도 함께 신청해야 한다.
양식은 internet-number-template.txt에 있다.
3. 자신의 하위(Sub) 도메인 만들기
우선 자신의 지역 네트워크에서 고유한 이름을 선택하고 새 도메인에 서버가
될 2개 이상의 호스트를 결정한다. 그리고 상위 도메인의 관리자와 협조한다.
BIND의 구성요소
앞서 설명했듯이 주소의 매핑을 해주고 질의에 응답하는 프로세스를 운영하는
호스트를 네임서버라 할 수 있고 이를 이용하는(질의하는) 호스트를 리솔버
(resolver)라 한다고 하였다.
이러한 네임서버와 리솔버가 구현된 일반적인 예가 BIND(Berkeley Internet
Name Domain Server)라고 했는데 이 BIND의 구성요소는 다음과 같다.
(1) 질의에 대답하는 named 데몬
(2) DNS를 이용하는 호스트 질의를 풀어주는 라이브러리 루틴
(3) DNS로의 명령어 라인 인터프리터(nslookup, dig, host명령)
1. named : BIND 네임 서버
named는 호스트이름과 IP 주소에 대한 질의에 대답한다. 만약 대답하지 못하
는 경우는 다른 서버에 물어보고 결과를 캐시한다.
named는 또한 zone transfer(도메인 서버사이의 데이터 복사) 수행을 책임진
다.
네임 서버는 3가지 종류로 동작한다. 여기서 종류는 데이터가 어디서 오는가와
서버가 도메인을 관리하는가로 구분한다.
각 도메인이나 서브도메인에 대해 하나의 주(primary) 네임 서버가 존재한다.
주(Primary) 서버는 디스크에 도메인 데이터의 마스터 복사본을 유지한다.
부(Secondary) 서버는 주(Primary) 서버로부터 zone transfer 동작을 통해 도
메인 데이터를 복사한다.
캐시전용(Caching-only) 네임 서버는 스타트업 파일로부터 몇 개의 중요한 시
스템의 주소를 로드하고 이곳에서 대답하는 질의의 응답을 캐싱해서 다른 나머
지 데이터를 얻는다.
2. 리솔버(Resolver) 라이브러리
DNS를 이용하기 전의 호스트 이름 매핑은 ‘/etc/hosts’에서 gethostbyname,
gethostbyaddr 라이브러리 루틴들에 의해 이루어진다.
이 정보가 DNS에 의해 제공되어지게 하기 위해서는 이 루틴들이 변경되어야
한다.
3. 셸 인터페이스
nslookup 명령어는 셸에서 DNS로 접근 가능하게 한다. 이외에도 dig같은 명령
어도 있는데 뒤에 자세히 설명하기로 하겠다.
DNS의 동작 원리
프로그램은 gethostbyname 루틴으로 호스트 이름을 IP 주소로 매핑한다. 호스
트가 DNS를 사용하도록 조정되어 있으면 gethostbyname은 DNS 리솔버를 이
용해 주소에 대한 네임 서버에게 질의 응답한다.
네임 서버는 재귀(recursive)나 비재귀(non-recursive) 두 가지 성격의 서버로
구분된다.
비재귀 서버는 게으른 서버인데 이유인즉 질의의 답을 모르면 알만한 다른 서
버로 질의를 보내라고만 응답하기 때문이다. 즉 모르면 자기는 책임지지 않는
다는 얘기다. 그러므로 클라이언트 쪽이 이러한 반응에 대해 받을 준비가 되어
있어야한다.
재귀 서버는 오직 실제 답과 에러 메시지만을 리턴한다(모르겠다고 안함). 기본
질의 응답 프로시저는 동일하다.
두 서버의 차이는 바로 주소를 모르는 경우 질의 응답의 책임을 자기가 지느냐
그렇지 않느냐에 따라 나타난다.
재귀 네임 서버의 부작용은 캐시가 중간 도메인의 정보를 가져야 한다는 점이
다.
이러한 점은 지역적인 네트워크에서는 별 문제가 없으나 com과 같은 상위의
도메인에서는 그 성능이 감소된다는데 문제가 있다.
이런 이유로 일반적으로 하위 레벨의 도메인에서는 재귀 네임 서버를 설치하고
상위 레벨의 도메인에서는 비재귀 네임 서버를 설치한다.
실제 대부분의 유닉스 리솔버 라이브러리는 자신의 네임 서버가 재귀 서버라고
가정한다.
자 실제의 예를 들어보기로 하자.
(예) lair.cs.colorado.edu 시스템에서 mammoth.cs.berkeley.edu 시스템의 주소를
찾는 경우이다.
우선 lair.cs.colorado.edu는 자신의 지역 네트워크 네임 서버인
ns.cs.colorado.edu에게 mammoth.cs.berkeley.edu의 주소를 묻는다.
ns.cs.colorado.edu가 재귀 네임 서버이므로 일단 cs.berkeley나 berkeley에 대해
서는 그 주소를 자기가 담당하지 않더라도 질의에 응답하기 위해 EDU에게 물
어본다.
EDU는 비재귀 네임 서버이므로 ns.cs.colorado.edu에게 berkeley.edu으로 가서
물어보라고 한다.
ns.cs.colorado.edu는 이를 수신하고 나서 다시 berkeley.edu에게 질의를 한다.
berkeley.edu도 주소를 모르지만 재귀 네임 서버이므로 질의를 cs.berkeley.edu
에게 보낸다.
cs.berkeley.edu는 mammoth.cs.berkeley.edu의 주소를 관리하는 네임 서버이므
로 질의의 응답으로 그 주소를 ns.cs.colorado.edu에게 돌려준다.
이와 같은 진행 과정을 거쳐 원하는 주소를 얻게 된다. 우리가 넷스케이프와
같은 웹 브라우저에서 주소를 입력했을 때 화면 하단에 ‘…lookup…’과 같은
메시지를 볼 수 있는데 이 상태가 바로 위에서 설명한 상위 도메인으로의 질의
과정이 되는 것이다.
이러한 질의 과정이 끝나면 그 결과로 ns.cs.colorado.edu는 mammoth의 주소
와 berkeley.edu의 주소를 캐시한다. 또한 berkeley.edu의 서버 또한 mammoth
의 주소를 캐시하게 되어 다시 같은 질의를 받으면 바로 응답하게 된다.
named 질의는 UDP 프로토콜과 포트 53을 사용하여 이루어지는데 응답 메시
지가 512 바이트가 넘는 경우는 TCP를 경유하게 된다.
참고로 zone transfer 동작도 TCP를 이용한다.
BIND 클라이언트에서의 고려 사항
다음 표는 BIND 사용에서의 고려할 사항을 나타낸 것이다.
---------------------------------------------------------------
기 능 대 상 비 고
---------------------------------------------------------------
도메인 네임 얻기 사이트 한 번
네임 서버 선택하기 사이트 한 번 이상
BIND distribution 얻기 사이트 한 번
리솔버 컨피그 하기 클라이언트 한 번 하고 분배
효율적인 리솔버 컨피그하기 클라이언트 각 서브넷에 대해하고 분배
부트시 named 구동하기 서버 각 네임 서버
부트 파일 컨피그 하기 서버 각 서버의 타입
캐시 파일 컨피그 하기 서버 한 번하고 분배
zone 파일 컨피그 주 네임 서버 한 번
zone 파일 업데이트하기 주 네임 서버 필요할 때마다
로그 파일 확인하기 로그 호스트 한 주에 최소 한 번
사용자 교육하기 모든 호스트 영원히
---------------------------------------------------------------
BIND를 사용하는 모든 호스트는 클라이언트이므로 지금부터는 클라이언트쪽
의 고려 사항을 이야기하겠다.
1. 리솔버 컨피그 하기
각 BIND 클라이언트는 ‘/etc/resolv.conf’ 파일을 가져야 한다. 이 파일에는
주소를 모르는 경우에 질의를 할 네임 서버의 리스트를 가진다.
형식은 다음과 같다.
; 주석
search
nameserver
주석은 반드시 첫 열에서 시작해야만 한다.
네임서버는 한 개에서 3개까지 나열할 수 있다. 실제 파일 내용을 예로 들면
다음과 같을 것이다.
search inha.ac.kr
; ns, guyber, huclons
nameserver 165.246.10.2
nameserver 165.246.10.3
▶ search 지시자는 도메인 이름이 생략된 경우 완전한 도메인 이름으로 만들
어 주기 위해 사용되는데 최대 6개의 이름이 올 수 있다.
▶ namesever 지시자는 최대 3개까지 올 수 있는데 말 그대로 네임 서버의 주
소를 등록한다.
첫 번째 등록된 네임 서버에게 먼저 질의한 후 응답이 없으면 그 다음 네임 서
버로 질의하게 된다.
만약 호스트 자체가 네임 서버인 경우는 제일 처음에 등록되어야 하며 주의할
점은 루프백 주소(127.0.0.0)를 사용하지 말고 실제 IP 주소를 사용해야 한다는
점이다. 약간의 버그 때문이라고 한다.
참고로 BIND 초기 버전에서는 search 지시자 대신 domain 지시자를 사용하기
도 한다. 하지만 RFC 1535에서는 search의 사용을 강력히 추천하고 있다.
2. 리솔버 테스팅하기
어떤 시스템에서는 DNS를 사용하기 위해서는 단지 ‘/etc/resolv.conf’ 파일
에 네임 서버만 등록해 주면 되는 것도 있는 반면 시스템에 따라서는
‘/etc/hosts’ 나 NIS 대신 DNS를 사용할 것을 시스템에 명시 해 주어야 하
는 것도 있다.
후자의 경우는 해당 매뉴얼을 참조해야 할 것이다.
‘/etc/resolv.conf’를 컨피그한 후 nslookup이나 dig 명령어를 사용하여 제대
로 DNS를 사용하는지 테스트한다.
dig(Domain Infomation Groper)는 nslookup 명령어보다 자세한 정보를 보여준
다.
그리고 나서 다시 telnet, rlogin, finger, talk 등의 명령어를 써서 테스트한다.
who 명령어를 이용해 IP 주소가 아닌 완전한 도메인 명이 나오는지 확인할 수
도 있다.
3. DNS로 전환 후
정적인 hosts 테이블에서 DNS로 전환한 후에 다른 시스템에 영향을 미치는
부분이 생기게 된다.
우선 부팅시 네트워크가 설정되기도 전에 ‘/etc/rc*’ 의 호스트명의 참조가
행해지는 경우는 당연히 그 호스트명을 알 수 없기에 결국 호스트명을 얻는데
실패할 수가 있다.
이러한 경우 부트 과정 초기에 호스트의 IP주소를 명기해 주는 방법이 있을 수
있고 이 외에 만약 시스템이 ‘/etc/hosts’ 와 DNS를 동시에 지원한다면 부
트시 필요한 서버 주소를 포함하는 ‘hosts’ 파일을 설치해주면 된다.
또 영향을 받는 부분으로는 이전에는 호스트명을 제대로 다 쓰지 않아도 되었
던 부분이 완전한 도메인 명을 써주어야 하는 경우가 생기는데 바로
‘/etc/exports’ 파일과 sendmail 프로세스의 참조에 관한 부분이다. 이 두 부
분에 관련된 도메인 명에는 모두 완전한 이름으로 명시하면 된다.
네임 서버 설치하기
1. named 데몬 설치
named 데몬이 부트될 때 수행되도록 스타트업 스크립트에 다음과 같은 형태로
스크립트를 추가한다.
(예) "/etc/rc.local" 에
if [ -x /usr/etc/in.named -a -r /etc/named.boot] ; then
/usr/etc/in.named ; echo -n ' named' > /dev/console
fi
named 데몬은 구동되면서 ‘/etc/named.pid’ 파일에 자신의 프로세스 ID를
기록한다(BSDI에서는 ‘/var/run/ named.pid’).
만약 named 데몬에 시그널을 보내려면 위의 파일을 이용해 다음과 같이 명령
을 주면 된다.
kill -시그널번호 `cat /etc/named.pid`
참고로 IRIX에서는 이 파일이 없으므로 ‘killall -시그널번호 named’ 하면
된다.
named 데몬은 로그 파일 생성을 위해 syslog를 사용하므로 named 데몬을 구
동시키기 전에 먼저 syslogd 데몬을 구동시켜야 함을 명심하자.
만약 inetd 데몬을 이용해 named 데몬을 관리한다면 캐시 정보를 제대로 활용
하지 못하게 되므로(자꾸 캐시가 지워진다) 되도록 inetd 데몬을 이용해 named
데몬을 관리하는 일은 피하도록 하자.
2. ‘/etc/named.boot’ 파일
‘named.boot’ 파일은 각 zone(하나의 네임 서버가 관리하는 네트워크 공간)
에 대한 호스트의 역할과 DNS 데이터베이스를 복사하는 방법 등을 지정한다
(‘;’는 주석을 의미).
파일의 형식은 다음과 같다.
directory 디렉토리명
cache . 파일명
primary 존(zone) 파일명
secondary 존(zone) IP 주소 [....] 파일명
▶ directory 지시자 : 다음 라인부터 사용되는 파일명들의 상대적 경로를 지정
한다.
▶ cache 지시자 : 루트 네임 서버의 이름과 IP주소를 포함하는 파일을 지정한
다. 일반적으로 ‘/etc/named.ca’ 파일로 지정하나 많은 사이트들이 ‘/va
r’ 디렉터리로 옮겨 사용한다.
▶ primary 지시자 : 지정된 존(zone)에 대해 호스트가 주(Primary) 혹은 부
(Secondary) 서버임을 지정하고 존에 대한 데이터 파일이 있는 위치를 지
정한다.
▶ secondary 지시자 : 주(Primary) 서버의 IP 주소와 그 데이터를 복사해 캐
시할 데이터 파일을 지정한다.
하나의 네임 서버가 여러 개의 다른 존에 대한 서비스를 제공할 수 있다. 즉
named.boot 파일에 여러 개의 primary, secondary 지시자가 쓰일 수도 있다는
말이다.
이 외에 ‘named.boot’ 파일은 domain 지시자도 가질 수 있는데 이 지시자는
도메인 명이 완전히 쓰이지 않은 경우 이를 완전히 만들어 줄 때 추가되는 도
메인 명을 지정한다.
forwarders 지시자는 해당 네임 서버가 질의에 응답을 못하는 경우 그 질의를
보낼 다른 호스트를 지정한다. 여러 개도 지정 가능하다.
BIND 4.9에서는 컴파일 옵션으로 여러 다중 네트워크 클래스를 지원 가능하게
하고 있다. 또한 zone transfer가 불가능한 사이트를 지정할 수도 있다.
bogus 지시자는 특정의 네임 서버의 질의에는 응답을 거부하는 것을 지정한다.
xfrnets 지시자는 해당 서버의 데이터베이스를 복사 가능한 호스트들과 네트워
크 리스트를 지정한다.
사이트가 많은 도메인에 대한 부(Secondary) 서버인 경우는 관리의 편이를 위
해 include 지시자를 사용할 수도 있다.
sortlist란 예약어는 극히 사용할 일이 없지만 설명하자면 하나의 시스템이 여
러 개의 네트워크 카드를 끼울 수 있는 multiple network interface를 지원하는
경우의 질의에 대한 우선 순위를 지정하는 것이다.
테스팅과 디버깅
DNS 테스팅과 디버깅은 크게 named 데몬을 통한 것과 인터페이스 명령을 통
한 것으로 나뉜다.
1. named 데몬을 통한 디버깅
named 데몬은 에러나 이상 유무의 리포트에 syslog 체계를 이용한다.
---------------------------------------------------------------
단 계 원 인
---------------------------------------------------------------
crit 시리얼 번호가 일정하게 증가하지 않음
네임 서버 파일에 대한 접근 허가 문제
err malloc, open, close 등의 많은 시스템 에러
다음과 같은 데이터베이스 컨피그 에러
1. 2개의 root hints
(루트 네임서버의 이름과 주소)보다 더 적다
2. 도메인 이름이 너무 길다.
3. 알려지지 않은 리소스 레코드 타입
4. SOA 레코드가 없음
5. SOA 레코드가 중복
6. 알려지지 않은 지시자
7. CNAME 이 다른 데이터를 가짐
warning 또다른 데이터베이스 컨피그 에러
1. HINFO CPU 타입이 너무 길다(255자 이상).
2. HINFO OS 타입이 너무 길다(255자 이상).
3. TXT 레코드가 255자에서 잘림
notice 특정 서버로의 잘못된 전송
자기 자신에게로의 질의 시도
최대 질의수를 초과
서버를 다시 로딩
info 제 형태가 아닌 응답
---------------------------------------------------------------
위의 표는 named 데몬으로부터 생기는 syslog 메시지이다.
named 데몬의 디버그 단계는 0부터 11까지이다.
숫자가 클수록 정보가 자세하게 되는데 이는 d 플래그로 지정한다.
(예) named -d2
디버깅 정보는 ‘/var/tmp/named.run’ 파일에 기록된다. 또한 named 데몬은
USR1 시그널을 받으면 디버그 단계를 1만큼 올린다.
파일을 생성하는 시그널을 받으면 보통 ‘/var/tmp’ 나 ‘/usr/tmp’ 디렉터
리에 생성한다. USR2 시그널은 디버그 모드를 끈다. 만약 시그널 이름사용이
안된다면 ‘/usr/ include/signal.h’ 파일을 참조하면 된다.
INT 시그널은 ‘named_dump.db’ 파일로 데이터베이스를 덤프한다.
다음은 named 데몬이 이해하는 시그널들이다.
---------------------------------------------------------------
시그널 기 능
---------------------------------------------------------------
USR1 디버그 레벨을 1만큼 높임
USR2 디버깅을 해제
INT named_dump.db에 데이터베이스를 덤프
IOT/ABRT named.stats에 상태를 덤프
HUP 부트 파일과 데이터 파일들을 다시 로드
KILL named를 죽임
WINCH 들어오는 질의의 추적을 토글(BIND 4.9)
---------------------------------------------------------------
2. nslookup과 dig를 통한 디버깅
dig 명령을 이용해 eslab의 mx 레코드를 보고 싶다면
(예) dig eslab.inha.ac.kr. mx
---------------------------------------------------------------
명령어 기 능
---------------------------------------------------------------
help 전체 명령어 리스트를 보여준다.
exit 종료
server 호스트 현재 서버를 이용해 디폴트 서버를 세팅한다.
lserver 호스트 초기 서버를 이용해 디폴트 서버를 세팅한다.
set type=xxx 질의 타입을 지정한다.
set debug 디버깅 모드를 끈다.
set d2 디버깅을 수행한다.
ls 도메인 모든 호스트/주소 매핑을 보여준다.
---------------------------------------------------------------
이번에는 inha.ac.kr로부터 모든 레코드를 보려는 경우는
(예) dig @inha.ac.kr eslab.inha.ac.kr. any
위의 표는 nslookup의 명령들을 나타낸 것이다.
여러 OS에서의 차이점
1. 솔라리스
솔라리스는 BIND 4.8.3에 기반을 둔다.
솔라리스에서는 ‘/etc/nsswitch.conf’ 파일을 통해 BIND, NIS, NIS+ 와
‘/etc/hosts’ 파일과의 상호 작용을 지정한다.
파일에 ‘host : dns files’ 라고 지정하면 먼저 DNS를 참조한 후
‘/etc/hosts’파일을 참조한다.
SUN에서는 NIS+ 다음에 DNS를 참조할 것을 권장하고 있다.
다음은 파일명과 그 위치를 나타낸 것이다.
---------------------------------------------------------------
파 일 디렉토리 설 명
---------------------------------------------------------------
resolv.conf /etc Resolver 라이브러리 설정
in.named /etc 네임 서버 데몬
named-xfer /usr/sbin zone transfer 코드
named.boot /etc 네임 서버를 위한 부트 파일
named.pid /etc 프로세스 ID
named.run /var/tmp 디버그 모드에서의 출력
named.stats /var/tmp 상태정보 출력
named_dump.db /var/tmp 전체 데이터베이스 덤프
---------------------------------------------------------------
2. HP
HP 또한 BIND 4.8.3에 기반을 둔다.
HP는 참조 순서가 무조건 DNS, NIS, ‘/etc/hosts’ 파일 순이다.
특징적인 것은 관련 명령들이 추가적으로 있다는 것인데 host_to_named 명령
어는 ‘/etc/hosts’ 파일 형식의 데이터를 DNS의 리소스 레코드 형태로 변환
해 준다.
또한 sig_named 명령은 named 데몬에게 시그널을 전달하는 명령이다.
convert_rhosts 명령은 ‘/etc/newconfig/bind’ 디렉터리에 있는데 ‘.rhosts’
파일의 도메인 명을 완전한 도메인 명으로 변환해 주는 스크립트 파일이다. 한
번 훑어보면 도움이 될 것이다.
다음 표는 HP에서의 파일명과 그 위치이다.
---------------------------------------------------------------
파 일 디렉토리 설 명
---------------------------------------------------------------
resolv.conf /etc Resolver 라이브러리 설정
in.named /etc 네임 서버 데몬
named-xfer /etc zone transfer 코드
named.boot /etc 네임 서버를 위한 부트 파일
named.pid /etc 프로세스 ID
named.run /usr/tmp 디버그 모드에서의 출력
named.stats /usr/tmp 상태정보 출력
named_dump.db /usr/tmp 전체 데이터베이스 덤프
Zone 파일 /etc/newconfig/bind zond 파일의 디폴트 위치
---------------------------------------------------------------
3. IRIX
IRIX도 역시 BIND 4.8.3에 기반을 둔다.
‘/etc/config’ 파일에서 어떤 서비스가 컨피그 되었는지 가리킨다.
이 파일은 chkconfig 명령이나 텍스트 에디터로 수정될 수 있다.
서비스 참조 순서는 ‘/etc/resolv.conf’의 hostresorder 지시자로 지정한다. 만
약 ‘hostresorder bind local’ 과 같은 내용이 있다면 이는 DNS를 먼저 참조
한 후 ‘/etc/hosts’ 파일을 참조하라는 의미이다. 물론 여기서 NIS의 추가도
가능하다.
named.reload 명령은 named 데몬에게 hangup 시그널을 보내는 일을 한다.
named.restart 명령은 named 데몬을 죽이고 난 후 다시 시작시키기 때문에 캐
시가 청소되는 차이가 있다.
다음은 관련 파일과 그 위치이다.
---------------------------------------------------------------
파 일 디렉토리 설 명
---------------------------------------------------------------
resolv.conf /usr/etc Resolver 라이브러리 설정
in.named /usr/etc 네임 서버 데몬
named-xfer /usr/etc zone transfer 코드
named.boot /usr/etc/named.d 네임 서버를 위한 부트 파일
named.run /usr/tmp 디버그 모드에서의 출력
named.stats /usr/tmp 상태정보 출력
named_dump.db /usr/tmp 전체 데이터베이스 덤프
Zone 파일 /usr/etc/named.d zond 파일의 디폴트 위치
---------------------------------------------------------------
4. SunOS
SunOS는 리솔버가 NIS의 ypserv 데몬의 일부이다.
다시 말하면 NIS를 수행 안하면 DNS 서비스도 사용 못함을 의미한다.
BIND는 4.8.1을 기반으로 한다.
다음은 관련 파일들과 그 위치이다.
---------------------------------------------------------------
파 일 디렉토리 설 명
--------------------------------------------------------------
resolv.conf /etc Resolver 라이브러리 설정
in.named /usr/etc 네임 서버 데몬
named-xfer /usr/etc zone transfer 코드
named.boot /etc 네임 서버를 위한 부트 파일
named.pid /etc 프로세스 ID
named.run /var/tmp 디버그 모드에서의 출력
named.stats /var/tmp 상태정보 출력
named_dump.db /var/tmp 전체 데이터베이스 덤프
Zone 파일 /etc/named.* zond 파일의 디폴트 위치
---------------------------------------------------------------
5. OSF/1
OSF/1은 BIND 4.8.3을 기반으로 한다.
‘/etc/svc.conf’ 파일에서 서비스 참조 순위를 지정하는데 예를 들면
‘hosts=local, bind’ 라는 내용이 있으면 ‘/etc/ hosts’ 파일을 참조한 후
DNS를 참조함을 의미한다.
‘/etc/svc.conf’파일을 수정하려면 ‘/usr/sbin/svc setcup’ 스크립트를 사용
한다.
다음은 BIND 관련 파일과 그 위치이다.
---------------------------------------------------------------
파 일 디렉토리 설 명
---------------------------------------------------------------
resolv.conf /etc Resolver 라이브러리 설정
in.named /usr/sbin 네임 서버 데몬
named-xfer /usr/sbin zone transfer 코드
named.boot /etc/namedb 네임 서버를 위한 부트 파일
named.pid /var/run 프로세스 ID
named.run /var/tmp 디버그 모드에서의 출력
named.stats /var/tmp 상태정보 출력
named_dump.db /var/tmp 전체 데이터베이스 덤프
Zone 파일 /usr/local/domain zond 파일의 디폴트 위치
---------------------------------------------------------------
6. BSDI
BSDI는 BIND 4.9에 기반을 두면 무조건 DNS 다음에 ‘/etc/hosts’ 파일을
참조한다.
다음은 관련 파일과 그 위치이다.
---------------------------------------------------------------
파 일 디렉토리 설 명
---------------------------------------------------------------
resolv.conf /etc Resolver 라이브러리 설정
in.named /usr/sbin 네임 서버 데몬
named-xfer /usr/libexec zone transfer 코드
named.boot /etc 네임 서버를 위한 부트 파일
named.pid /var/run 프로세스 ID
named.run /var/tmp 디버그 모드에서의 출력
named.stats /var/tmp 상태정보 출력
named_dump.db /var/tmp 전체 데이터베이스 덤프
Zone 파일 /etc/namedb zond 파일의 디폴트 위치
---------------------------------------------------------------
마치며
이번 달에는 도메인 네임 서비스에 대해서 다루었다.
필자는 유닉스의 최대 강점이 네트워크 기능이라고 생각한다. 하지만 요즈음
나오는 마이크로소프트 사의 운영체계를 보고 있노라면 어느새 유닉스의 네트
워크 아성도 곧 무너질 것 같은 생각이 드는 것도 사실이다.
항상 후발 주자는 선발 주자의 장점을 모두 수용하고 그 외에 다른 특징을 포
함하는 것이 당연할지도 모르겠다. 유닉스의 네트워크 기능은 이래서 후발로
나오는 운영체계의 기본 모델이 되고 있는 만큼 철저히 공부해두면 다른 운영
체계의 네트워크 기능을 이해하는데도 크게 도움이 될 것이라 믿는다.
다음 호에는 네트워크 파일 시스템(NFS)에 대해 공부하기로 하겠다.
필자 연락처：HiTEL-huclons, 천리안- huclons
의 독자가 익히 들어 본 단어인데 실제 어떻게 구성되는지 차근차근 숙지해 나
가도록 하자.
양종윤 : 인하 대학교 전자계산 공학과 전문가시스템 연구실
들어가며
이 글을 읽는 독자 여러분들은 ‘www.inha.ac.kr’과 같은 인터넷 사이트명에
대해 매우 익숙할 것이라고 생각되는데 이러한 인터넷 사이트명, 다시 말해 도
메인 네임이 내부적으로는 IP 주소로 변환되어 컴퓨터가 이를 이해한다는 정도
도 알고 있을 것이라 생각된다.
바로 이러한 일을 해 주는 것이 도메인 네임 서비스인데 이제부터 어떻게 그
많은 이름을 IP 주소로 매핑할 수 있는지 알아보기로 하자.
도메인 네임 서비스(Domain Name Service)란 무엇인가? 한문장으로 말한다
면 호스트이름과 IP주소를 서로 매핑해주고 전자우편에 대한 경로설정(routing)
정보를 제공하는 일을 수행하는 TCP/IP 기반의 응용 프로그램이 사용하는 분
산 데이터베이스이다.
RFC 1034에 그 개념과 제공되는 기능에 대해 나와 있고, RFC 1035에서는 그
구현과 사양이 자세히 소개되어 있다. 응용 프로그램의 입장에서 보면 데이
터베이스를 가지고 이를 이용해 도메인 이름을 IP 주소로 매핑시키는 프로세스
를 운영하는 호스트를 네임서버라 할 수 있고 이를 이용하는(질의하는) 호스트
를 리솔버(resolver)라 한다.
이러한 네임서버와 리솔버가 구현된 일반적인 예가 BIND(Berkeley Internet
Name Domain Server)이다.
DNS(Domain Name System)의 구성 요소
DNS의 구성은 크게 다음과 같이 5가지로 이루어진다.
① 호스트에 대한 계층적 네임 공간(namespace) 정의
② 분산 데이터베이스로서 구현된 호스트 테이블을 정의
③ 이 데이터베이스를 질의하기 위한 라이브러리 루틴
(BIND의 일부) 정의
④ 전자우편을 위한 개선된 라우팅 정의
⑤ naming 정보 교환을 위한 프로토콜을 정의
위의 내용들을 지금부터 하나하나 자세히 설명하겠다.
DNS 네임공간(Namespace)
인터넷에는 셀 수 없이 많은 컴퓨터들이 네트워크를 통해 연결되어 있다.
이렇게 많은 컴퓨터에 사람이 알기 쉽도록 이름을 붙인다고 생각해 보자.
무작위로 붙이면 어떨까? 그러면 아마도 원래의 목적에 부합되게, 즉 사람이
알기 쉽게 이름을 붙이는데도 실패할 것이고 또한 중복된 이름이 많이 생기게
될 것이다. 그래서 나온 방안이 이름을 계층적으로 부여하는 방법이다.
이 방법이 바로 도메인 네임 시스템(Domain Name System-DNS) 이다.
그러므로 DNS는 하나의 커다란 트리구조로 생각할 수 있는데 트리의 루트는
‘ . ’ 이고 그 밑은 최상위 단계 도메인(top level domain)이다.
이 최상위 단계 도메인은 역사적인 이유로 2개의 최상위 단계 도메인 그룹이
존재한다. 최초 인터넷의 전신인 ARPANET이 미국에서 시작하였기에 당시 부
여한 도메인 이름은 후에 인터넷으로 발전한 후에도 그대로 사용할 수밖에 없
어 이렇게 2개 그룹이 공존하게 된 것이다.
미국에서는 com, edu, gov, mil, net, org, int, arpa 등이고 미국 밖에서는 2문
자의 ISO 국가 코드를 사용한다(au, jp, kr, ca, dk, de, fi, fr, se, hk, ch 등).
하지만 근래 들어서는 gov, mil을 제외한 다른 도메인 명은 다른 나라에서도
많이 사용하고 있다.
---------------------------------------------------------------
최상위 단계 도메인 이름 의 미
---------------------------------------------------------------
com 미국내의 회사와 같은 상업적인 기관
edu 미국내의 교육기관
gov 미국내의 정부기관
mil 미국내의 군대 관련 기관
net 게이트웨이와 다른 관리 호스트에 대한 이름
org 이외의 기타 조직 기관
kr 한국
au 호주
ca 캐나다
ae 아랍 에미레이트 연합
zw 짐바브웨
---------------------------------------------------------------
미국 이외의 지역에서 쓰이는 국가코드 부여시 기관에 대한 구분은 다시
ac(academy), co(Commercial), re(Resea rch) 등의 이름을 그 이름 앞에 부여
함으로써 이루어진다. 이것이 두 번째 단계 도메인(Second level domain)이다.
‘www.lg.co.kr’이나 ‘www.inha.ac.kr’ 등의 인터넷 사이트 명을 생각하면
될 것이다.
또한 도메인 이름은 대소문자를 구분하지 않는다(case insensitive).
두 번째 단계 도메인들은 국외의 경우는 NIC(Network Info Center)에 의해 유
지되며 국내의 경우는 KRNIC(Korea Network Information Center)에서 담당한
다.
이러한 두 번째 단계 도메인 이름을 할당받기 위해서는 다음과 같은 일을 수행
해야 한다.
1. 도메인 이름 정하기
RFC1032에서는 두 번째 단계 도메인을 12자나 그 이하로 할 것을 추천하고
있다. 실제로는 64자까지 가능하다.
2. 두 번째 단계 도메인 이름 등록하기
미국의 경우는 Registration Services group of NIC에 신청하는데 신청 양식은
rs.internic.net에서 ftp로 구할 수 있다. 이 양식은 domain-template.txt라고 불
리고 template 디렉터리에 있다.
유럽의 경우는 RIPE(mcsun.eu.net)에 신청한다.
만약 인터넷에 처음 접속시키는 경우는 IP 주소도 함께 신청해야 한다.
양식은 internet-number-template.txt에 있다.
3. 자신의 하위(Sub) 도메인 만들기
우선 자신의 지역 네트워크에서 고유한 이름을 선택하고 새 도메인에 서버가
될 2개 이상의 호스트를 결정한다. 그리고 상위 도메인의 관리자와 협조한다.
BIND의 구성요소
앞서 설명했듯이 주소의 매핑을 해주고 질의에 응답하는 프로세스를 운영하는
호스트를 네임서버라 할 수 있고 이를 이용하는(질의하는) 호스트를 리솔버
(resolver)라 한다고 하였다.
이러한 네임서버와 리솔버가 구현된 일반적인 예가 BIND(Berkeley Internet
Name Domain Server)라고 했는데 이 BIND의 구성요소는 다음과 같다.
(1) 질의에 대답하는 named 데몬
(2) DNS를 이용하는 호스트 질의를 풀어주는 라이브러리 루틴
(3) DNS로의 명령어 라인 인터프리터(nslookup, dig, host명령)
1. named : BIND 네임 서버
named는 호스트이름과 IP 주소에 대한 질의에 대답한다. 만약 대답하지 못하
는 경우는 다른 서버에 물어보고 결과를 캐시한다.
named는 또한 zone transfer(도메인 서버사이의 데이터 복사) 수행을 책임진
다.
네임 서버는 3가지 종류로 동작한다. 여기서 종류는 데이터가 어디서 오는가와
서버가 도메인을 관리하는가로 구분한다.
각 도메인이나 서브도메인에 대해 하나의 주(primary) 네임 서버가 존재한다.
주(Primary) 서버는 디스크에 도메인 데이터의 마스터 복사본을 유지한다.
부(Secondary) 서버는 주(Primary) 서버로부터 zone transfer 동작을 통해 도
메인 데이터를 복사한다.
캐시전용(Caching-only) 네임 서버는 스타트업 파일로부터 몇 개의 중요한 시
스템의 주소를 로드하고 이곳에서 대답하는 질의의 응답을 캐싱해서 다른 나머
지 데이터를 얻는다.
2. 리솔버(Resolver) 라이브러리
DNS를 이용하기 전의 호스트 이름 매핑은 ‘/etc/hosts’에서 gethostbyname,
gethostbyaddr 라이브러리 루틴들에 의해 이루어진다.
이 정보가 DNS에 의해 제공되어지게 하기 위해서는 이 루틴들이 변경되어야
한다.
3. 셸 인터페이스
nslookup 명령어는 셸에서 DNS로 접근 가능하게 한다. 이외에도 dig같은 명령
어도 있는데 뒤에 자세히 설명하기로 하겠다.
DNS의 동작 원리
프로그램은 gethostbyname 루틴으로 호스트 이름을 IP 주소로 매핑한다. 호스
트가 DNS를 사용하도록 조정되어 있으면 gethostbyname은 DNS 리솔버를 이
용해 주소에 대한 네임 서버에게 질의 응답한다.
네임 서버는 재귀(recursive)나 비재귀(non-recursive) 두 가지 성격의 서버로
구분된다.
비재귀 서버는 게으른 서버인데 이유인즉 질의의 답을 모르면 알만한 다른 서
버로 질의를 보내라고만 응답하기 때문이다. 즉 모르면 자기는 책임지지 않는
다는 얘기다. 그러므로 클라이언트 쪽이 이러한 반응에 대해 받을 준비가 되어
있어야한다.
재귀 서버는 오직 실제 답과 에러 메시지만을 리턴한다(모르겠다고 안함). 기본
질의 응답 프로시저는 동일하다.
두 서버의 차이는 바로 주소를 모르는 경우 질의 응답의 책임을 자기가 지느냐
그렇지 않느냐에 따라 나타난다.
재귀 네임 서버의 부작용은 캐시가 중간 도메인의 정보를 가져야 한다는 점이
다.
이러한 점은 지역적인 네트워크에서는 별 문제가 없으나 com과 같은 상위의
도메인에서는 그 성능이 감소된다는데 문제가 있다.
이런 이유로 일반적으로 하위 레벨의 도메인에서는 재귀 네임 서버를 설치하고
상위 레벨의 도메인에서는 비재귀 네임 서버를 설치한다.
실제 대부분의 유닉스 리솔버 라이브러리는 자신의 네임 서버가 재귀 서버라고
가정한다.
자 실제의 예를 들어보기로 하자.
(예) lair.cs.colorado.edu 시스템에서 mammoth.cs.berkeley.edu 시스템의 주소를
찾는 경우이다.
우선 lair.cs.colorado.edu는 자신의 지역 네트워크 네임 서버인
ns.cs.colorado.edu에게 mammoth.cs.berkeley.edu의 주소를 묻는다.
ns.cs.colorado.edu가 재귀 네임 서버이므로 일단 cs.berkeley나 berkeley에 대해
서는 그 주소를 자기가 담당하지 않더라도 질의에 응답하기 위해 EDU에게 물
어본다.
EDU는 비재귀 네임 서버이므로 ns.cs.colorado.edu에게 berkeley.edu으로 가서
물어보라고 한다.
ns.cs.colorado.edu는 이를 수신하고 나서 다시 berkeley.edu에게 질의를 한다.
berkeley.edu도 주소를 모르지만 재귀 네임 서버이므로 질의를 cs.berkeley.edu
에게 보낸다.
cs.berkeley.edu는 mammoth.cs.berkeley.edu의 주소를 관리하는 네임 서버이므
로 질의의 응답으로 그 주소를 ns.cs.colorado.edu에게 돌려준다.
이와 같은 진행 과정을 거쳐 원하는 주소를 얻게 된다. 우리가 넷스케이프와
같은 웹 브라우저에서 주소를 입력했을 때 화면 하단에 ‘…lookup…’과 같은
메시지를 볼 수 있는데 이 상태가 바로 위에서 설명한 상위 도메인으로의 질의
과정이 되는 것이다.
이러한 질의 과정이 끝나면 그 결과로 ns.cs.colorado.edu는 mammoth의 주소
와 berkeley.edu의 주소를 캐시한다. 또한 berkeley.edu의 서버 또한 mammoth
의 주소를 캐시하게 되어 다시 같은 질의를 받으면 바로 응답하게 된다.
named 질의는 UDP 프로토콜과 포트 53을 사용하여 이루어지는데 응답 메시
지가 512 바이트가 넘는 경우는 TCP를 경유하게 된다.
참고로 zone transfer 동작도 TCP를 이용한다.
BIND 클라이언트에서의 고려 사항
다음 표는 BIND 사용에서의 고려할 사항을 나타낸 것이다.
---------------------------------------------------------------
기 능 대 상 비 고
---------------------------------------------------------------
도메인 네임 얻기 사이트 한 번
네임 서버 선택하기 사이트 한 번 이상
BIND distribution 얻기 사이트 한 번
리솔버 컨피그 하기 클라이언트 한 번 하고 분배
효율적인 리솔버 컨피그하기 클라이언트 각 서브넷에 대해하고 분배
부트시 named 구동하기 서버 각 네임 서버
부트 파일 컨피그 하기 서버 각 서버의 타입
캐시 파일 컨피그 하기 서버 한 번하고 분배
zone 파일 컨피그 주 네임 서버 한 번
zone 파일 업데이트하기 주 네임 서버 필요할 때마다
로그 파일 확인하기 로그 호스트 한 주에 최소 한 번
사용자 교육하기 모든 호스트 영원히
---------------------------------------------------------------
BIND를 사용하는 모든 호스트는 클라이언트이므로 지금부터는 클라이언트쪽
의 고려 사항을 이야기하겠다.
1. 리솔버 컨피그 하기
각 BIND 클라이언트는 ‘/etc/resolv.conf’ 파일을 가져야 한다. 이 파일에는
주소를 모르는 경우에 질의를 할 네임 서버의 리스트를 가진다.
형식은 다음과 같다.
; 주석
search
nameserver
주석은 반드시 첫 열에서 시작해야만 한다.
네임서버는 한 개에서 3개까지 나열할 수 있다. 실제 파일 내용을 예로 들면
다음과 같을 것이다.
search inha.ac.kr
; ns, guyber, huclons
nameserver 165.246.10.2
nameserver 165.246.10.3
▶ search 지시자는 도메인 이름이 생략된 경우 완전한 도메인 이름으로 만들
어 주기 위해 사용되는데 최대 6개의 이름이 올 수 있다.
▶ namesever 지시자는 최대 3개까지 올 수 있는데 말 그대로 네임 서버의 주
소를 등록한다.
첫 번째 등록된 네임 서버에게 먼저 질의한 후 응답이 없으면 그 다음 네임 서
버로 질의하게 된다.
만약 호스트 자체가 네임 서버인 경우는 제일 처음에 등록되어야 하며 주의할
점은 루프백 주소(127.0.0.0)를 사용하지 말고 실제 IP 주소를 사용해야 한다는
점이다. 약간의 버그 때문이라고 한다.
참고로 BIND 초기 버전에서는 search 지시자 대신 domain 지시자를 사용하기
도 한다. 하지만 RFC 1535에서는 search의 사용을 강력히 추천하고 있다.
2. 리솔버 테스팅하기
어떤 시스템에서는 DNS를 사용하기 위해서는 단지 ‘/etc/resolv.conf’ 파일
에 네임 서버만 등록해 주면 되는 것도 있는 반면 시스템에 따라서는
‘/etc/hosts’ 나 NIS 대신 DNS를 사용할 것을 시스템에 명시 해 주어야 하
는 것도 있다.
후자의 경우는 해당 매뉴얼을 참조해야 할 것이다.
‘/etc/resolv.conf’를 컨피그한 후 nslookup이나 dig 명령어를 사용하여 제대
로 DNS를 사용하는지 테스트한다.
dig(Domain Infomation Groper)는 nslookup 명령어보다 자세한 정보를 보여준
다.
그리고 나서 다시 telnet, rlogin, finger, talk 등의 명령어를 써서 테스트한다.
who 명령어를 이용해 IP 주소가 아닌 완전한 도메인 명이 나오는지 확인할 수
도 있다.
3. DNS로 전환 후
정적인 hosts 테이블에서 DNS로 전환한 후에 다른 시스템에 영향을 미치는
부분이 생기게 된다.
우선 부팅시 네트워크가 설정되기도 전에 ‘/etc/rc*’ 의 호스트명의 참조가
행해지는 경우는 당연히 그 호스트명을 알 수 없기에 결국 호스트명을 얻는데
실패할 수가 있다.
이러한 경우 부트 과정 초기에 호스트의 IP주소를 명기해 주는 방법이 있을 수
있고 이 외에 만약 시스템이 ‘/etc/hosts’ 와 DNS를 동시에 지원한다면 부
트시 필요한 서버 주소를 포함하는 ‘hosts’ 파일을 설치해주면 된다.
또 영향을 받는 부분으로는 이전에는 호스트명을 제대로 다 쓰지 않아도 되었
던 부분이 완전한 도메인 명을 써주어야 하는 경우가 생기는데 바로
‘/etc/exports’ 파일과 sendmail 프로세스의 참조에 관한 부분이다. 이 두 부
분에 관련된 도메인 명에는 모두 완전한 이름으로 명시하면 된다.
네임 서버 설치하기
1. named 데몬 설치
named 데몬이 부트될 때 수행되도록 스타트업 스크립트에 다음과 같은 형태로
스크립트를 추가한다.
(예) "/etc/rc.local" 에
if [ -x /usr/etc/in.named -a -r /etc/named.boot] ; then
/usr/etc/in.named ; echo -n ' named' > /dev/console
fi
named 데몬은 구동되면서 ‘/etc/named.pid’ 파일에 자신의 프로세스 ID를
기록한다(BSDI에서는 ‘/var/run/ named.pid’).
만약 named 데몬에 시그널을 보내려면 위의 파일을 이용해 다음과 같이 명령
을 주면 된다.
kill -시그널번호 `cat /etc/named.pid`
참고로 IRIX에서는 이 파일이 없으므로 ‘killall -시그널번호 named’ 하면
된다.
named 데몬은 로그 파일 생성을 위해 syslog를 사용하므로 named 데몬을 구
동시키기 전에 먼저 syslogd 데몬을 구동시켜야 함을 명심하자.
만약 inetd 데몬을 이용해 named 데몬을 관리한다면 캐시 정보를 제대로 활용
하지 못하게 되므로(자꾸 캐시가 지워진다) 되도록 inetd 데몬을 이용해 named
데몬을 관리하는 일은 피하도록 하자.
2. ‘/etc/named.boot’ 파일
‘named.boot’ 파일은 각 zone(하나의 네임 서버가 관리하는 네트워크 공간)
에 대한 호스트의 역할과 DNS 데이터베이스를 복사하는 방법 등을 지정한다
(‘;’는 주석을 의미).
파일의 형식은 다음과 같다.
directory 디렉토리명
cache . 파일명
primary 존(zone) 파일명
secondary 존(zone) IP 주소 [....] 파일명
▶ directory 지시자 : 다음 라인부터 사용되는 파일명들의 상대적 경로를 지정
한다.
▶ cache 지시자 : 루트 네임 서버의 이름과 IP주소를 포함하는 파일을 지정한
다. 일반적으로 ‘/etc/named.ca’ 파일로 지정하나 많은 사이트들이 ‘/va
r’ 디렉터리로 옮겨 사용한다.
▶ primary 지시자 : 지정된 존(zone)에 대해 호스트가 주(Primary) 혹은 부
(Secondary) 서버임을 지정하고 존에 대한 데이터 파일이 있는 위치를 지
정한다.
▶ secondary 지시자 : 주(Primary) 서버의 IP 주소와 그 데이터를 복사해 캐
시할 데이터 파일을 지정한다.
하나의 네임 서버가 여러 개의 다른 존에 대한 서비스를 제공할 수 있다. 즉
named.boot 파일에 여러 개의 primary, secondary 지시자가 쓰일 수도 있다는
말이다.
이 외에 ‘named.boot’ 파일은 domain 지시자도 가질 수 있는데 이 지시자는
도메인 명이 완전히 쓰이지 않은 경우 이를 완전히 만들어 줄 때 추가되는 도
메인 명을 지정한다.
forwarders 지시자는 해당 네임 서버가 질의에 응답을 못하는 경우 그 질의를
보낼 다른 호스트를 지정한다. 여러 개도 지정 가능하다.
BIND 4.9에서는 컴파일 옵션으로 여러 다중 네트워크 클래스를 지원 가능하게
하고 있다. 또한 zone transfer가 불가능한 사이트를 지정할 수도 있다.
bogus 지시자는 특정의 네임 서버의 질의에는 응답을 거부하는 것을 지정한다.
xfrnets 지시자는 해당 서버의 데이터베이스를 복사 가능한 호스트들과 네트워
크 리스트를 지정한다.
사이트가 많은 도메인에 대한 부(Secondary) 서버인 경우는 관리의 편이를 위
해 include 지시자를 사용할 수도 있다.
sortlist란 예약어는 극히 사용할 일이 없지만 설명하자면 하나의 시스템이 여
러 개의 네트워크 카드를 끼울 수 있는 multiple network interface를 지원하는
경우의 질의에 대한 우선 순위를 지정하는 것이다.
테스팅과 디버깅
DNS 테스팅과 디버깅은 크게 named 데몬을 통한 것과 인터페이스 명령을 통
한 것으로 나뉜다.
1. named 데몬을 통한 디버깅
named 데몬은 에러나 이상 유무의 리포트에 syslog 체계를 이용한다.
---------------------------------------------------------------
단 계 원 인
---------------------------------------------------------------
crit 시리얼 번호가 일정하게 증가하지 않음
네임 서버 파일에 대한 접근 허가 문제
err malloc, open, close 등의 많은 시스템 에러
다음과 같은 데이터베이스 컨피그 에러
1. 2개의 root hints
(루트 네임서버의 이름과 주소)보다 더 적다
2. 도메인 이름이 너무 길다.
3. 알려지지 않은 리소스 레코드 타입
4. SOA 레코드가 없음
5. SOA 레코드가 중복
6. 알려지지 않은 지시자
7. CNAME 이 다른 데이터를 가짐
warning 또다른 데이터베이스 컨피그 에러
1. HINFO CPU 타입이 너무 길다(255자 이상).
2. HINFO OS 타입이 너무 길다(255자 이상).
3. TXT 레코드가 255자에서 잘림
notice 특정 서버로의 잘못된 전송
자기 자신에게로의 질의 시도
최대 질의수를 초과
서버를 다시 로딩
info 제 형태가 아닌 응답
---------------------------------------------------------------
위의 표는 named 데몬으로부터 생기는 syslog 메시지이다.
named 데몬의 디버그 단계는 0부터 11까지이다.
숫자가 클수록 정보가 자세하게 되는데 이는 d 플래그로 지정한다.
(예) named -d2
디버깅 정보는 ‘/var/tmp/named.run’ 파일에 기록된다. 또한 named 데몬은
USR1 시그널을 받으면 디버그 단계를 1만큼 올린다.
파일을 생성하는 시그널을 받으면 보통 ‘/var/tmp’ 나 ‘/usr/tmp’ 디렉터
리에 생성한다. USR2 시그널은 디버그 모드를 끈다. 만약 시그널 이름사용이
안된다면 ‘/usr/ include/signal.h’ 파일을 참조하면 된다.
INT 시그널은 ‘named_dump.db’ 파일로 데이터베이스를 덤프한다.
다음은 named 데몬이 이해하는 시그널들이다.
---------------------------------------------------------------
시그널 기 능
---------------------------------------------------------------
USR1 디버그 레벨을 1만큼 높임
USR2 디버깅을 해제
INT named_dump.db에 데이터베이스를 덤프
IOT/ABRT named.stats에 상태를 덤프
HUP 부트 파일과 데이터 파일들을 다시 로드
KILL named를 죽임
WINCH 들어오는 질의의 추적을 토글(BIND 4.9)
---------------------------------------------------------------
2. nslookup과 dig를 통한 디버깅
dig 명령을 이용해 eslab의 mx 레코드를 보고 싶다면
(예) dig eslab.inha.ac.kr. mx
---------------------------------------------------------------
명령어 기 능
---------------------------------------------------------------
help 전체 명령어 리스트를 보여준다.
exit 종료
server 호스트 현재 서버를 이용해 디폴트 서버를 세팅한다.
lserver 호스트 초기 서버를 이용해 디폴트 서버를 세팅한다.
set type=xxx 질의 타입을 지정한다.
set debug 디버깅 모드를 끈다.
set d2 디버깅을 수행한다.
ls 도메인 모든 호스트/주소 매핑을 보여준다.
---------------------------------------------------------------
이번에는 inha.ac.kr로부터 모든 레코드를 보려는 경우는
(예) dig @inha.ac.kr eslab.inha.ac.kr. any
위의 표는 nslookup의 명령들을 나타낸 것이다.
여러 OS에서의 차이점
1. 솔라리스
솔라리스는 BIND 4.8.3에 기반을 둔다.
솔라리스에서는 ‘/etc/nsswitch.conf’ 파일을 통해 BIND, NIS, NIS+ 와
‘/etc/hosts’ 파일과의 상호 작용을 지정한다.
파일에 ‘host : dns files’ 라고 지정하면 먼저 DNS를 참조한 후
‘/etc/hosts’파일을 참조한다.
SUN에서는 NIS+ 다음에 DNS를 참조할 것을 권장하고 있다.
다음은 파일명과 그 위치를 나타낸 것이다.
---------------------------------------------------------------
파 일 디렉토리 설 명
---------------------------------------------------------------
resolv.conf /etc Resolver 라이브러리 설정
in.named /etc 네임 서버 데몬
named-xfer /usr/sbin zone transfer 코드
named.boot /etc 네임 서버를 위한 부트 파일
named.pid /etc 프로세스 ID
named.run /var/tmp 디버그 모드에서의 출력
named.stats /var/tmp 상태정보 출력
named_dump.db /var/tmp 전체 데이터베이스 덤프
---------------------------------------------------------------
2. HP
HP 또한 BIND 4.8.3에 기반을 둔다.
HP는 참조 순서가 무조건 DNS, NIS, ‘/etc/hosts’ 파일 순이다.
특징적인 것은 관련 명령들이 추가적으로 있다는 것인데 host_to_named 명령
어는 ‘/etc/hosts’ 파일 형식의 데이터를 DNS의 리소스 레코드 형태로 변환
해 준다.
또한 sig_named 명령은 named 데몬에게 시그널을 전달하는 명령이다.
convert_rhosts 명령은 ‘/etc/newconfig/bind’ 디렉터리에 있는데 ‘.rhosts’
파일의 도메인 명을 완전한 도메인 명으로 변환해 주는 스크립트 파일이다. 한
번 훑어보면 도움이 될 것이다.
다음 표는 HP에서의 파일명과 그 위치이다.
---------------------------------------------------------------
파 일 디렉토리 설 명
---------------------------------------------------------------
resolv.conf /etc Resolver 라이브러리 설정
in.named /etc 네임 서버 데몬
named-xfer /etc zone transfer 코드
named.boot /etc 네임 서버를 위한 부트 파일
named.pid /etc 프로세스 ID
named.run /usr/tmp 디버그 모드에서의 출력
named.stats /usr/tmp 상태정보 출력
named_dump.db /usr/tmp 전체 데이터베이스 덤프
Zone 파일 /etc/newconfig/bind zond 파일의 디폴트 위치
---------------------------------------------------------------
3. IRIX
IRIX도 역시 BIND 4.8.3에 기반을 둔다.
‘/etc/config’ 파일에서 어떤 서비스가 컨피그 되었는지 가리킨다.
이 파일은 chkconfig 명령이나 텍스트 에디터로 수정될 수 있다.
서비스 참조 순서는 ‘/etc/resolv.conf’의 hostresorder 지시자로 지정한다. 만
약 ‘hostresorder bind local’ 과 같은 내용이 있다면 이는 DNS를 먼저 참조
한 후 ‘/etc/hosts’ 파일을 참조하라는 의미이다. 물론 여기서 NIS의 추가도
가능하다.
named.reload 명령은 named 데몬에게 hangup 시그널을 보내는 일을 한다.
named.restart 명령은 named 데몬을 죽이고 난 후 다시 시작시키기 때문에 캐
시가 청소되는 차이가 있다.
다음은 관련 파일과 그 위치이다.
---------------------------------------------------------------
파 일 디렉토리 설 명
---------------------------------------------------------------
resolv.conf /usr/etc Resolver 라이브러리 설정
in.named /usr/etc 네임 서버 데몬
named-xfer /usr/etc zone transfer 코드
named.boot /usr/etc/named.d 네임 서버를 위한 부트 파일
named.run /usr/tmp 디버그 모드에서의 출력
named.stats /usr/tmp 상태정보 출력
named_dump.db /usr/tmp 전체 데이터베이스 덤프
Zone 파일 /usr/etc/named.d zond 파일의 디폴트 위치
---------------------------------------------------------------
4. SunOS
SunOS는 리솔버가 NIS의 ypserv 데몬의 일부이다.
다시 말하면 NIS를 수행 안하면 DNS 서비스도 사용 못함을 의미한다.
BIND는 4.8.1을 기반으로 한다.
다음은 관련 파일들과 그 위치이다.
---------------------------------------------------------------
파 일 디렉토리 설 명
--------------------------------------------------------------
resolv.conf /etc Resolver 라이브러리 설정
in.named /usr/etc 네임 서버 데몬
named-xfer /usr/etc zone transfer 코드
named.boot /etc 네임 서버를 위한 부트 파일
named.pid /etc 프로세스 ID
named.run /var/tmp 디버그 모드에서의 출력
named.stats /var/tmp 상태정보 출력
named_dump.db /var/tmp 전체 데이터베이스 덤프
Zone 파일 /etc/named.* zond 파일의 디폴트 위치
---------------------------------------------------------------
5. OSF/1
OSF/1은 BIND 4.8.3을 기반으로 한다.
‘/etc/svc.conf’ 파일에서 서비스 참조 순위를 지정하는데 예를 들면
‘hosts=local, bind’ 라는 내용이 있으면 ‘/etc/ hosts’ 파일을 참조한 후
DNS를 참조함을 의미한다.
‘/etc/svc.conf’파일을 수정하려면 ‘/usr/sbin/svc setcup’ 스크립트를 사용
한다.
다음은 BIND 관련 파일과 그 위치이다.
---------------------------------------------------------------
파 일 디렉토리 설 명
---------------------------------------------------------------
resolv.conf /etc Resolver 라이브러리 설정
in.named /usr/sbin 네임 서버 데몬
named-xfer /usr/sbin zone transfer 코드
named.boot /etc/namedb 네임 서버를 위한 부트 파일
named.pid /var/run 프로세스 ID
named.run /var/tmp 디버그 모드에서의 출력
named.stats /var/tmp 상태정보 출력
named_dump.db /var/tmp 전체 데이터베이스 덤프
Zone 파일 /usr/local/domain zond 파일의 디폴트 위치
---------------------------------------------------------------
6. BSDI
BSDI는 BIND 4.9에 기반을 두면 무조건 DNS 다음에 ‘/etc/hosts’ 파일을
참조한다.
다음은 관련 파일과 그 위치이다.
---------------------------------------------------------------
파 일 디렉토리 설 명
---------------------------------------------------------------
resolv.conf /etc Resolver 라이브러리 설정
in.named /usr/sbin 네임 서버 데몬
named-xfer /usr/libexec zone transfer 코드
named.boot /etc 네임 서버를 위한 부트 파일
named.pid /var/run 프로세스 ID
named.run /var/tmp 디버그 모드에서의 출력
named.stats /var/tmp 상태정보 출력
named_dump.db /var/tmp 전체 데이터베이스 덤프
Zone 파일 /etc/namedb zond 파일의 디폴트 위치
---------------------------------------------------------------
마치며
이번 달에는 도메인 네임 서비스에 대해서 다루었다.
필자는 유닉스의 최대 강점이 네트워크 기능이라고 생각한다. 하지만 요즈음
나오는 마이크로소프트 사의 운영체계를 보고 있노라면 어느새 유닉스의 네트
워크 아성도 곧 무너질 것 같은 생각이 드는 것도 사실이다.
항상 후발 주자는 선발 주자의 장점을 모두 수용하고 그 외에 다른 특징을 포
함하는 것이 당연할지도 모르겠다. 유닉스의 네트워크 기능은 이래서 후발로
나오는 운영체계의 기본 모델이 되고 있는 만큼 철저히 공부해두면 다른 운영
체계의 네트워크 기능을 이해하는데도 크게 도움이 될 것이라 믿는다.
다음 호에는 네트워크 파일 시스템(NFS)에 대해 공부하기로 하겠다.
필자 연락처：HiTEL-huclons, 천리안- huclons
