named
2011. 12. 22. 02:34ㆍ개발/서버
1. named.conf 문법
1.1 options 구문
optons 은 말 그대로 네임서버의 옵션을 설정하기 위한 구문이다.
optoins 구분은 "options" 라는 키워드로 시작해서 " { " 와 " }; " 안에 옵션을 정의하면 된다.
수십가지의 옵션들이 존재하는데 여기에서는 많이 사용하는 몇가지 옵션만 살펴볼 것이다.
options {
옵션들;
};
directory "/var/named" ;
네임서버에서 기본적으로 참조하는 zone , hint , reserv zone 등이 위치할 디렉토리를 설정해 주는 곳인데 기본값인
"/var/named"를 사용하도록 하자.
forward first ; (or only ;)
이 네임서버로 오는 질의를 특정 호스트로 포워딩 한다. forwaders와 같이 사용해야 된다.
forward first ; 는 네임서버로 들어오는 질의를 forwarders 로 지정한 외부 서버에서 먼저 처리하고 적절한 해답을 찾지 못할 경우 로컬에서 처리를 한다.
forward olny ; 는 네임서버로 들어오는 질의를 forwaders 로 지정한 외부서에서만 해결한다.
forwaders { IP_Address1; IP_ Address2 ; ..... }
forward 를 처리할 외부 서버의 IP_Address 를 정의한다.
1.2 zone 구문
zone 구문의 작성 형식은 다음과 같은 형식을 사용해야 된다. ' | ' 는 or 을 뜻한다.
zone " Domain " IN {
type [ hint ; | master ; | slave ; ]
file "File_name" ;
allow-update { none ; | maching IP ; };
추가 옵션들....
};
zone
zone 구문의 시작은 zone 이라는 키워드로 시작해야 된다.
" Domain "
정의할 Domain을 적는 부분이다.
IN
Internet DNS 설정일 때 사용한다. 내부에서만 사용하는 네임서버가 아닐경우 모두 IN으로 설정한다.
IN은 생략가능한데 bind 9 부터는 엄격한 문법을 지켜야 되기 때문에 설정해 주는 것이 좋다.
type
네임서버의 타입을 설정하는데 master, slave, hint 를 설정할 수 있다.
hint : 루트 도메인( . ) 정의할 때 사용한다.
master : 1차 네임서버를 정의할 때 사용한다.
slave : 2차 네임 서버를 정의할 때 사용한다.
file
해당 도메인의 zone 파일 이름을 정의한다.
type이 hint일 경우 /var/named 에 named.ca 라는 이름으로 루트 도메인의 zone 파일에 해당하는 hint 파일이 제공
되기 때문에 named.ca 파일을 지정하면 된다.
allow-update { none; };
다이나믹 업데이트를 사용할 때 매칭될 IP 주소를 적으면 되는데 특별한 경우가 아니라면 none; 이외의 설정을 사용할
기회가 없을 것이다.
2. named.conf
zone "." IN {
type hint;
file "named.ca";
};
루트 도메인 ( . )에 대한 zone 구문이고 루트 도메인의 type은 오직 hint만 가능하다.
루트 도에인 ( . )의 zone 파일 즉 hint 파일의 이름을 named.ca 로 지정했다.
named.ca 파일은 bind를 rpm으로 설치할 경우 /var/named에 기본적으로 생성된다.
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
locahost에 대한 zone 구문이고 type은 master로 설정되어 있다. localhost의 type을 slave로 설정할 경우는 없을 것이다.
localhost의 zone 파일을 localhost.zone 으로 지정했는데 이 파일 역시 bind를 rpm으로 설치 했을 경우 /var/named에 생성
된다. 당연히 다이나믹 업데이이트는 허용하지 않고 있다.
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
localhost의 Inverse Domain을 설정하는 zone 구문이다. 이 설정은 named.conf에 기본적으로 설정되어 있다.
localhost의 inverse Domain의 zone 파일을 named.local로 지정해 주었다. 이 파일 역시 rpm으로 bind를 설치 했을 경우 /var/named 디렉토리에 생성된다.
zone "rootman.co.kr" IN {
type master;
file "rootman.zone";
allow-update { none; };
};
도메인 rootman.co.kr 의 zone 구문으로 type master; 설정으로 1차 네임서버임을 정의했다.
zone 파일의 이름은 "rootman.zone"으로 명시했고 다이나믹 업데이트를 허용하지 않고 있다.
zone "205.241.203.in-addr.arpa" IN {
type master;
file "rootman.rev"
allow-update { none; };
};
--> 추가 설명)
zone "hosting1.co.kr" IN {
type master;
file "hosting1.zone";
allow-update { none; };
};
호스팅 중인 도메인을 하나씩 위의 작업대로 반복한다.
80개의 도메인을 호스팅 중이라면 80번 해당 도메인에 대한 zone을 설정해준다.
Inverse Domain에 대한 zone 구문 설정이다. 이 부부은 Inverse Domain을 보유하고 있는 분들만 설정하면 된다.
자신이 Inverse Domain을 보유하고 있는지 잘 모르겠으면 IP 주소를 할당 해준 ISP 업체에 문의해 보기 바란다.
Inverse Domain은 rootman.co.kr과 같은 Domain을 할당 받을 때 부여 받는 것이 아니라 IP 주소를 부여 받을 때 ISP업체로 부터 할당 받는 것이다.
Inverse Domain 설정시 가장 주의해야 될 부분은 Inverse Domain을 작성하는 형식이다.
203.241.205.1 ~ 255의 C 클래스 IP주소를 설정할 Inverse Domain은 IP주로의 네트 워크 부분인 203.241.205를 역으로 적고뒤에 in-addr.arpa를 붙여서 적어 주면 된다. 즉 IP 주소 203.241.205.97 의 Inverse Domain은205.241.203.in-addr.arpa 가 되는 것이다.
named.conf에서의 작성 형식은 다른 zone 파일과 동일하다.
Inverse Domain에 대한 자세한 설명은 "reverse zone 파일 설정하기" 를 참고하고 named.conf에서는 위의 형식을 지켜서
작성하자.
==========================2) /var/OOO.zone 설정=======================================
zone 파일은 네임서버 설정시 가장 중요한 도메인 데이터 베이스 파일이고 네임서버 가동시에 zone 파일을 읽어 들여서 네임서버 서비스가 가동된다. zone 파일은 도메인을 IP 주소로 변환해 주는 역할을 한다.
1 . zone파일 작성시 주의 사항(필독)
@(origin)의 역활
@는 named.conf에서 zone "rootman.co.kr" 로 지정해준 rootman.co.kr. 을 의미한다.
zone 파일 설정시 루트 도메인 ( . ) 의 중요성.
흔히 우리가 사용하는 도메인 주소는 aaa.com , bbb.co.kr 과 같이 끝에 루트도메인( . )을 사용하지 않는다.
하지만 aaa.com 과 bbb.com 의 정확한 도메인 주소는 aaa.com. , bbb.co.kr. 과 같이 표기할 수 있다.
루트 도메인( . )은 최상위 도메인을 의미하는데 즉 .com .net .org 등의 상위 도메인이다.
도메인을 이용해서 특정 호스트로 접속할 때 특별히 루트 도메인( . )까지 표기 하지 않아도 접속할 수 있다.
하지만 네임서버 설정시 zone파일을 작성할 때는 꼭 최상위 도메인을 붙인 완전한 도메인 주소를 사용해야 된다.
예들 들어 ns1.rootman.co.kr 이라는 주소를 표기 할 때는 꼭 제일 끝에 루트 도메인( . )을 붙여 줘야 된다.
만약 루트 도메인( . )을 붙이지 않으면 그 도메인을 완전한 도메인으로 인식하지 않기 때문에 그 도메인 두에 @에 해당하는 도메인을 덧 붙여주게 된다. 즉 루트 도메인으로 마무리 되지 않은 도메인은 @(origin)의 호스트로 인식하는 것이다.
ns1.rootman.co.kr -> ns1.rootman.co.kr.rootman.co.kr
위와 같이 "ns1.rootman.co.kr " 은 "ns1.rootman.co.kr.rootman.co.kr"로 작성한 것과 같은 영향을 미친다.
뒤에 추가된 rootman.co.kr은 @ 에 해당하는 도메인이다.
이런 이유 때문에 linux.rootman.co.kr 이라는 서브 도메인을 zone 파일에서 설정할 때 "linux" 만 적어도
"linux.rootman.co.kr." 을 적은 것과 같은 결과를 얻게 된다.
$TTL 43200
bind 9 의 zone파일 설정시 주의 해야 될 것은 꼭 zone파일의 첫줄에 TTL 값을 설정해야 된다는 것이다.
bind 9 이전 버젼에서는 TTL 값을 지정하지 않으면 네임서버 가동시에 default값으로 자동 설정 되었는데 bind 9에서는
꼭 zone파일의 첫줄에 꼭 설정해야 된다.
TTL은 다른 네임서버를 제어 하는 부분인데 특정 네임 서버가 rootman.co.kr의 네임 서버에 www.rootman.co.kr을 질의하고 그 정보를 가져 간 후 그 정보를 보유하고 있을 시간을 지정해 주는 것이다.
한가지 예로 어떤 사용자가 한국 통신의 DNS(168.126.63.1)를 이용해서 rootman.co.kr을 접속할 경우 한국 통신의 DNS는 rootman.co.kr의 네임 서버에 rootman.co.kr의 IP를 물어 보고 사용자에게 정보를 준 후 그 정보를 자신도 보관한다.
rootman.co.kr의 정보를 가지고 있는 한국 통신 DNS는 다음 부터 rootman.co.kr에 대해 사용자가 물어 보면 그 때부터는 보관된 정보를 이용해서 사용자에게 알려주는 것이다. 바로 이 TTL값이 한국 통신 DNS가 한번 퍼 간 정보를 얼마 동안 보관할 것인가를 결정한다.
자주 올라오는 질문 중에 네임 서버의 zone파일을 수정했는데 계속 전에 설정했던 값으로 적용된다고 질문을 하시는 분이 많은데 바로 그 이유도 클라이언트에서 이용하는 DNS가 아직 수정 전에 설정했던 값을 보관 하고 있어서 새로운 정보를 해당 네임 서버에서 퍼올 때 까지 이전의 설정값을 사용자에게 알려 주기 때문이다.
자주 네임 서버 수정을 하는 시스템에서는 이 값을 줄여서 사용하면 되는데 너무 작은 값을 설정하면 너무 자주 네임서버에
질의 해 오기 때문에 네임 서버에 과부하가 걸릴 수 있다.
2 . zone 파일 설정 형식
host_name [TTL] class record_type data
--->> zone 파일의 모든 행은 위의 형식을 따른다.
host_name
설정하고 싶은 호스트 네임을 지정해 주면 된다. 꼭 호스트 네임 설정시 루트 도메인( . )에 대해 주의를 하세요.
host_name이 생략된 행은 바로 윗 행의 host_name 설정을 적용 받는다.
TTL
zone파일의 첫행에 default값을 지정했기 때문에 생략 가능한다. ($TTL 43200)
루트맨의 zone 파일 설정에는 모두 생략되어 있다.
class
IN은 internet 클래스를 가리키는데 저도 IN 이외에 다른것을 설정해서 사용한 적이 없습니다.
record_type
레코드 유형
역활
SOA
zone 파일의 시작을 알리고 전체 영역에 영향을 미치는 파라미터를 정의한다.
NS
네임서버를 지정한다.
A
호스트 이름을 IP 주소로 매핑할 때 사용한다. 즉 A 레코드의 data는 IP 주소를 설정해야 된다.
PTM
IP 주소를 호스트 이름으로 매핑할 때 사용한다. PTR 레코드는 reverse zone파일 설정에 사용된다.
MX
메일 포워딩 개념으로 메일을 MX 레코드로 지정한 호스트로 포워딩한다.
CNAME
호스트의 alias(엘리어스)를 정의한다.
HINFO
호스트 정보를 표시하는 레코드
data
각 레코드 타입에 해당하는 데이타를 설정하면 된다.
3 . 각 레코드 별 data 설정
::SOA 레코드의 data 설정
모든 zone파일은 SOA 레코드로 zone파일의 시작을 알린다.
꼭 다음과 같은 형식을 지켜야 된다.
@ IN SOA ns1.rootman.co.kr. yunil.rootman.co.kr. (
20010504 ; serial
10800 ; refresh
3600 ; retry
3600000 ; expire
43200 ) ; mininum
SOA 레코드의 data 부분은 여러개의 요소로 구성된다. 각 data 부분의 설명은 다음과 같다.
ns1.rootman.co.kr.
1차 네임 서버를 정의하고 있다.
yunil.rootman.co.kr.
관리자 메일 주소를 정의하고 있다. @는 zone파일에서 특별한 의미를 갖고 있기 때문에 yunil@rootman.co.kr.을
yunil.rootman.co.kr. 로 표기 해야 된다.
주의 : bind 9 (bind 8.2.3 이후) 부터는 SOA 레코드의 2차 네임 서버와 관련된 data 설정을 시작하는 여는 괄호 " ( " 는
꼭 SOA 레코드의 첫행의 마지막에 위치 해야 된다. 다른 곳에 위치 할 겨우 bind 9에서 error을 발생시킬 수 있다.
20010504 ; serial
zone 파일의 버젼을 의미한다. 보통 zone파일을 수정하거나 생성한 날을 숫자로 설정한다.
2차 네임 서버는 정기적으로 1차 네임 서버의 이 값을 확인하고 2차 네임 서버의 사본을 나타내는 일련 번호보다 크면
1차 네임 서버로 부터 zone파일을 전송해서 2차 네임 서버 정보를 갱신한다.
즉 1차 네임 서버의 정보가 갱신 되었는지를 2차 네임 서버는 이 값을 통해서 확인한다.
10800 ; refresh
2차 네임 서버가 1차 네임 서버의 갱신 내용을 확인하기 위해 주기적으로 체크하는 시간을 초(s)로 설정한다.
3600 ; retry
2차 네임 서버가 refresh값에 의해 1차 네임 서버로 접속시도 때 1차 서버의 문제가 접속을 못한 경우 다시 접속 시도할
시간을 설정한다. (예 : 1차 네임 서버의 정전, 네트웍 과부하 등)
3600000 ; expire
2차 네임 서버가 1차 네임 서버의 정보를 얼마나 오랫동안 신임 할 것인가를 설정한다.
만약 1차 네임 서버가 오랫동안 다운 된다거나 시스템 파괴로 인해 2차 네임 서버가 1차 네임 서버에 접속할 수 없을 때
전에 백어 받아온 1차 네임 서버 정보를 이 값이 초과 할때 까지 신임한다.
루트맨의 설정은 1000일(3년)동안 1차 네임 서버가 소식이 없더라도 그 전에 백업 받아온 파일로 2차 네임서버를 운영하라는것이다. 보통 한달 정도를 설정해서 쓴다.
즉 위의 설정값이 초과하면 2차 네임 서버는 자신이 가지고 있는 1차 네임 서버 정보를 파기한다.
루트맨이 3년으로 설정한 것은 저의 특이한 성격 때문에 설정한 값으로 말도 않되는 값이기 때문에 따라 하는 사람이 없기를 바란다.. 저처럼 특이한 성격의 소유자라면 상관 없지만.
43200 ; mininum
TTL 값 설정 부분이다. TTL 설명을 참고
::NS 레코드의 데이타 설정
NS 레코드는 해당 호스트의 네임서버 호스트를 지정하는 레코드이다.
루트맨의 네임 서버 호스트는 ns1.rootman.co.kr. 이다.
rootman.co.kr. IN NS ns1.rootman.co.kr
::HINFO 레코드의 데이타 설정
HINFO 레코드는 시스템의 정보를 제공하기 위해 사용하느 레코드이다.
rootman.co.kr. IN HINFO "Inter Pentium" "RedHat"
HINFO 레코드의 데이터 부분인 문자열은 사용자 마음대로 설정하면 된다.
::A 레코드의 데이터 설정
A 레코드는 host_name의 IP 주소를 지정하는 레코드이다.
linux.rootman.co.kr. IN A 203.241.205.91
rootman.co.kr의 서브 도메인인 linux.rootman.co.kr의 IP 주소를 203.241.205.91로 지정했다.
A 레코드로 하나의 호스트에 대해서 여러개의 IP 주소를 지정할 수도 있다.
예를 들어 호스트 linux.rootoman.co.kr 에 대해 zone 파일에서 A 레코드로 203.241.205.91 과 203.241.205.92 로 설정했을 경우 클라이언트에서 linux.rootman.co.kr 로 접근 시도할 때 클라이언트는 IP 주소 203.241.205.91 과 203.241.205.92 를 랜덤으로 접속하게 된다. 즉 사용자가 상황에 따라 203.241.205.91에 접속될 수도 있고 203.241.205.92에 접속될 수도 있다.
이러한 설정은 방문자수가 많은 웹 사이트에서 부하를 줄이기 위해 종종 사용하는 방법이다.
실예로 www.daum.net은 총 14개의 IP로 랜덤하게 접근하도록 설정되어 있다.
::MX 레코드의 데어터 설정
MX 레코드는 Mail Exchange 설정을 해준다.
host_name에 해당하는 주소로 오는 메일을 다른 호스트로 exchange 한다.
실제로는 이 설정만으로는 Mail Exchange를 완벽하게 할 수 없다.
실제 메일이 들어오는 서버를 큐잉 서버로 만들어야 되고 MX 레코드에 의해 설정된 메일의 최종 도착지에서는 메일 수신
자를 설정해야 되는데 이에 대한 자세한 설명은 sendmail 강좌중에 독립 메일 서버 만들기를 참고하기를 바란다.
host_name에 해당하는 IP 주소와 Mail Exchange 될 호스트의 IP 주소가 같을 경우 이 설정을 사용하지 않도록 한다.
가끔 쓸데없이 같은 IP 주소에 mail 호스트를 설정하고 MX 레코드로 지정해 주는 분들이 있는데 이런 설정은 시스템에
아무런 도움도 주지 못한다. zone 파일을 최대한 줄일수 있는것이 시스템 리소스를 절약하는 방법이다.
::CNAME 레코드의 데이터 설정
CNAME 레코드는 host_name에 대한 alias 기능을 한다.
linux.rootman.co.kr. IN A 203.241.205.91
ftp.rootman.co.kr. IN CNAME linux.rootman.co.kr.
위의 경우는 linux.rootman.co.kr. 이라는 호스트에 A 레코드를 이용하여 IP 주소 203.241.205.91을 설정하고ftp.rootman.co.kr은 A 레코드가 아닌 CNAME 레코드로 linux.rootman.co.kr로 alias 설정을 한 것이다.
쉽게 생각하면 ftp.rootman.co.kr을 linux.rootman.co.kr에 링크를 시켰다고 생각하면 된다.
물론 CNAME 레코드 부분을 A 레코드로 바꾸고 IP 주소를 지정해도 똑같은 효과를 줄 수 있다.
제가 많은 네임서버를 수정해 주면서 느낀 것인데 Inverse Domain을 보유하고 있지 않으면서도 Inverse Domain을 설정하고reserve zone 파일을 설정한 경우를 많이 보았다. 이유를 물어 보니 남들이 설정하니까 설정했다고 말하는 사람이 대부분이었다. 항상 얘기하는 것이지만 네임 서버 뿐만이 아니라 리눅스에서의 모든 설정들은 남들이 설정한 것을 그냥 아무 생각없이 따라 하면 절대 리눅스에 대해서 깊이 알지 못할 것이다.
왜 그런 설정들이 필요한 것인지 .. 또 이런 설정들이 본인의 시스템에 필요한 것인지를 알고 설정했으면 한다. 제가 바로 설명을 시작하지 않고 이런 얘기를 따분하게 늘어 놓는 이유는 네임서버를 설정함에 있어서 Inverse Domain을 운영할 권한이
없는 시스템에서 Inverse Domain을 설정한 경우를 너무 많이 보았고 지금도 제 글을 읽고 바로 이해하지 못하고 쓸데없이 시스템에 Inverse Domain에 대한 설정을 하는 분들이 분명히 있을 것이기 때문이다.
루트맨을 이용하는 방문자들만은 리눅스를 운영함에 있어서 올바른 이해를 가지고 서버를 운영했으면 하는 바램이다.
물론 저도 아직까지 실수 투성이 운영자이다.
Reverse Mapping이란 무엇인가?
우리가 흔히 생각하는 네임서버는 Forward Zone 기능을 하는 네임서버를 말한다. 즉 도메인을 IP 주소로 변경해 주는 네임 서버를 말하는데 Reverse Zone은 Forward Zone과 반대로 IP 주소를 도메인으로 변경하는 역활을 한다.
특정 도메인을 운영할 목적으로 네임서버를 설정할 때 Reverse Mapping에 대한 설정 부분은 필수 조건은 아니다. 분명히 말해서 도메인의 소유권과 Inverse Domain과는 아무런 상관이 없다. Inverse Domain은 도메인을 신청할 때 받는 것이 아니라
ISP로 부터 IP주소를 부여 받을 때 같이 부여 받는 것이다. 학교에서 아이피를 부여 받아 사용하는 사용자는 학교 전산실에서 관리하는 C클래스 주소에 대한 Inverse Domain을 보유하고 설정하기 때문에 reverse zone을 설정할 필요가 없다.
ISP 업체로 부터 몇개의 도메인을 부여받아 사용하는 경우에도 대부분 reverse zone을 설정할 필요가 없지만 ISP 업체에 문의해 보기 바란다.
우선 다음의 경우를 보자. 필자의 시스템에서 한국통신 DNS를 이용해 IP 주소 203.241.205.97을 nslookup한 결과와 루트맨의 네임서버를 이용해서 질의한 결과이다. 먼저 한국 통신 DNS인 168.126.63.1의 결과부터 보도록 하자.
(참고로 203.241.205.97은 rootman.co.kr의 IP 주소로 루트맨의 웹서버가 운영중이다.)
nslookup의 결과는 흥미롭게도 dvc.dongeui.ac.kr이라는 결과를 resolve(풀이)했다. dvc.dongeui.ac.kr은 제가 속한 동아리 홈페이지 주소이다.
그럼 이 결과는 도데체 어디서 resolve(풀이)한 것이길래 dvc.dongeui.ac.kr 이라는 도메인을 결과로 보여 줄까?
rootman.co.kr 네임서버의 reverse zone에 IP 주소 203.241.205.97을 dvc.dongeui.ac.kr로 설정해서 나온것일까?
루트맨의 서버를 운영하고 있는 본인은 전혀 루트맨의 서버에 이러한 설정을 한 적이 없다. 정확히 말한면 인터넷에서 적용될 수 있는 reserver znoe을 설정할 수 있는 권한이 본인에게는 없다.
즉 IP주소 203.241.205.97이 속한 Inverse Domain(205.241.203.in-addr.arpa)을 가지고 있지 않다. 다만 내가 할 수 있는 것은 localhost에서만 적용될 수 reverse mapping을 만들고 설정할 수 있다. 이 얘기들이 뜻하는 것은 IP 주소 203.241.205.91를 reverse mapping 할수 있는 Inverse Domain을 다른 시스템에서 관리하고 있으며 그 시스템의 reverse zone 파일에서 IP 주소 203.241.205.97을 dvc.dongeui.ac.kr 로 정의해 놓았기 때문이다. 그렇기 때문에 rootman.co.kr의 네임서버에서 IP 주소 203.241.205.97을 rootman.co.kr 로 reverse mapping 해도 localhost의 네임 서버를 이용해서 질의 할 때만 적용되지 인터넷을 통해 ns1.rootman.co.kr이 아닌 다른 DNS에 질의를 하면 dvc.dongeui.ac.kr 이라는 결과만 볼수 있는 것이다. 한마디로 Inverse Domain을 보유하고 있지 않은 상태에서 아무리 reverse mapping을 설정해도 인터넷의 사용자들은 dvc.dongeui.ac.kr 으로 resolve(풀이)된 결과만 볼수 있는 것이다. 회사내에 네트워크를 구축해서 회사내에서만 통용되는 도메인을 만들어서 사용하는 것과 같은 이치이다.
그럼 이제부터 Inverse Domain을 보유하고 계신 분들만 이 설정을 하도록 하자. 공부 차원에서 localhost에서만 적용되는 것이라도 설정해 보고 싶으신 분들도 환영한다.
reverse zone 파일 설정은 PTR 레코드를 사용하는 것 빼고는 forward zone 파일 설정과 동일하다.
reserver zone에서도 forward zone에서와 마찬가지로 @(origin)의 의미은 named.conf의 해당 zone 구문에서 설정해준 Domain 부분을 의미한다. 즉 rootman의 named.conf에서는 Inverse Domain의 zone 구문에서 Domain을 205.241.203.in-addr.arpa로
설정했기 때문에 @(origin)은 205.241.203.in-addr.arpa 라는 의미를 가지게 되는 것이다.
PTR 레코드 부분을 제외한 나머지는 forward zone 파일 설정과 동일하다. PTR 레크드의 데이터 부분만 제대로 설정해 주면 된다.
예를 들어 IP 주소 203.241.205.97을 설정하기 위해서는 97.205.241.203.in-addr.arpa 라고 설정해야 된다.
그럼 NS 레코드 까지는 forward zone 파일과 작성형식이 같으니까 나머지 부분에 대해 설명하겠다.
forward zone 파일에서는 A 레코드가 가장 핵심이었다면 reserve zone 파일에서는 PTR 레코드가 가장 중요한다.
PTR 레코드 사용 방법만 안다면 별 무리없이 설정할 수 있을 것이다.
::reverse zone 설정 형식
[Inverse Domain] [TTL(생략가능)] [IN(class)] PTR Host_Name
91 IN PTR linux.rootman.co.kr.
97 IN PTR rootman.co.kr.
forward zone 파일에서와 마찬가지로 완벽한 호스트 네임을 설정해야 된다. 즉 도메인의 끝은 꼭 ( . )루트 도메인으로
마무리 해 줘야 된다. 루트 도메인(.)으로 마무리 하지 않은 도메인은 뒤에 @(origin)에 해당하는 도메인이 덧 붙여 진다.
다음의 두 설정은 같은 효과를 가진다.
91 IN PTR linux.rootman.co.kr.
91.205.241.203.in-addr.arpa. IN PTR linux.rootman.co.kr.
그리고 간혹 하나의 아이피에 물려있는 모든 호스트를 PTR 레코드로 적어주는 경우가 있는데 별 필요없는 설정이다.
예를 들어 IP 주소 203.241.205.91에 linux.rootman.co.kr 과 yunil.rootman.co.kr이 물려있다면 대표로 사용할 하나의
도메인만 설정해 주면 된다. 어차피 여러개를 설정해 봤자 reserve zone에서는 랜덤으로 하나를 선택해서 표시해 주기 때문
에 어떻게 보면 혼란을 야기시킬 수도 있다. 많이 설정해 봤자 랜덤으로 표시하기 때문에 쓸데없는 노가다는 하지 않길
바란다.
'개발 > 서버' 카테고리의 다른 글
| sysstat 를 이용하여 시스템 모니터링 하기 (0) | 2012.02.05 |
|---|---|
| lsof (0) | 2012.01.19 |
| Crontab을 이용한 ftp 파일 자동 전송받기 (0) | 2011.12.21 |
| VSFTP (1) | 2011.12.21 |
| 네트워크 상태 보기! - TCP View 편 (1) (0) | 2011.12.18 |