|
D.M.Z
CONTENT
PRE
NEXT
6.1 The Resolver Library
6.2 Running named
2장에서 논한바와 같이, TCP/IP 네트워킹은 네임을 주소로 변환하는데 있어 서로
다른 체계에 의존한다. zone으로 나뉜 name space 방법의 잇점이 없긴하지만,
가장 단순한 방법은 /etc/hosts에 저장된 호스트 테이블이다. 이는
단 한명의 관리자가 운영하고, 외부세계로 IP traffic을
주고 받지 않는 소규모 LAN에서나 유용한 방법이다. hosts파일의 형식은 이미 5장에서
기술한 바 있다.
대신에, BIND (Berkely Internet Name Domain Server)를 사용하여 호스트네임을 IP 주소로
변환할 수있다. BIND를 설정하는 것은 정말로 허드렛일일수 있으나, 한번 해
놓으면 네트웍 토폴로지의 내용을 쉽계 변경할 수 있다. 리눅스 상에서 네임
서비스는 다른 UN*X 시스템처럼 named라는 프로그램을
통해 제공된다. 그것은 시작될 때 마스터 파일을 캐쉬에 읽어들이고 리모트 또는
로컬 사용자 프로세스의 쿼리를 기다린다. BIND를 셋업하는덴 서로 다른 방법이
존재하고, 그들 모두가 모든호스트에서 네임서버를 돌릴 필요는 없다.
이 장에선 네임 서버를 어떻게 조작하는 것인가에 대한 개략적인 설명만을 한다.
만약 당신이 인터넷에 연결된, 작지만은 않은 LAN 환경에서 BIND를 사용할
계획이라면, Cricket Liu의 "DNS and BIND"([AlbitzLiu92]를 보라)같은 BIND에 관한
좋은 서적을 구해보아야 한다. 최신정보를 구하려면, BIND 소스에 포함된 릴리즈 노트를
검토하자. DNS에 대한 뉴스그룹은 comp.protocols.tcp-ip.domains이다.
6.1 The Resolver Library
"resolver"는 특수한 어플리케이션을 의미하는 것이아니라, 대신 표준
C 라이브러리내에 있는 함수 모음인 resolver library를 가리킨다.
핵심 루틴은 gethostbyname(2)와 gethostbyaddr(2)로,
이들은 한 호스트에 속한 모든 IP 주소를 검색하거나, 그 반대이다. 그것들은
hosts내의 정보를 단순히 찾거나, 네임서버들에 쿼리를 보내거나, 혹은
NIS (Network Information Service)의 hosts 데이터베이스를 사용하도록
설정될수 있다.
smail과 같은, 그외의 어플리케이션은 이들중 어느것과도 다른 드라이버를
포함할 수 있으며, 특별한 주의을 필요로한다.
6.1.1 The host.conf File
당신의 resolver 설정을 제어하는 핵심파일은 host.conf이다. 그것은
/etc내에 있으며, resolver에 어떤 서비스가 어떤 순서로 사용되는지를
알려준다.
host.conf내의 옵션은 각각의 라인에 따로 써줘야 한다. 필드는
공백(space 또는 tab)으로 나누어지며, 해쉬부호 (#)는, 뉴라인까지는
주석문임을 표시한다.
다음의 옵션들이 사용가능하다.
| order |
이것은 resolving 서비스가 시도되는 순서를 결정한다. 네임서버에 쿼리를
보내도록 하는 올바른 옵션은 bind이며, hosts는 /etc/hosts에서
검색을, 그리고 NIS 검색을 위한것은 nis이다. 그들 중 어느 한쪽이나 모두가
지정될 수 있으며, 라인상의 순서에 따라 각각의 서비스를 시도한다. |
| multi |
옵션으로 on이나 off를 쓸 수 있다. 이것은 /etc/hosts내의
한 호스트가, 흔히 "multi-homed"라 언급되는, 몇개의 IP 주소를 가질 수 있는지
없는지를 결정한다. 이 플래그는 DNS나 NIS 쿼리에 어떠한 영향도 미치지 않는다. |
| nospoof |
지난 장에서 설명하였듯, DNS는 in-addr.arpa 도메인을 사용하여
IP 주소에 속한 호스트네임을 찾을 수 있도록 한다. 네임서버에 의해 이루어지는,
잘못된 호스트네임을 공급하기 위한 시도를 "spoofing"이라 한다. 이를 막기
위해서, resolver는 얻어진 호스트 네임에 진짜 IP 주소가 실제로 연관되는지를
검사하도록 설정될 수 있다. 만약 연관되지 않았다면 네임은 거부되고 에러가
리턴된다. 이러한 작용은 nospoof on으로 세팅하였을 때 효력을 발휘한다. |
| alert |
이 옵션은 인자로 on 또는 off를 받는다. 만약 on 상태라면
spoof에 대한 시도 (위를 보라)가 있을 때 resolver가 syslog에 로그를
남기게 한다. |
| trim |
이 옵션은 인자로 검색전에 호스트네임에서 제거되는 도메인네임을 받는다.
이는 hosts 엔트리에서, 로컬 도메인 없이 호스트네임을 지정하고자 할 때
유용하다. 로컬도메인이 뒤에 붙어있는 호스트를 검색할 때 이를 제거하여,
/etc/hosts내의 검색이 성공하게 한다.
trim 옵션이 축적되면, 당신의 호스트가 몇몇 도메인을 로컬처럼 간주하도록 한다.
|
아래는 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.
6.1.2 Resolver Environment Variable
몇몇 환결변수를 사용하여 host.conf의 세팅을 오버라이드 할 수 있는데,
이 환경변수들은,
| RESOLV_HOST_CONF |
|
이는 /etc/host.conf대신에 읽어들일 파일을 지정한다. |
| RESOLV_SERV_ORDER |
|
host.conf의 order 옵션을 오버라이드한다. 서비스는 host,
bind, 그리고 nis가 공백이나 콤마, 또는 세미콜론으로 나뉘어 주어진다. |
| RESOLV_SPOOF_CHECK |
|
spoofing에 대한 대처수준을 결정한다. off로 완전히 무력화할 수 있다.
warn과 warn off값은 각기 logging을 하고 하지 않고이나, spoof 체크는
양쪽 모두 한다. * 값은 host.conf에 정의된 것과 같이 logging도 한다. |
| RESOLV_MULTI |
host.conf의 multi 옵션을 오버라이드 할 수 있으며, on
또는 off의 값을 받는다. |
| RESOLV_OVERRIDE_TRIM_DOMAINS |
|
trim 도메인의 목록을 지정하며, host.conf의 내용을 오버라이드한다.
| RESOLV_ADD_TRIM_DOMAINS |
|
trim 도메인의 목록을 지정하며, 이는 host.conf의 내용에 추가된다.
|
6.1.3 Configuring Name Server Lookups - resolv.conf
호스트 검색에 BIND 네임 서비스를 사용하도록 resolver 라이브러리를 설정하고자
할 때, 어떤 네임서버를 사용할 것인지를 말해줘야 한다. 이를 위한 별도의
파일이 resolv.conf이다. 만약 이 파일이 존재하지 않거나 비어 있으면,
resolver는 로컬 호스트에 네임서버가 있다고 간주한다.
만약, 로컬 호스트에 네임서버를 돌린다면, 다음 절에서의 설명에 따라 별도로
셋업해줘야 한다. 만약 로컬 네트웍상에서 현존하는 네임서버를 사용하고자 한다면,
resolv.conf에서 설정해 줘야 한다.
resolv.conf에서 가장 중요한 옵션은 nameserver이며, 이는 사용할
네임서버의 IP 주소를 지정한다. 여러개의 네임서버를 사용하려면, nameserver
옵션을 여러번 주면되고, 그 순서에따라 시도한다. 그러므로 가장 신뢰성있는 서버를
처음에 주어야 한다. 현재 3개까지의 네임서버가 지원된다.
만약 nameserver 옵션이 주어지지 않는다면, resolver는 로컬 호스트의
네임서버에 연결을 시도한다.
다른 두 옵션, domain과 search는, BIND가 첫번째 쿼리로 도메인을
resolve하지 못할때 호스트네임에 붙는 디폴트 도메인과 연관되어 있다. search옵션은
시도할 도메인네임의 목록을 지정하며, 그 목록은 공백또는 탭으로 구분된다.
만약 search 옵션이 주어지지 않는다면, 로컬 도메인네임 자체와 root까지의
모든 상위 도메인으로 default search list를 만든다. 로컬 도메인네임은 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을 resolve할때, resolver는 vale을 검색하여
이에 실패하면 vale.vbrew.com, 그리고 vale.com을 검색한다.
6.1.4 Resolver Robustness
만약 좀 더 큰 규모내에서 LAN을 운영하고자 할 때, 분명히 당신은 가능하다면
중앙네임서버를 사용할 것이다. 이것이 지니는 장점은 모든 쿼리가 그것에
포워드 됨으로 인해 풍부한 캐쉬를 가질 수 있는 것이다. 그러나 이 체계에는
한가지 결점이 있다. 최근 우리 대학에서 화재로 backbone 케이블이 탄 적이 있는데,
resolver가 어떠한 네임서버에도 도달할 수 없으므로 있해 학과의 LAN에서의
어떠한 X 터미널 상의 로그인이나 프린팅과 같은 작업이 불가능했다.
물론 화재로 campus backbone이 나가버리는 일이 일상적인 것은 아니지만, 이와 같은
경우에 대한 예방책을 알아두는 것도 좋은 일이다.
한가지 방법은, 로컬 도메인에서의 호스트네임을 resolve하고 다른 호스트 네임에 대한
쿼리는 중앙서버에 포워드 하는 것이다. 물론 이것은 당신이 자체 도메인을 따로
운영할 경우에 한하는 일이다.
다른 방법은, /etc/hosts내에 당신의 도메인 또는 LAN의 백업 호스트 테이블을
가지고 있고, /etc/host.conf에 "order bind hosts"를 넣어두어
중앙 네임서버가 다운되었을 때, resolver가 hosts 파일을 찾도록 하는 것이다.
6.2 Running named
대부분의 UN*X 메신에서 도메인네임 서비스를 제공하는 프로그램은
named (네임-디라고 발음한다.)라 한다. 이것은 원래 BSD에서 클라이언트와, 가능하다면
다른 네임서버에 네임서비스를 제공하기 위해 개발된 서버 프로그램이다. 현재 대부분의 리눅스
설치에 사용되는 버전은 BIND-4.8.3 정도이며, 새 버전 BIND-4.9.3은 베타 테스트되고
있으며, 곧 리눅스에서 활용될 것이다.
이 절은 Domain Name System의 동작에 대한 약간의 이해를 요한다. 만약 다음에서
논하는 것이 마치 그리스어를 보는듯 하다면, 다시한번 2장을 읽어보기 바란다.
거기엔 DNS의 기본에대한 정보가 있다.
named는 보통 시스템 부팅시에 구동되며 머신이 셧다운될 때 까지 돌아간다.
그것은 /etc/named.boot라는 설정파일과, 도메인 네임을 주소로 매핑하는 것같은
데이터를 포함한 여러 파일에서 정보를 얻는다. 후자는 zone file이라 불린다.
이러한 파일의 포맷과 의미에관해선 다음의 절에서 설명할 것이다.
named를 돌리려면, 프롬프트에서 단순히 다음을 입력하라.
# /usr/sbin/named
그러면 named가 뜨며, named.boot 파일과 zone 파일에 지정된 사항을
읽을 것이다. 그것은 /var/run/named.pid에 ASCII로 프로세스 id를 적고,
필요하다면 주 서버에서 zone 파일들을 다운로드하며, 포트 53에서 DNS 쿼리를
listening하기 시작한다.
6.2.1 The named.boot Files
named.boot 파일은 아주 작고, zone 정보를 포함하는 마스터파일과, 다른
네임서버에의 포인터만을 가진다. boot 파일에서의 주석문은 세미콜론에서 시작해서
뉴라인까지이다. 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 리소스 레코드(RR)문자로 표기되어 있다.
이 예제에서 named는 파일의 끝에서 primary 선언문으로 지시된 것처럼
세개의 도메인에대한 메인 주 네임서버로 설정되었다. 예를 들어, 이들 중 첫번째
라인은 named.hosts 파일에서 zone 데이터를 얻어, vbrew.com의
주 서버로 동작할 것을 지시한다. directory 키워드는 모든 zone 파일이
/var/named 내에 위치함을 알린다.
cache 엔트리는 매우 특별하고, 사실상 네임서버를 돌리는 모든 머신에
존재한다. 그것의 기능은 두 가지로, named가 캐쉬를 사용하게끔 지시하며,
지정된 캐쉬파일(이 예제에서는 named.ca)에서 root name server hints를
읽어들이도록 한다. 네임 서버 힌트에 대해선 나중에 또다시 살펴볼 것이다.
다음은 named.boot에서 사용할 수 있는 가장 중요한 옵션들의 목록이다.
| directory |
zone 파일이 존재하는 디렉토리를 지정한다. 파일명은 이 디렉토리에대해
상대적인 경로로 주어진다. directory를 반복적으로 사용함으로써 여러
디렉토리를 지정할 수 있으나, 리눅스 파일시스템 표준에 따른 디렉토리는 /var/named이다. |
| primary |
이것은 domain name과 file name을 인자로
받으며,이는 로컬 서버가, 명시된 도메인에 권한을 갖고 있음을 선언한다. 주 서버로서
named는 주어진 마스터파일에서 zone 정보를 읽어들인다. |
| secondary |
이 선언문은 인자로 domain name, address list, file name를
받는다. 이는 로컬서버가 지정된 도메인의 2차 마스터 서버임을 선언한다.
2차 서버 역시, 도메인에 대한 권한 데이터를 지니고 있으나, 그것을 파일에서 얻어내는 대신에 주 서버로부터
다운로드한다. 그러므로 named에 제공되는 주소 리스트엔 주 서버의 IP 주소가
적어도 하나이상은 있어야한다. 로컬 서버는 zone 데이터베이스를 성공적으로 전송받들때까지
그들 각각에 차례로 접촉하여 세번째 인자로 준 백업 파일에 저장한다. 만약
어떠한 주 서버도 응답하지 않을땐, 백업파일에서 zone 데이터를 얻는다.
named는 정기적인 주기로 zone 데이터 갱신을 시도한다.
이는 차후에 SOA 리소스 레코드 타입과 연결하여 설명할 것이다. |
| cache |
이는 domain과 file name을 인자로 받는다.
이 파일엔, root 네임서버를 가리키는 레코드의 리스트인 root server hints가
포함되어 있다. 단지 NS와 A 레코드만을 인식할 수 있다. domain인자는
일반적으로 root 도메인네임인 "."이다.
이 정보는 named에 있어서 절대적으로 중요한 것이다. 즉, cache구문이
boot 파일에 들어있지 않을 경우, named는 로컬 캐쉬를 전혀 확장시킬 수 없다.
이는 다음번에 쿼리된 서버가 로컬 넷에 있지 않을 경우, 퍼포먼스를 떨어뜨리고 네트웍 로드를
증가시킨다. 게다가 named는 어떠한 root 네임 서버에도 도달할 수 없을 뿐더러,
그것이 인증하는 것 외의 어떠한 주소도 resolve할 수 없다. 이에 대한 한가지 예외는
포워딩 서버(아래의 forwaredrs 옵션을 참고하라)를 사용할 때이다. |
| forwarders |
이는 address list를 인자로 받으며, 이 리스트 내의 IP 주소는
named가 로컬 캐쉬에서 쿼리를 resolve할 수 없을 때 쿼리할 네임서버의 리스트이다.
그들 중 하나가 쿼리에 응답할 때 까지 차례로 시도된다. |
| slave |
이 구문은 네임서버를 slave 서버로 만든다. 즉, 그 서버 자체는
반복질의(recursive query)를 수행하지 못하고 forwarders 선언문으로
지정된 서버로 쿼리를 포워드 시키기만 한다. |
여기에 적지않은 두개의 옵션이 더 존재하는데, 그것은 sortlist와 domain이다.
또한 zone 데이터베이스 파일에 사용할 수도 있는 두개의 지정자(directive)도 존재하며,
그들은 각각 $INCLUDE와 $ORIGIN이다. 그러나 이들이 거의 사용되지 않는
이유로 여기에 그것들을 적진 않을 것이다.
6.2.2 The DNS Database Files
named에 include되는 named.hosts와 같은 마스터 파일은 항상 origin이라
부르는 것과 연관된 도메인을 갖고 있으며, 이는 cache와 primary 커맨드로
지정된 도메인네임이다. 마스터 파일내에선 이 도메인에 관련된 도메인네임과 호스트네임을
지정할 수 있다. 설정파일에서 점으로 끝나는 이름은 절대적인 것으로
갖주되고, 그렇지 않은 경우는 origin에 상대적인 것으로 간주된다. origin자체는
"@"이라 지칭된다.
마스터 파일내의 모든 데이터는 리소스 레코드(RR)로 나뉜다. 그것들은 DNS를 통해 이용할 수 있는 정보의 최소
단위를 만든다. 리소스 레코드엔 각각의 타입이 있는데, 예를 들어 A 레코드는 호스트 네임을 IP 주소로
매핑하며, CNAME 레코드는 호스트에 대한 앨리어스를 공식적인 이름에 연관시킨다.
일례로, Virtual Brewery의 named.hosts 마스터 파일을 보여주는 그림 6.3을 보라.
마스터 파일 내에 표시된 리소스 레코드들은 공통으로 일반적 포맷을 따르는데,
그것은
[domain] [tt1] [class] type rdata
각 필드는 스페이스나 탭으로 나뉜다. 첫번째 뉴라인 캐릭터 전에 중괄호 열기
문자를 적고, 마지막 필드 다음에 중괄호 닫기 문자를 쓴다면, 여러라인에 걸쳐
하나의 엔트리를 적을 수 있다. 세미콜론과 뉴라인 사이의 어떠한 것도 무시된다.
| domain |
이는 엔트리가 적용되는 도메인네임을 정한다. 만약 도메인네임이
주어지지 않는다면 RR은 지난번 RR의 도메인에 적용된다고 간주한다. |
| ttl |
일정 시간 후에 resolver가 정보를 파기하도록 강제하기 위해, 각 RR은
"time to live", 짧게는 ttl라는 것에 관련되어 있다. ttl 필드는
정보가 서버로부터 얻어진 이후로부터 유효한 기간을 초단위로 지정한다. 이는 최대
10진수 8자리까지를 받을 수 있다. |
| class |
이는 IP 주소의 IN, 또는 Hesiod 클래스 내의 객체를 위한 HS와 같은 주소
클래스이다. TCP/IP 네트워킹을 위해선, 이를 IN으로 만들어 줘야한다.
만약 class 필드가 주어지지 않는다면, 먼저번 RR의 클래스라 가정된다. |
| type |
이는 RR의 타입을 기술한다. 가장 보편적인 타입은 A,SOA,PTR,NS이다.
다음절에서 다양한 RR 타입에 관해 다룰 것이다. |
| rdata |
이는 RR과 연관된 데이터를 갖고 있다. 이 필드의 포맷은 RR의 타입에의해
좌우된다. 각 RR에 대해선 아래에서 개별적으로 다루고 있다. |
다음은 DNS 마스터 파일에서 사용되는 RR의 목록이다. 우리가 여기서 설명하지 않는 것도 있는데,
그것들은 시험적인 것이고, 또한 보통의 경우 거의 사용하지 않는 것들이다.
| SOA |
이것은 권한의 영역을 기술하며(SOA는 "Start of Authority"를 의미한다),
SOA RR 다음의 레코드는 그 도메인데 해한 권한정보를 포함한다는 신호를 보낸다.
primary 선언문으로 include된 모든 마스터 파일은 반드시 그 zone에 대한
SOA 레코드를 포함해야 한다. 리소스 데이터는 다음의 필드를 지닌다. |
|
origin |
이것은 이 도메인을 위한 주 네임서버의 canonical 호스트네임이다. |
| contact |
이것은 그 도메인을 관리하는 책임자의 email 주소로, '@'자는 점으로 대신한다.
예를 들어, Virtual Brewery의 책임자가 janet이라면, 이 필드는
janet.vbrew.com이 될 것이다. |
| serial |
이것은 단일 10진수로 표현된 zone 파일의 버전 번호이다. zone 파일의
내용이 변경될 때마다 이 숫자는 증가할 것이다.
시리얼 넘버는 zone 정보가 변경되었을 때, 2차 네임서버가 인식할 수 있게 하기 위해 사용된다.
정보를 최근의 것으로 유지하기 위해, 2차 서버는 일정 간격을 두고 주 서버의
SOA 레코드를 요청하여, 그것의 시리얼 넘버와 캐쉬된 SOA레코드의 그것을 비교한다.
만약 번호가 변경되어 있다면, 2차 서버는 주 서버로부터 전체 zone 데이터베이스를 전송받는다. |
| refresh |
이것은 2차 서버가 주 서버의 SOA 레코드를 체크하는 간격을 초단위로 지정하는 것이다.
이것 역시 최대 10진수 8자리를 쓸수 있다.
일반적으로, 네트웍 토폴로지라는 것이 자주 변경되는 것이 아니기 때문에,
대규모의 네트웍에선 대략 하루정도로, 그리고 소규모에서는 그보다 더 지정해
주어야 한다. |
| retry |
이 숫자는 2차 서버가 주 서버에 요청하거나 zone을 갱신하는 것에 실패했을 때
다시 주 서버에로의 접촉을 재시도하는 간격을 지정하는 것이다. 그것은 너무
낮게 지정되지 않아야만 하는데, 그렇지 않을 경우 일시적인 접촉 실패나
네트웍 문제가 2차서버의 네트웍 자원 낭비를 유발할 수 있다. 한시간 또는
반시간 정도가 좋은 선택일 것이다. |
| expire |
이것은 주 서버에 접촉하지 못할때 서버가 모든 zone 데이터를 파기하는 시간을
초단위로 지정하는 것이다. 보통, 이는 매우 큰 수로 잡아 주어야 하는데,
Craig Hunt ([Hunt92])는 42일의 값을 권장한다. |
| minimum |
이는 명시적으로 하나의 ttl을 지정하지 않은 리소스 레코드들의 기본 ttl 값이다.
이는 2차서버가 zone 정보의 업데이트를 시도한 후의 시간에 개의치 않고,
일정시간이 지나면 다른 네임서버들도 그 RR을 파기하길 요청한다.
minimum은 큰 값이어야하며, 특히 네트웍 토폴로지가 거의
변경되지 않는 LAN의 경우 더 그렇다. 한 주나 한 달의 값이 아마도 좋을 것이다.
그리고 단일 RR만이 자주 변경되는 경우는 그것에 다른 ttl의 값을 지정해 주면 된다. |
| A |
이는 IP 주소를 호스트네임에 연결시킨다. 리소스 데이터 필드엔
dotted quad notation으로 적힌 주소가 들어간다. |
| NS |
이는 종속 zone의 마스터 네임서버를 가리킨다. 왜 NS 레코드를 가진 것이 있어야만 하는가에대한
설명을 원한다면 section 2.6을 보라. 호스트네임을 resolve하기 위해선 추가적인
A 레코드도 필요한데, 흔히 glue record라 불리는 것으로, 네임서버의
IP 주소를 넘겨준다. |
| CNAME |
이것은 호스트의 앨리어스(alias)를 그것의 canonical 호스트네임에
연결시킨다. canonical 호스트네임은 마스터 파일이 제공하는 A 레코드이다.
앨리어스는 단순히 그 이름에 CNAME으로 링크시킬 뿐이며, 그외에 자신의 레코드를
가지고 있지 않다. |
| PTR |
in-addr.arpa 도메인내의 네임을 호스트네임과 연관시키는데
쓰이는 레코드 타입이다. 이는 IP 주소를 호스트네임으로 역매핑하는데 사용된다.
주어지는 호스트네임은 반드시 canonical 호스트네임이어야 한다. |
| MX |
이 RR은 한 도메인을 위한 mail exchanger를 알린다.
mail exchanger를 가지는 이유는 3장내의 Mail Routing on the Internet 섹션에서
논의한다. MX 레코드의 문법은,
[domain] [ttl] [class] MX preference host
host는 domain의 mail exchanger를 명시한다.
모든 mail exchanger는 그것과 연관된 integer preference를
가지고 있다. domain으로 메일을 배달하길 원하는 MTA(Mail
Transport Agent)는 이 도메인에서 MX 레코드를 가진 모든 호스트에, 성공할 때까지
시도하는데, 가장 낮은 preference 값을 가진 것을 먼저 시도하며, 다른 것들은
preference 값의 증가에 따라 시도된다. |
| MX |
이 레코드는 시스템의 하드웨어와 소프트웨어 정보를 제공한다.
문법은
[domain] [ttl] [class] HINFO hardware software
hostname 필드는 이 호스트가 사용하는 하드웨어 정보를
판별한다. 이를 지정하는데 특수한 편의가 제공되는데, 유효한 이름의 리스트는
"Assigned Numbers" (RFC 1340)에서 주어진다. 만약 필드가 공백을 갖고 있다면,
그것은 반드시 따옴표로 싸여있어야 한다. software 필드는
시스템에 사용되는 운영 체제를 명시한다. 이 또한 "Assigned Numbers" RFC에서
적절한 이름을 골라야 한다. |
6.2.3 Writing the Master Files
그림 6.2, 6.3, 6.4, 6.5는 vlager에 위치한 brewery 네임서버의
샘플파일을 보여준다. 논의된 네트웍의 (단일 LAN) 특성덕에, 이 예제는 꽤
직선적이다. 만약 더 복잡한 것을 요하거나 named가 어떻게 돌아가는지
잘 모르겠다면, Cricket Liu와 Paul Albitz의 "DNS and BIND"([AlbitzLiu92])를
구해 보기바란다.
그림 6.2의 named.ca 캐쉬파일은 root 네임서버를 위한 샘플 hint 레코드를
보여준다. 보편적인 캐쉬파일은 10여개의 네임서버를 거론하는데, root 도메인에대한
현재 네임서버 목록은, 이 장의 말미에서 논할 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 파일
;
; /var/named/named.hosts Local hosts at the brewery
; Origin is vbrew.com
;
@ IN SOA vlager.vbrew.com. (
janet.vbrew.com.
16 ; serial
86400 ; refresh: once per day
3600 ; retry: one hour
3600000 ; expire: 42 days
604800 ; minimum: 1 week
)
IN NS vlager.vbrew.com.
;
; local mail is distributed on vlager
IN MX 10 vlager
;
; loopback address
localhost. IN A 127.0.0.1
; brewery Ethernet
vlager IN A 191.72.1.1
vlager-if1 IN CNAME vlager
; vlager is also news server
news IN CNAME vlager
vstout IN A 191.72.1.2
vale IN A 191.72.1.3
; winery Ethernet
vlager-if2 IN A 191.72.2.1
vbardolino IN A 191.72.2.2
vchianti IN A 191.72.2.3
vbeaujolais IN A 191.72.2.4
그림 6.3: named.host 파일
;
; /var/named/named.local Reverse mapping of 127.0.0
; Origin is 0.0.127.in-addr.arpa.
;
@ IN SOA vlager.vbrew.com. (
joe.vbrew.com.
1 ; serial
360000 ; refresh: 100 hrs
3600 ; retry: one hour
3600000 ; expire: 42 days
360000 ; minimum: 100 hrs
)
IN NS vlager.vbrew.com.
1 IN PTR localhost.
그림 6.4 : named.local 파일
;
; /var/named/named.rev Reverse mapping of our IP addresses
; Origin is 72.191.in-addr.arpa.
;
@ IN SOA vlager.vbrew.com. (
joe.vbrew.com.
16 ; serial
86400 ; refresh: once per day
3600 ; retry: one hour
3600000 ; expire: 42 days
604800 ; minimum: 1 week
)
IN NS vlager.vbrew.com.
; brewery
1.1 IN PTR vlager.vbrew.com.
2.1 IN PTR vstout.vbrew.com.
3.1 IN PTR vale.vbrew.com.
; winery
1.2 IN PTR vlager-if1.vbrew.com.
2.2 IN PTR vbardolino.vbrew.com.
3.2 IN PTR vchianti.vbrew.com.
4.2 IN PTR vbeaujolais.vbrew.com.
그림 6.5 : named.rev 파일
6.2.4 Verifying the Name Server Setup
당신의 네임서버 셋업이 제대로 작동하는지 검사하기 위한 좋은 툴이 있는데,
그것을 가리켜 nslookup이라한다. 그것은 인터랙티브하게, 또는 커맨드라인에서
사용될 수 있는데, 후자의 경우 다음처럼 단순히
nslookup hostname
이라하면 된다. 그러면 그것은 resolv.conf에 지정된 네임서버에
hostname에 대한 쿼리를 보낸다(만약, 이 파일에 여러개의
서버가 있다면 nslookup은 랜덤으로 하나를 선택한다).
그러나 인터랙티브 모드는 이보다 더 흥미 진진하다. 호스트를 검색하는 것 외에,
어떠한 DNS 레코드 타입에 대하여서도 질의할 수 있고, 도메인의 전반적인
zone 정보를 전송할 수도 있다.
인자 없이 실행되면, nslookup은 사용하는 네임서버를 표시하고
인터팩티브 모드로 들어간다. '>'프롬프트에서, 질의할 도메인 네임을
쳐넣으면, 그것은 디폴트로 도메인네임에 연관된 IP 주소를 담고 있는
클래스 A 레코드를 요청한다.
"set type=type"을 이용하여 이 타입을 바꿀수도 있는데,
type은 섹션 6.2에서 거론한 리소스 레코드 네임중의 하나이거나,
ANY이다.
예를들어, 다음과 같은 다이얼로그를 접할 수도 있다:
$ 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 레코드 등에 대해서도 질의할 수 있다. ANY 타입을 사용하면 주어진 네임에
관련된 모든 리소스 레코드를 돌려줄 것이다.
> 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
디버깅외에도, named.ca 파일에 대한 모든 현재의 root 서버의 목록을 얻을때
nslookup을 쓸모있게 응용할 수 있다. 이를 위해 당신이 할 일은 단지 root 도메인에
연관된 모든 타입의 NS 레코드를 질의하는 것이다.
> 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커맨드를
사용하여 얻을 수 있다.
6.2.5 Other Useful Tools
BIND 관리자와 같은, 당신의 업무를 도와줄 몇개의 툴이 존재하는데, 여기선 간략히 두가지만
설명하겠다. 이러한 툴을 어떻게 사용하는지에 관한 정보는 그것에 딸려오는 문서를 참고하자.
hostcvt는 당신의 /etc/hosts 파일을 named의 마스터파일로 변환하여
당신의 BIND설정을 초기화해줌으로써 당신을 돕는 툴이다. 그것은 forward (A)와 reverse mapping (PTR) 엔트리를
모두 만들어내고, 앨리어스 같은 것에 주의를 쏟는다. 물론 그것이 당신의 모든 작업, 이를테면
SOA 레코드의 타임아웃 값을 조절하거나, MX 레코드를 추가하는 것 같은 일을 해줄 순 없고,
당신 직접해야 하지만, 그것은 골치아픈 일을 줄일 수 있게 해 준다. hostcvt는
BIND 소스의 일부이지만, 몇몇 리눅스 FTP 서버에서 독립적인 패키지로서도 구할 수 있다.
당신의 네임서버를 셋업한 후엔, 설정사항을 테스트 해보고 싶을 것이다. 이를위한 이상적인(그리고 내가 알고 있는) 툴은
오직 dnswalk 뿐으로, 이것은 보편적인 실수를 찾아내고, 정보가 일관된 것인지를 검증하기 위해
DNS 데이터베이스를 돌아다니는 perl기반 패키지이다. dnswalk는 최근
comp.source.misc에서 릴리즈 되고 있으며, 이 그룹을 보관하는 모든 FTP 사이트에서
구할 수 있을 것이다(당신 근처에 그런 사이트가 없다면 ftp.uu.net에서 찾으면 된다).
|