Skip to content

2008.12.14 14:19

bind zone파일 세부설명

조회 수 11776 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
모든 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 업체에 문의해 보기 바란다.


List of Articles
번호 제목 글쓴이 날짜 조회 수
29 Web서버 / FTP서버 무료관리 프로그램 [ 웹깨비 ] ADMINPLAY 2008.11.10 10395
28 무료DNS [ DNS 에버 ] ADMINPLAY 2008.11.10 10200
27 Anti DNS Cache Poisioning ADMINPLAY 2008.12.14 10820
» bind zone파일 세부설명 ADMINPLAY 2008.12.14 11776
25 대표 ISP 업체별 네임서버 ADMINPLAY 2008.12.14 13393
24 자체 네임서버 - 초간단 ADMINPLAY 2008.12.28 15878
23 BIND 9.3.x 외부에서 질의 안될때 ADMINPLAY 2009.01.05 14229
22 DNS 서버 구성하기 - 세부설명포함 ADMINPLAY 2009.03.17 16245
21 네임서버 업데이트 주기는? ADMINPLAY 2009.03.17 16426
20 인버스 도메인 신청,위임 및 서브도메인 위임 ADMINPLAY 2009.03.29 17767
19 DNS TCP53, UDP53 용도 ADMINPLAY 2009.06.04 18579
18 네임서버 named.conf 파일과 zone파일 체크 방법 ADMINPLAY 2009.07.31 17909
17 'could not set file modification time' 와 같은 오류 메... file ADMINPLAY 2009.10.20 19839
16 CentOS5,Fedora7 네임서버 설정법 file ADMINPLAY 2009.10.31 18756
15 bind 세부로그 남기기- named.conf logging설정 예제 ADMINPLAY 2009.10.31 23541
14 DNS 개념을 위한 상식용어 ADMINPLAY 2009.11.04 30185
13 서브도메인 유출 방지방법 ADMINPLAY 2009.11.11 19081
12 lame server resoving ADMINPLAY 2009.12.08 17491
11 DNS 의 Cache Poisoning 취약점 ADMINPLAY 2009.12.08 21060
10 DNS 싱크홀 (악성 봇 감염) file ADMINPLAY 2009.12.08 23601
Board Pagination Prev 1 2 Next
/ 2

Copyright ADMINPLAY corp. All rights reserved.

abcXYZ, 세종대왕,1234

abcXYZ, 세종대왕,1234