2장에서 설명한 바대로, TCP/IP 네트워킹은 호스트네임을 IP 주소를 변환하기 위한 여러 가지 스키마에 의존하고 있다. 가장 간단한 방법으로 /etc/hosts에 저장되어 있는 호스트 테 이블의 이름구역을 여러 지역으로 쪼개는 방법은 아무런 이득을 가져다 주지는 못한다. 이 러한 방법은 관리자 한사람에 의해 운영되며, 외부세계와 아무런 IP 트래픽이 발생하지 않 는 규모가 작은 LAN에서는 유용하다. hosts 파일의 형식은 이미 5장에서 설명하였다.
다른 방법으로, 여러분은 호스트네임을 IP 주소로 변환시킬 때 사용되는 BIND - Berkeley Internet Name Domain Service를 사용할 수도 있다. BIND를 구성하는 작 업은 정 말 따분한 일이지만, 네트워크 토폴로지를 쉽게 만들려면, 한번은 해야할 작업이다. 리눅스 나 또 다른 유닉스 계열 시스템에서, 네임 서비스는 named라는 프로그램을 통해 제공된다. 시동시, 이것은 마스터 파일들을 그 자체의 저장소(cache)에 적재하고, 리모트 또는 로컬 사 용자 프로세스에서 질의를 기다린다. BIND를 설정하는 방법은 여러 가지가 있지만, 모든 호스트에 네임 서버를 설정할 필요는 없다.
이 장에서는 네임 서버 운영에 관한 기본지식만 다룰 생각이다. 만약 여러분이 작은 LAN이상의 환경이나, 인터넷상에서 BIND를 사용할 계획이라면, 예를 들어, Cricket Liu의 "DNS and BIND" ([AlbitzLiu92]를 참조하라.)와 같이, 더 좋은 책을 읽어 보아야 할 것이 다. 이러한 정보를 위해서, 여러분은 BIND 소스에 포함되어 있는 release notes를 확인해 볼수도 있다. 또한 comp.protocols.tcp-ip.domains이라고 하는 DNS 뉴스 그룹도 있다.
"the resolver"은 특별한 어플리케이션이 아니라 "resolver library"를 지칭하는 것이다. 이것 은 C 라이브러리에 본 바탕을 두고 있는 기능의 모음집이다. 중심이 되는 루틴으로는 호스 트에 속해 있는 모든 IP 주소를 찾거나 IP 주소에 있는 모든 호스트를 찾아주는 gethostbyname(2)와 gethostbyaddr(2)를 들 수 있다. 이것들은 단순히 hosts에 있는 정보를 찾거나, 네임 서버의 네임을 질의하거나, NIS (Network Information Service)의 hosts 데이 터베이스를 사용하도록 구성되어 있다. smail과 같은 어플리케이션은 이러한 것들을 위한 드라이버를 포함할 수도 있으며, 이것은 특별한 경우에 필요하다.
여러분의 resolver 셋업을 제어하는 것이 바로 host.conf 파일이다. 이것은 /etc 디렉토리 에 있고, resolver가 사용할 서비스를 말해 주며, 그러한 서비스들은 순서대로 나열되어 있다.
host.conf에 있는 옵션들은 각각 독립된 한 라인에 존재한다. 필드는 스페이스나 탭으로 구분되어 있다. 해쉬 표시 (#)가 되어 있는 라인은 그 다음에 나올 각 옵션에 대해 짧막한 설명을 해주는 부분이다.
다음과 같은 옵션이 있다:
이것은 resolving service가 처리되는 순서를 결정한다. 이와 함께 사용되는 옵션으로는 bind, hosts, nis가 있는데, 각각이 하는 일은 네임 서버에게 질의를 한다든지, /etc/hosts에서 정보를 찾는다든지, NIS에서 필요한 정보를 찾는 역할을 한다. 이러한 것들 중 몇 개 혹은 전부를 명시할 수도 있다. 라인에 나타나는 순서는 각 서비스가 처리되는 순서 를 의미한다.
옵션을 사용할 수 있게 또는 사용할 수 없게 만든다. /etc/hosts에 있는 하나의 호스트가 여러개의 IP 주소를 가지게끔 할려면, 대개 "multihomed"를 사용한다. 이 플래그는 DNS나 NIS 질의에 아무런 영향을 끼치지 않는다.
5장에서 설명한 바대로, 여러분이 DNS는 in-addr.arpa 도메인을 사용해서, IP 주소에 해당하는 호스트 네임을 찾게 해준다. 네임 서버에 의해 잘못된 호스트 네임을 제공하는 것을 "spoofing"라고 한다. 이러한 점을 막기 위해서, resolver는 오리지널 IP 주소가 호스트네임과 연관되어 있는지를 검사하도록 구성되어 있다. 그렇지 않다면, 호스트네임은 어떤 에러를 발생시킬 것이다. 이러한 작업을 위해서는 nospoof로 설정해 놓아야 한다.
이 옵션은 변수를 사용할 수 있게 하거나 사용할 수 없게 만든다. 이 옵션을 on 시켜 놓으면, spoof 시도 (attempt)는 resolver가 syslog에 메시지를 저장하도록 만들 것이 다.
이 옵션은 도메인 네임을 변수로 설정한다. 즉, 도메인 네임은 룩업과정이 일어 나기 전에 호스트네임에서 삭제될 것이다. 이것은 hosts 엔트리를 사용하고자 할때 유용하게 쓰 인다. hosts 엔트리는 여러분이 로컬 도메인 없이 호스트네임을 명시하고자 할 때, 사용되는 것 이다. 호스트에 추가적으로 붙어 있는 로컬 도메인 네임의 룩업과정은 삭제되고, /etc/hosts에서 이러한 작업이 진행될 것이다.
옵션은 여러분의 호스트를 여러 로컬 도메인으로 간주하게끔 만들어 준다.
다음은 vlager에 대한 예제파일이다;
# /etc/host.conf
# We have named running, but no NIS (yet)
order bind hosts
# Allow multiple addrs
multi on
# Guard against spoof attempts
nospoof on
# Tirm local domain (not really necessary).
trim vbrew.com.
host.conf에서 설정하는 부분을 무시해 버리는 여러 가지 환경변수가 있다.
이것은 /etc/host.conf 대신에 읽어 들일 파일을 명시한다.
host.conf에 주어진 순서를 무시해 버린다. hosts, bind 그리고 nis에서 주어지는 서비스들은 스페이스, 콤마, 콜론 또는 세미 콜론으로 구분되어 있 다.
주어진 spoofing를 측정할건지를 결정한다. 완전히 사용할 수 없게 할려면, 그 뒤에 off를 붙여라. spoof 검사를 가능하도록 만들어 주는 warn과 warn off는 각각 로깅 온 (logging on)과 로깅 오프 (logging off)를 한다. * 변수는 spoof를 체크하겠다는 의미이지만, host.conf에 규정된 대로, 로깅을 하지는 않는다.
on 또는 off라는 변수는 host.conf에서 multi 옵션을 무시해 버릴 때 사용할 수도 있다.
이 환경은 host.conf를 무시해 버리는 트림 도메인 목록을 명시한다.
이 환경은 host.conf에 추가된 트림 도메인을 명시 한다.
여러분이 호스트 룩업을 위한 BIND 네임 서비스를 사용하기 위해서, resolver library를 구 성하려고 한다면, 사용할려는 네임서버를 말해 주어야 한다. 이러한 작업을 하기 위해서는 resolv.conf를 편집해야 한다. 이 파일이 없거나 파일안이 텅비어 있다면, resolver는 네임 서 버가 여러분의 로컬 호스트에 있다고 가정해 버린다.
만약 여러분의 로컬 호스트에서 네임서버를 실행하려고 한다면, 독립적으로 설정해 주어 야 한다. 그러나, 로컬 네트워크에 네임서버가 존재하고 있다면, 이것을 사용하는 것이 훨씬 더 경제적이다.
resolv.conf에서 가장 중요한 옵션은 nameserver이다. 이것은 사용할 네임서버에게 IP 주 소를 할당해 주는 일을 한다. 만약 여러분이 nameserver 옵션을 사용해서 여러 가지 네임 서버를 명시하고자 한다면, 그것들은 주어진 순서대로 처리된다. 먼저, 가장 믿을 만한 서버 를 택하는 것이 좋다. 현재, 가질 수 있는 네임서버의 수는 세 개다.
no nameserver가 주어진다면, resolver는 로컬 호스트에 있는 네임서버로 연결하려고 할 것이다.
domain과 search 옵션은 둘다 디폴트 도메인 설정시에 사용된다. 즉, BIND에서 첫 번째 질의가 실패했다면, 이러한 옵션들은 호스트네임에 덧붙혀진다. search 옵션은 접속을 시도 할려는 도메인의 목록을 명시한다. 각 항목들은 스페이스나 탭으로 구분되어 있다.
no search 옵션이 주어진다면, 그 자체의 도메인 네임을 사용해서, 로컬 도메인 네임으로 부터 디폴트 서치 리스트가 만들어 지며, 최고 루트까지 부모 도메인이 추가된다. 로컬 도메 인 네임은 domain 문장을 사용해서 만들 수도 있다; 만약 아무것도 주지 않는다면, resolver는 getdomainname(2) 시스템 콜을 사용해서 도메인 네임을 구할 것이다.
지금 이러한 설명이 조금 복잡하게 들린다면, Virtual Brewery에서 resolv.conf파일을 사용 하는 예를 생각해 보자:
# /etc/resolv.conf
# Our domain
domain vbrew.com
#
# We use vlager as central nameserver:
nameserver 191.72.1.1
vale라는 이름을 resolv하려고 할 때, resolver는 vale.vbrew.com과 vale.com과 같이 vale
를 사용하는 이름을 모두 찾을 것이다.
만약 여러분이 거대한 네트워크에서 LAN을 구현하려고 한다면, 중앙 네임 서버를 사용해야 한다. 이것을 사용하는 이점이라면, 모든 질의가 그 저장소 (cache)로 들어가기 때문에 많은 저장소를 만들어 낼 수 있다는 것이다. 하지만 이러한 스키마에도 약점은 있다: 대학의 백본 망이 파괴되었을 때, 각각의 LAN에서는 아무런 작업도 할 수 없다. 왜냐하면, resolver가 더 이상 네임서버에 도달 할 수 없기 때문이다. 그리고 X 터미널에도 접속할 수 없고, 프린 터도 사용할 수 없게 된다.
캠퍼스 백본이 파과되는 일이 매우 드문 경우이지만, 이러한 경우를 대비해서 예방조치 를 취해 두는 것도 좋은 방법이다.
로컬 네임서버를 설정하기 위한 한가지 옵션으로는 여러분의 로컬 네임서버에서 호스트 네임을 resolv하라. 그리고 다른 호스트네임을 위한 모든 질의를 메인 서버로 향하게 하라. 만약 여러분 자체의 도메인을 실행하고 있다면, 이것이 적절한 방법이 될 것이다.
다른 방법으로, /etc/hosts에 있는 여러분의 도메인이나 LAN을 위한 백업 호스트 테이 블을 유지할 수 있다. 만약 중앙 네임 서버가 다운되는 경우를 대비해서, resolver가 호스트 파일을 가리키지 않도록 할려면, /etc/host.conf에 "order bind hosts"를 추가시켜라.
대부분의 유닉스 계열 시스템에서 도메인 네임 서비스를 제공해 주는 프로그램은 named (대개 name-dee라고 발음한다.)이다. 이것은 원래 BSD에서 개발되었으며, 클라이언트에게 네임서비스를 제공해 주고, 또 다른 네임서버를 사용할 수 있게끔 해준다. 현재 대부분의 리 눅스 버전에서 사용되고 있는 버전은 BIND-4.8.3이다. 최근 버전인 BIND-4.9.3은 아직 베타 테스트 중이고, 가까운 시일내에 리눅스에서도 사용할 수 있을 것이다.
이 절은 Domain Name System이 어떻게 작동되는지를 이해시키는 부분이다. 만약 이해 할 수 없는 부분이 나온다면, 2장을 다시 한번 읽어보기 바란다. 그 장은 DNS에 관한 기본 적인 정보를 설명해 놓고 있다.
named는 대개 시스템이 부팅될 때, 시작되며, 시스템이 셧다운 되기 전까지 작동한다. /etc/named.boot 라는 구성파일에서 이러한 정보를 알 수 있으며, 이 파일에는 도메인 네임 을 주소에 대응시킬 때 사용하는 zone 이란 파일도 포함되어 있다. 이러한 파일의 형식과 의미는 다음절에 설명되어 있다.
named를 실행시키기 위해서는, 프롬프트에서 단순히 다음과 같이 하라.
# /usr/sbin/named
named는 named.boot와 그 가운데 명시되어 있는 zone 파일을 읽고나서, 실행될 것이다. 그것의 프로세스 id는 ASCII형태로 /var/run/named.pid에 쓰여져 있으며, 필요하다면, 프라 이머리 서버로부터 전송받을 수도 있으며, DNS 질의를 위한 포트 53에서 리스닝할 수도 있 다.
named.boot파일의 크기는 대개 매구 작고, 포함되어 있는 정보또한 그리 많진 않지만, zone 에 관한 정보를 포함하고 있는 마스터 파일과 또 다른 네임 서버를 가리키고 있다. 부트 파 일에서 세미 콜론으로 시작하는 문법은 다음 라인으로 연장한다는 의미이다. 자세한 정보를 위해서 named.boot의 형식을 논하기 전에, 그림 6.1에서 주어진 vlager을 위한 예제 파일을 먼저 살펴보자.
;
; /etc/named.boot file for vlager.vbrew.com
;
directory /var/named
;
; domain file
;----------------------------------------------
cache . named.ca
primary vbrew.com named.hosts
primary 0.0.127.in-addr.arpa named.local
primary 72.191.in-addr.arpa named.rev
그림 6.1: vlager를 위한 named.boot파일
이 예제에서 cache와 primary는 named에 정보를 적재시키는 명령이다. 이 정보는 두
번째 문장에 명시되어 있는 마스터 파일로부터 읽어 들인다. 그것들은 텍스트 형식으로 되
어 있는 DNS 자원 레코를 포함하고 있으며, 다음에 볼 것이다.
이 예제에서, 우리는 세 개의 도메인을 갖도록 named를 구성하였다. 이를테면, 이들 중 첫 번째 라인은 프라이머리 네임을 vbrew.com으로 활동하도록 named에게 통보했으며, 이 것은 named.hosts 파일에서 zone 데이터를 읽어 들인다. directory 라는 키워드는 모든 zone 파일이 /var/named에 위치하고 있다는 것을 말해준다.
cache는 매우 특별한 것으로써, 네임서버를 실행하고 있는 모든 기계를 가상적으로 표현 한다. 이것은 named가 그 자체의 저장소와 named.ca와 같은 저장(cache)파일로부터 root name server hints를 사용할 수 있게끔 해준다. name server hint에 대해서는 다음에 설명 하겠다.
다음은 여러분이 named.boot에서 사용할 수 있는 가장 중요한 옵션의 목록들이다.
이것은 zone 파일이 존재하고 있는 디렉토리를 명시한다. 파일들의 이름이 이 디렉토리와 연관되어서 주어진다. 여러 가지 디렉토리는 directory를 여러차례 사용함으로써 명시할 수 있다. 표준 리눅스 파일시스템에서는 /var/named가 되어야 한다.
이것은 변수로써 domain name과 file name을 사용한다. named 도메인을 위 해 서는 믿을 만한 로컬 서버를 사용하라. 프라이머리 서버에서, named는 주어진 마스터 파일로 부터 zone 정보를 적재시킨다. 일반적으로, 모든 부트 파일에는 적어도 하나의 primary 엔트리가 존재할 것이다. 즉, 127.0.0.0 네트워크를 변환시키면, 로컬 루프백 네트워크가 될 것이다.
이것은 변수로써, domain name와 address list 그리고 file name을 사용한 다. 로컬 서버를 명시된 도메인을 위한 두 번째 마스터 서버로 변환시켜 놓는다. 두 번째 서버는 도메인에 있는 믿을 만한 데이터를 가지고 있지만, 파일에서 자료를 가지고 오 진 못한다. 하지만 프라이머리 서버로부터 자료를 전송받을려고 할 것이다. 프라이머리 서버에 있는 IP 주소중 적어도 하나는 named로 주어져야 한다. 로컬 서버는 데이터를 zone 데이터베이스에 성공적으로 전송할 때까지, 각주소에 접속할 것이며, 세 번째 변수로 주어진 백업 파일에 저장되어 있다. 만약 어떤 프라이머리 서버도 응답하지 않는다면, zone 데이터는 대신에 백업파일에서 그 정보를 검색할 것이다. named는 규칙적인 간격으로 zone 데이터를 리프레시할 것이다. 이것은 이전에 SOA 자원 레코드 형태로 연결되었을 때 설명한 적이 있다.
이것은 domain name과 file name을 변수로써 사용한다. 이 파일은 root server hint를 포함하고 있으며, 모든 레코드 목록이 로트 네임서버를 가리키도록 되어 있다. 오직 NS와 A레코드가 인식될 것이다. domain 변수는 일반적으로 루트 도메인 네임을 지칭하는 것이다. 이 정보는 named에서 절대적인 것이다: 만약 cache 문이 부트 파일에서 발생하지 않았다면, named는 더 이상 로컬 저장소를 개발하지 않는다. 만약 질의를 받은 다음 서버가 로컬 네트워크에 존재하고 있지 않다면, 이것은 그러한 수행작업을 중단시켜 버릴 것이고, 네트워크 적재 작업을 심하게 증가 시킬 것이다. 게다가 named는 어떤 루트 네임 서버에도 도달할 수 없을 것이고, 그리하여, 믿을 만한 것을 제외하고는 어떤 주소도 해결 (resolve)하지 못할 것이다. 이러한 규칙에서 예외가 있다면, 그것은 전송중인 서버를 사용할 때 뿐일 것이다. (아래에 있는 forwarders 옵션)
이것은 변수로써 address list를 사용한다. 이 목록에 있는 IP 주소들은 만약 로컬 저장소에서 질의하는 과정이 실패로 끝이 났다면, named가 질의할 수 있 는 네임 서버의 목록을 명시한다. 이것들은 질의에 응답하는 것이 하나라도 있을 때 까지 이러한 작업을 계속한다.
이것은 네임 서버를 slave 서버로 만들어 준다. 그 자체내에서는 질의를 수행할 수 없지만, forwarders 문을 써서, 명시된 서버로 질의를 향하게 끔 만 든다.
여기에는 기술되어 있진 않지만, sortlist와 domain과 같은 옵션이 더 있다. 추가적으로 zone 데이터 파일에서 사용되는 두 개의 지시기가 있다. 그것들은 $INCLUDE와 $ORIGIN. 이다. 이것들이 거의 필요로 하지 않은 관계로 여기서는 설명하지 않았다.
named.hosts와 같이 named에 의해 포함되어 있는 마스터 파일은 항상 origin이라고 부르는 것과 연관되어 있는 도메인을 가지고 있다. origin은 cache와 primary 명령을 명시해 놓은 도메인 네임이다. 여러분은 마스터 파일안에, 이 도메인과 관련되어 있는 도메인과 호스트네 임을 명시해야 한다. 만약 absolute라는 파일앞에 도트가 붙어 있다면, 이 파일은 환경 구성 파일 이름이라고 간주하고, 그렇지 않고 다른 문자가 붙어 있다면, 대개 이 파일은 origin파 일이라고 간주한다. 모든 origin은 그 앞에 @을 붙인다.
마스터 파일에 있는 모든 데이터는 resource records 또는 줄여서 RR로 나누어져 있다. 이것들은 DNS파일을 통해서 사용할 수 있는 정보의 가장 작은 단위로 만들어져 있다. 각 자원 레코드는 어떤 형태를 가지고 있다. 이를테면, 하나의 레코드는 IP address를 호스트네 임과 대응시킬때 사용되고, CNAME 레코드는 공식적인 호스트네임을 가지고 있는 호스트 의 익명과 연관되어 있다. 예를 들어, 115페이지에 있는 그림 6.3을 보면, virtual brewery에 해당하는 마스터 파일인 named.hosts를 볼 수 있다.
마스터 파일에 있는 자원 레코드를 일반적인 포맷으로 할당하기 위해서는 다음과 같이 하 라.
[domain] [tt1] [class] type rdata
각 필드는 공백과 탭으로 구분되어 있다. 만약 첫 번째 라인을 쓰기 전에 여는 괄호가 나오고, 닫는 괄호가 마지막 필드에 해당한다면, 하나의 개체는 여러 가지 라인으로 이어져 있다. 세미콜론과 새로운 라인사이에 있는 것은 무시된다.
이것은 각 개체를 도메인 네임에 적용시키는 명령이다. 만약 아무런 도메인도 주어지지 않았다면, RR은 도메인이 이전에 적용시킨 RR이라고 가정한다.
특정한 시간이 지난후에 resolver가 어떤 정보를 강제로 폐기시키게 하기 위해서 는 RR을 "time to live" 줄여서 ttl과 연결시켜야 한다. ttl필드는 정보가 서버로부터 검색된 후에 유효하게 될 때 까지의 시간을 명시한다. 그 시간은 10 진수로 표시하며 대개 여덟 개의 아라비아 숫자로 되어 있다. 만약 아무런 ttl값도 주어지지 않았다면, 이전의 SOA 레코드의 minimun 필드를 초기값으로 설정한다.
이것은 IP 주소를 위한 IN 또는 Hesiod 클래스에 있는 개체들을 위한 HS와 같 은 주소 클래스이다. TCP/IP 네트워킹에서, 여러분은 이 IN을 만들어야 한다. 아무런 class 필드도 주어지지 않았다면, 이것을 이전의 RR 클래스로 가정한다.
이것은 RR의 형태를 기술한다. 일반적인 형태는 A, SOA, PTR 그리고 NS이다. 다음절에서 여러 가지 RR의 형태를 보여준다.
이것은 RR과 관련되어 있는 데이터를 가두어 놓는 역할을 한다. 이 필드의 형식 은 RR 형태에 의존한다. 다음절에서 각각의 RR에 대해 설명해 놓고 있다. DNS 마스터 파일에서 사용되는 RR 목록들을 전부다 기술해 놓지는 않았다. 여기서 설명하 지 않은 RR 목록들이 아주 많이 있다. 여기에서는 일반적으로 사용하는 몇가지만 기술해 놓았다.
이것은 권한 구역을 표시해 주고 있다. (SOA는 "Start of Authority"를 의미한 다.) 이 신호는 SOA RR에 해당하는 레코드가 도메인을 위한 믿을 만한 정보를 가지고 있다는 것을 표시해 준다. primary 문장에 포함되어 있는 모든 마스터 파일은 이러한 구역을 위한 SOA 레코드를 포함시켜야 한다. 여기에 있는 리소 스 데이터는 다음과 같은 필드를 포함하고 있다:
이것은 이 도메인을 위한 프라이머리 네임 서버의 호스트네임을 가리킨다. 이것은 대개 절대적인 이름으로 주어진다.
이것은 도메인을 유지 관리하고 있는 사람의 전자우편 주소를 가리킨다. 이것 은 도트 대신에 '@'이라는 문자를 사용한다. 이를테면, Virtual Brewery를 관리하고 있는 사람이 janet이라고 가정하자. 그러면 이 사람의 도메인 주소는 janet.vbrew.com이 된 다.
이것은 구역(zone) 파일의 버전 번호를 가리킨다. 이러한 번호는 십진수 하나로 표시되어 있다. 구역 파일에 데이터가 변경될 때 마다, 이 번호는 하나씩 증가한다. 두 번째 네임서버에 의해 사용되는 이 시리얼 번호는 구역(zone) 정보가 변경되었다는 것을 인식시켜 준다. 그러한 데이터가 최고가 될 때까지 두 번째 네임서버는 일정한 간격을 두고 프라이머리 서버에게 SOA 레코드를 요청하고, 저장된 SOA 레코드를 시리얼 번호와 비교한다. 만약 그 번호가 변경되었다면, 두 번째 서버는 프라이머리서버로부터 모든 구역(zone) 데이터베이스를 전송받는다.
이것은 두 번째 서버가 프라이머리 서버의 SOA 레코드를 검사하는 동안에 기다리는 시간을 나타내준다. 이것도 대부분 10진수로 되어 있으며 8개의 아라비아 숫자로 나타낸다. 일반적으로, 네트워크 위상(topology)은 그다지 자주 변경되지 않는다. 그래서, 거대한 네트워크나 이보다 작은 네트워크에서도 하루정도의 간격을 두고 명시해 주어야 한 다.
이 번호는 두 번째 서버가 프라이머리 서버와 접속하는 시간 간격을 명시해 준 다. 만약 이 번호를 크게 잡는다면, 일시적인 접속 실패나 네트워크 문제로 인해 두 번째 서버 가 네트워크 자원을 소비하는 결과를 초래할 수도 있다. 한시간 이나 반시간 정도가 알맞다.
이것은 두 번째 서버가 더 이상 프라이머리 서버에 접속할 수 없는 상태가 되었을 때, 이 서버가 마지막으로 모든 구역(zone)데이터를 폐기 처분할 때 걸리는 시간을 나타내준다. 일반적으로 매우 크게 잡힐 것이다. Craig Hunt ([Hunt92])는 42일을 의미한다.
이것은 자원(resource) 레코드를 위한 ttl의 초기값을 나타내주며, 이것은 명백하게 규정지울 수 없다. 이것은 특정한 시간이 경과한 후 에 RR(자원 레코드)을 폐기 처분하기 위해 또 다른 네임 서버가 필요하다. 그러나 어느 정도의 시간이 흐르면, 두 번째 서버는 구역정보를 갱신하지 않는다. 대개 LAN에서 네트워크 위상이 잘 변경되지 않기 때문에 minimum은 조금 크게 잡아야 한다. 한 주 또는 한 달을 잡는 것이 올바른 방법이다. 하나의 RR이 자주 변경되는 경우에, 여러분은 그것들을 다른 ttl로 할당할 수 있다.
이것은 호스트네임을 가지고 있는 IP 주소와 관련되어 있다. 자원(resource) 데이터 필드는 dotted quad notation로 표기되어 있는 주소를 가지고 있다. 각 호스트에는 오직 하나의 A 레코드가 할당되어야 한다. A 레코드에서 사용되는 호스트네임은 공식적인 호스트네임으로 간주한다. 다른 모든 호스트네임들은 CNAME 레코드를 사용한 공식적인 호스트네임과 대응되어야 한다.
이것은 종속(subordinate) 구역의 마스터 네임 서버를 가리킨다. NS 레코드를 가져야 하는 이유는 2.5절에 나타나 있다. 자원(resource)데이터 필드는 네임서버의 호스트네임을 가지고 있다. 호스트네임을 변경시키기 위해서는 추가적으로 A 레코드가 필요하다. 소위 glue 레코드라고도 하며, 이것은 네임서버의 IP 주소에 관한 정보를 가지고 있다.
이것은 canonical hostname이라고 하는 호스트의 별명과 관련되어 있다. 마스터 파일이 제공하는 A 레코드들 중에는 호스트네임도 포함되어 있다; 별명(alias)은 단순히 CNAME 레코드에 연결되어 있지만, 그 자체로서는 아무런 레코드도 가지고 있지 않다.
이 레코드 형태는 호스트네임을 가지고 있는 in-addr.arpa 라는 도메인과 연관 지어 사용한다. 이것은 IP 주소과 대응하는 호스트네임으로 변경시킬 때 사용한다. 이때 호스트네임은 공식적으로 사용하고 있는 호스트네임이어야 한다.
이것은 RR이 mail exchanger를 가리키도록 한다. 메일 교환기(mail exchanger)를 가지는 이유는 13장 Mail Routing on the Internet에서 설명할 것이다. MX 레코드는 메일 교환기를 사용해서 domain을 host 네임으로 바꾸어 주는 역할을 한다.
[domain] [ttl] [class] MX preference host
모든 메일 교환기는 그것과 관련되어 있는 정수형태로 되어 있는 preference를 가지고 있다. domain으로 메일을 전달하길 바라는 우편물 대행업자 (mail transport agent)는 이러한 전달과정이 성공할 때 까지, MX 레코드를 가지고 있는 모든 호스트에게 질의를 할 것이다. 우선순위가 제일 낮은 것부터 질의를 할 것이다.
이 레코드는 시스템의 하드웨어와 소프트웨어에 관한 정보를 제공한다. 이것의 문법은 다음과 같다.
[domain] [ttl] [class] HINFO hardware software
hardware는 이 호스트에 의해 사용되는 하드웨어를 가리켜 주는 필드이다. 이것 을 명시해 주기 위해서 사용하는 특별한 변환작업이 있다. 여기서 사용하는 이름 목록은 "Assigned Numbers" (RFC 1340)에 주어져 있다. 만약 하나의 필드에 공 백을 주려고 한다면, 그 필드를 "로 묶어야 한다. software 필드는 시스템에 의해 사용되는 운영체제 소프트웨어를 가리키는 이름이다. 이 이름도 "Assigned Numbers" RFC에 포함되어 있다.
그림 6.2, 6.3, 6.4 그리고 6.5는 brewery에서 vlager로 지정되어 있는 네임서버의 예제파일 들이다. 여기서 보인 예제파일들은 대체로 간단한 것들이다. 만약 더욱더 상세한 것을 원한 다면, named에서 얻지 말고, Cricket Liu 와 Paul Albitz([AlbitzLiu92])가 쓴 "DNS and BIND"를 참조하라.
그림 6.2에 보이는 named.ca 저장(cache) 파일은 루트 네임서버를 위해 레코드를 어떻게 주느냐 하는 것을 보여주는 예이다. 전형적인 저장 파일은 대개 12개의 네임서버에 대해 설 명해 놓는다. 이 장의 맨 끝에 설명되어 있는 nslookup라는 도구를 사용해서, 여러분은 루 트 도메인을 위한 현재 네임서버 목록을 구할 수 있다.
; /var/named/named.ca Cache file for the brewery
; We're not on the Internet, so we don't need
; any root servers. To activate these
; records, remove the semicolons.
;
; . 99999999 IN NS NS.NIC.DDN.MIL
; NS.NIC.DDN.MIL 99999999 IN A 26.3.0.103
; . 99999999 IN NS NS.NASA.GOV
; NS.NASA.GOV 99999999 IN A 128.102.16.10
그림 6.2: named.ca 파일
여러분의 네임 서버 설정을 검사하기 위해 사용하는 좋은 도구가 있다. nslookup라고 하는 이것은 대화식으로나 명령행에서 사용할 수 있다. 간단하게 다음과 같이 사용할 수 있고,
nslookup hostname
이것은 resolv.conf에 명시되어 있으며 hostname에 해당하는 네임서버에게 질의할 것이다. (만약 서버안에 하나 이상의 파일이 있다면, nslookup은 임의로 하나를 선택할 것이다.)
개인 호스트에서 사용하는 대화식 모드에서는 DNS 레코드형태를 질의하고, 해당 도메인 에게 전체 구역 정보를 전송한다.
아무런 인수없이 nslookup을 사용하면, 사용할 네임서버를 화면에 출력하고, 대화식 모 드로 들어갈 것이다. > 프롬프트에서, 여러분은 질의해야할 도메인 네임을 입력할 수도 있 다.
기본값으로 클래스 A 레코드를 요청한다. 이 레코드는 도메인 네임과 연관되어 있는 IP 주소를 포함하고 있다.
여러분은 "set type=type"라고 입력함으로써 이러한 형태를 변경시킬 수 있다. type는 6.2절에 기술되어 있는 자원 레코드 이름중 하나가 된다.
예를 들어, 여러분은 다음과 같은 대화상자(dialogue)를 가질 수도 있다:
$ nslookup
Default Name Server: rs10.hrz.th-darmstadt.de
Address: 130.83.56.60
> sunsite.unc.edu
Name Server: rs10.hrz.th-darmstadt.de
Address: 130.83.56.60
Non-authoritative answer:
Name: sunsite.unc.edu
Address: 152.2.22.81
만약 여러분이 어떤 IP 주소도 가지고 있지 않은 호스트네임을 찾거나, DNS 데이터베이 스에서 또다른 레코드를 찾고자 하는 경우, nslookup는 "No type A records found"라는 에 러를 화면에 출력할 것이다. 하지만 여러분은 "set type" 명령에 A라는 것을 입력해서 레코 드를 위한 질의를 만들 수 있다. 예를 들어, unc.edu의 SOA 레코드를 얻기 위해서는, 다음 과 같이 하라:
> unc.edu
*** No address (A) records available for unc.edu
Name Server: rs10.hrz.th-darmstadt.de
Address: 130.83.56.60
> set type=SOA
> unc.edu
Name Server: rs10.hrz.th-darmstadt.de
Address: 130.83.56.60
Non-authoritative answer:
unc.edu
origin = ns.unc.edu
mail addr = shava.ns.unc.edu
serial = 930408
refresh = 28800 (8 hours)
retry = 3600 (1 hour)
expire = 1209600 (14 days)
minimum ttl = 86400 (1 day)
Authoritative answers can be found from:
UNC.EDU nameserver = SAMBA.ACS.UNC.EDU
SAMBA.ACS.UNC.EDU internet address = 128.109.157.30
유사한 방법으로 MX 레코드를 질의하게 되면, 주어진 이름과 연관되어 있는 모든 리소 스 레코드를 되돌려 주게 된다.
> set type=MX
> unc.edu
Non-authoritative answer:
unc.edu preference = 10, mail exchanger = lambada.oit.unc.edu
lambada.oit.unc.edu internet address = 152.2.22.80
Authoritative answers can be found from:
UNC.EDU nameserver = SAMBA.ACS.UNC.EDU
SAMBA.ACS.UNC.EDU internet address = 128.109.157.30
디버깅까지 해주는 nslookup 어플리케이션은 named.ca 파일에서 현재 사용하고 있는 루 트네임서버 목록을 보여준다.
> set type=NS
> .
Name Server: fb0430.mathematik.th-darmstadt.de
Address: 130.83.2.30
Non-authoritative answer:
(root) nameserver = NS.INTERNIC.NET
(root) nameserver = AOS.ARL.ARMY.MIL
(root) nameserver = C.NYSER.NET
(root) nameserver = TERP.UMD.EDU
(root) nameserver = NS.NASA.GOV
(root) nameserver = NIC.NORDU.NET
(root) nameserver = NS.NIC.DDN.MIL
Authoritative answers can be found from:
(root) nameserver = NS.INTERNIC.NET
(root) nameserver = AOS.ARL.ARMY.MIL
(root) nameserver = C.NYSER.NET
(root) nameserver = TERP.UMD.EDU
(root) nameserver = NS.NASA.GOV
(root) nameserver = NIC.NORDU.NET
(root) nameserver = NS.NIC.DDN.MIL
NS.INTERNIC.NET internet address = 198.41.0.4
AOS.ARL.ARMY.MIL internet address = 128.63.4.82
AOS.ARL.ARMY.MIL internet address = 192.5.25.82
AOS.ARL.ARMY.MIL internet address = 26.3.0.29
C.NYSER.NET internet address = 192.33.4.12
TERP.UMD.EDU internet address = 128.8.10.90
NS.NASA.GOV internet address = 128.102.16.10
NS.NASA.GOV internet address = 192.52.195.10
NS.NASA.GOV internet address = 45.13.10.121
NIC.NORDU.NET internet address = 192.36.148.17
NS.NIC.DDN.MIL internet address = 192.112.36.4
nslookup에서 사용할 수 있는 모든 명령어는 nslookup 명령에 help를 입력함으로써 얻 을 수 있다.
여러분이 BIND 관리자로써 어떤 일을 할 때, 도움을 줄 수 있는 몇가지 도구가 있다. 이 문서에서는 그것들중 두가지만 간단히 설명하겠다. 그것들을 사용하는 방법에 대해서는 그 도구에 따라오는 설명서를 참조하기 바란다.
hostcvt는 여러분의 /etc/hosts 파일을 named에 해당하는 마스터파일로 변환시킴으로써, BIND 환경을 초기화시킬 때 도움을 줄수 있는 도구이다. 이것은 이전에 했던 A 레코드와 PTR 레코드를 대응시키고, 별명(alias)을 유지하는 일을 한다. 물론, 전체적인 작업을 하는 것은 아니다. 이를테면, SOA 레코드에 있는 타임 아웃 값을 일치시켜야 한다든지, MX레코 드를 추가시켜야 하는 작업은 여전히 여러분들의 몫이다. BIND 소스의 일부분인 hostcvt는 몇몇 리눅스 FTP 서버에 있는 스탠드얼론 패키지를 찾는데 사용할 수도 있다.
여러분의 네임서버를 설정하고 난후, 구성환경을 시험해 보고 싶어할런지도 모른다. 이러 한 작업을 하기 위해서는 perl에 기초를 두고 있는 dnswalk라는 도구를 사용하라. 이것은 DNS를 순회하면서, 일반적인 오류를 검사하고, 정보가 일치하는지를 검증하는 역할을 한다. dnswalk는 comp.source.misc에서 주기적으로 배포되고 있으며, 이 그룹(여러분이 어떤 사 이트도 들어보지 않았다면, ftp.uu.net를 저장해 두는 것도 좋은 생각이 될 것이다.)에 있는 정보를 보관하고 있는 모든 FTP 사이트에서도 쉽게 구할 수 있다.