DNS HOWTO
이전다음

5. 간단한 도메인

도메인 구축 방법.

5.1. 5.1 우선은 상투적인 이론부터

우선적으로 이전에 다른 여러 관련서적을 읽고 숙지했는가? 그래야만한다.

이 장을 시작하기 전에 DNS가 구동되는 약간의 이론에 대해 설명하기로 한다. 그리고 이 장을읽는것이 좋다. 읽기 싫으면 적어도 named.conf가 나오기 전까지 속독이라도 하라.

DNS는 tree구조로 되있는 계층구조이다. 일반적인 tree데이터-구조에서 상위는 '.' 으로 되어 있고 이것은 'root'로 다시 불리워 진다. '.' 아래에는 수많은 최상위 도메인들이 있다(TLDs:Top Level Domains);가장 잘 알려진 것은 ORG, COM, EDU, NET 등이 있다. 나무처럼 뿌리(root)도 있고 가지(branch)도 있다고 생각하자. 컴퓨터과학에 대한 지식이 있다면 DNS를 tree부분, 마디, 잎마디, 봉우리로 인식하게 될 것이다. 점(.)이 분기점이고 봉우리가 이름들이다.

질의는 root로 부터 시작되는 구조에 대해서 순환적으로 진행된다. prep.ai.mit.edu. 이라는 주소를 찾으려 한다면 네임서버는 어딘가에 질의를 할것이다. 우선은 캐쉬에서부터 질의를 한다. 캐쉬가 답을 가지고 있고 답변이 오게 된다면 바로 전 장에서와 같은 결과를 보게 될 것이다.여기에서 답이 나오지 않으면 이름이 시작되는 왼쪽부터 지워 나가게 된다. ai.mit.edu. 그리고는 mit.edu. 또 그리고 edu.를 네임서버가 알고 있는지 확인하고, 모른다면. 에게 질의를 하게 된다. . 은 hints파일을 가르키기 때문이다. 그러면 . 서버들은 prep.ai.mit.edu 에 대해 질의를 하게 되며, prep.ai.mit.edu 서버가 답을 모르더라도 다른 곳 어디를 찾아야 할지를 당신의 서버에 알려주고, 찾아간 곳에서 질의에 대한 답을 얻게 된다. 이러한 것을 이제 보여줄 것이다. dig에서 +norec는 비순환적인 질의를 보내서 우리에게 돌아온 값만을 얻게 된다.이 옵션은 dig 과정을 줄이고 페이지 수를 줄일것이다. (질의 보내고 다시 질의를 찾는 식의 순환이 아니라 질의 한번에 결과 한번을 보여준다는 의미로 이해됩니다.^^;)

$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu.
;; res options: init defnam dnsrch
;; got answer:
; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; AUTHORITY SECTION:
.                       5d23h48m47s IN NS  I.ROOT-SERVERS.NET.
.                       5d23h48m47s IN NS  E.ROOT-SERVERS.NET.
.                       5d23h48m47s IN NS  D.ROOT-SERVERS.NET.
.                       5d23h48m47s IN NS  A.ROOT-SERVERS.NET.
.                       5d23h48m47s IN NS  H.ROOT-SERVERS.NET.
.                       5d23h48m47s IN NS  C.ROOT-SERVERS.NET.
.                       5d23h48m47s IN NS  G.ROOT-SERVERS.NET.
.                       5d23h48m47s IN NS  F.ROOT-SERVERS.NET.
.                       5d23h48m47s IN NS  B.ROOT-SERVERS.NET.
.                       5d23h48m47s IN NS  J.ROOT-SERVERS.NET.
.                       5d23h48m47s IN NS  K.ROOT-SERVERS.NET.
.                       5d23h48m47s IN NS  L.ROOT-SERVERS.NET.
.                       5d23h48m47s IN NS  M.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
I.ROOT-SERVERS.NET.     6d23h48m47s IN A  192.36.148.17
E.ROOT-SERVERS.NET.     6d23h48m47s IN A  192.203.230.10
D.ROOT-SERVERS.NET.     6d23h48m47s IN A  128.8.10.90
A.ROOT-SERVERS.NET.     6d23h48m47s IN A  198.41.0.4
H.ROOT-SERVERS.NET.     6d23h48m47s IN A  128.63.2.53
C.ROOT-SERVERS.NET.     6d23h48m47s IN A  192.33.4.12
G.ROOT-SERVERS.NET.     6d23h48m47s IN A  192.112.36.4
F.ROOT-SERVERS.NET.     6d23h48m47s IN A  192.5.5.241
B.ROOT-SERVERS.NET.     6d23h48m47s IN A  128.9.0.107
J.ROOT-SERVERS.NET.     6d23h48m47s IN A  198.41.0.10
K.ROOT-SERVERS.NET.     6d23h48m47s IN A  193.0.14.129
L.ROOT-SERVERS.NET.     6d23h48m47s IN A  198.32.64.12
M.ROOT-SERVERS.NET.     6d23h48m47s IN A  202.12.27.33

가이드라인만(referral) 들어왔다. 우리에게 "AUTHORITY SECTION(인증 섹션)"만을 주고 "Answer Section(응답섹션)"은 주지 않았다. 우리 네임서버가 하나의 네임서버를 선택할 것이다. 아무거나 집어보자.(추천된 서버중 하나를 집어내서 다시 질의를 보내자는 이야기겠져...)

$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu. @H.ROOT-SERVERS.NET.
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; AUTHORITY SECTION:
MIT.EDU.                2D IN NS        BITSY.MIT.EDU.
MIT.EDU.                2D IN NS        STRAWB.MIT.EDU.
MIT.EDU.                2D IN NS        W20NS.MIT.EDU.

;; ADDITIONAL SECTION:
BITSY.MIT.EDU.          2D IN A         18.72.0.3
STRAWB.MIT.EDU.         2D IN A         18.71.0.151
W20NS.MIT.EDU.          2D IN A         18.70.0.160

이제 우리에게 MIT.EDU를 선택할 수 있다. 다시 하나 집어내 보자.

$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu. @bitsy.mit.edu
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; ANSWER SECTION:
prep.ai.mit.edu.        3h50m7s IN A    198.186.203.18

;; AUTHORITY SECTION:
AI.MIT.EDU.             6H IN NS        FEDEX.AI.MIT.EDU.
AI.MIT.EDU.             6H IN NS        LIFE.AI.MIT.EDU.
AI.MIT.EDU.             6H IN NS        ALPHA-BITS.AI.MIT.EDU.
AI.MIT.EDU.             6H IN NS        BEET-CHEX.AI.MIT.EDU.

;; ADDITIONAL SECTION:
FEDEX.AI.MIT.EDU.       6H IN A         192.148.252.43
LIFE.AI.MIT.EDU.        6H IN A         128.52.32.80
ALPHA-BITS.AI.MIT.EDU.  6H IN A         128.52.32.5
BEET-CHEX.AI.MIT.EDU.   6H IN A         128.52.32.22

이제 "Answer Section"을 얻었고, 우리는 질의에 대한 답을 얻게 되었다. "AUTHORITY SECTION"은 어느 서버에 ai.mit.edu를 다음에 물어야 하는 지에 대한 정보를 가지고 있다. 그래서 바로 다음에 ai.mit.edu를 물어볼 수 있게 된다.

. 에서부터 출발해서 우리는 각 도메인 네임의 레벨에서 네임서버를 성공적으로 발견해 내었다. 다른 서버를 사용하지 않고 여러분의 DNS서버를 사용했다면 당연히 그 정보를 캐쉬에 저장해 둘 것이고 당분간은 다시 묻지 않을 것이다.

이 트리구조에서 이름안에 있는 "." 들은 분기점이다. 그리고 "."점들 사이의 부분은 이 트리구조에서 개별적으로 분기되는 부분이다. 우리가 원하는 이름을 (prep.ai.mit.edu) 찾기 위해서 트리구조를 보면 우선 캐쉬에 있는 정보나 아니면 뿌리(.)에게 어느 서버가 prep.ai.mit.edu로 가는 시작점(원본은 father라는 동사를 씁니다.원류... 근원...)인지를 물어본다. 캐쉬에 정보가 없으면 밖으로 나가서 그 이름에 대한 좀더 가까운 힌트(referral,지정된 서버라고 번역되는데 힌트가 더 적당할 수 있겠습니다.)를 얻기 위해 재귀적으로 계속해서 서버들에게 질문을 하게 된다.

자주 이야기 되지는 않지만 중요한 도메인이 in-addr.arpa 이다. '일반'도메인과 유사하다. in-addr.arpa는 우리가 주소를 알고 있을 경우에 그 이름을 알려준다. 숙지해야 할 중요한 부분은 ip 주소가 in-addr.arpa 도메인에서는 거꾸로 사용된다는 것이다. 만약에 주소 192.148.52.43을 알고 있다고 하자. 그러면 prep.ai.mit.edu 예에서 했던 것과 같은 식으로 진행이 된다. 먼저 arpa. 서버를 찾고 in-addr.arpa. 서버를 찾게된다. 그리고 나서 192.in-addr.arpa. 로, 148.192.in-addr.arpa. 로, 52.148.192.in-addr.arpa. 서버로 해서 43.52.148.192.in-addr.arpa.서버를 찾게된다. 영리하지 않은가? (그렇다고 대답하라고 원문은 강요도 한다.-.-) 숫자를 뒤집어 놓은 것이 다소간은 혼란스러울 것이다.)

5.2. 자신의 도메인

이제 우리 도메인을 정의해 보자. 우리는 linux.bogus라는 도메인을 가지고 우리 서버에 만들어 놓을 것이다. 나는 이러한 것이 외부로 실제 나가지 않게 가짜 도메인 이름을 쓸 것이다.

시작전에 하나 알아둬야 한다. 모든 문자가 다 도메인이 되는 것은 아니다. 제한적으로 영어 알파벳이 쓰인다.: a-z, 0-9, 그리고 '-'(대쉬)가 사용된다. 대소문자는 구별이 없다는 점도 알아 두기를. 그래서 pat.uio.no 는 Pat.UiO.No 와 같이 쓰인다.

우리는 이미 named.conf에서 이 부분을 했었다.:

zone "0.0.127.in-addr.arpa" {
	type master;
	file "pz/127.0.0";
};

이 파일에서는 도메인 네임의 마지막에 '.'이 없다는 사실을 주의해라. 이 부분은 우리가 0.0.127.in-addr.arpa 존에 대한 정의이고 마스터 서버에 대한 정의가 있으며 pz/127.0.0이라는 파일 안에 저장이 된다. 우리는 이미 이 파일을 세팅했다. 보면...

$TTL 3D
@               IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
				1       ; Serial
				8H	; Refresh
				2H      ; Retry
				4W	; Expire
				1D)	; Minimum TTL
			NS      ns.linux.bogus.
1			PTR	localhost.

위의 named.conf와는 다르게 이 파일안에 있는 모든 도메인명의 마지막에는 '.'이 있다는 사실을 알아두길 바란다. 어떤 이들은 모든 존 파일을 $ORIGIN으로 시작하기도 하는데 이것은 불필요한 것이다. 도메인 계층안에 포함되어 있는 이 존 파일들의 근원지는 이미 named.conf에서 다 명시가 되어 있기 때문이다. 이 경우에는 0.0.127.in-addr.arpa 이다.

이 'zone' 파일은 3개의 '자원레코드(RR:Resource Records)'를 가지고 있다. SOA, NS, PTR이다. SOA는 Start Of Authority의 약어이다. @는 원본을 의미하는 것으로 이것은 'domain'컬럼에서 0.0.127.in-addr.arpa를의미하는 것이다.

0.0.127.in-addr.arpa.	IN	SOA ...

NS는 NameServer의 약자이다. 시작부분에 '@'가 없다. 이미 앞 라인이 @로 시작되면서 @가 내제되어있다. 타이핑 수를 줄여라. 그래서 NS라인은 이렇게 쓰여진다.

0.0.127.in-addr.arpa.	IN	NS	ns.linux.bogus

이것은 DNS에게 어떤 컴퓨터가 도메인 0.0.127.in-addr.arpa의 nameserver인지 알려주게 된다. 여기서는 ns.linux.bogus이다. 'ns'는 보편적으로 nameserver에 붙는 말이다. 그러나 웹서버의 이름이 일반적으로 www.something 이듯이 다른 이름을 주어도 무방하다.

그리고 마지막으로 PTR(Domain Name Pointer)레코드는 서브넷 0.0.127.in-addr.arpa의 호스트 어드레스가 1 임을 이야기 한다. 즉 127.0.0.1의 이름이 localhost이다.

SOA 레코드는 모든 zone 파일의 서두에 해당되며 각 존 파일마다 반드시 하나씩 있어야 한다. 이것은 그 zone 파일이 무엇이라 불리는지(여기서는 ns.linux.bogus라 불린다.), 누가 이 contents를 관리하는지(hostmaster@linux.bogus; email주소를 필히 넣어야 한다), 이 존 파일의 버젼이 무엇인지(serial:1), 캐시서버와 2차 DNS서버는 무엇인지 등을 기재하게 된다. 나머지 필드(refresh, retry,expire,minimum)은 HOWTO 에 기술된 것으로 해라. 이것이 안정적일 것이다. SOA 라인이 쓰여지기 전에 $TTL 3D란 것을 위에 기재하길 바란다. 이것은 모든 zone file에 넣어야 한다.

이제 named 를 재구동시켜보자.(ndc restart) 그리고 dig명령어로 질의를 해 보자(옵션 -x)

$ dig -x 127.0.0.1

; <<>> DiG 8.2 <<>> -x 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;;      1.0.0.127.in-addr.arpa, type = ANY, class = IN

;; ANSWER SECTION:
1.0.0.127.in-addr.arpa.  1D IN PTR  localhost.

;; AUTHORITY SECTION:
0.0.127.in-addr.arpa.   1D IN NS        ns.penguin.bv.

;; Total query time: 5 msec
;; FROM: lookfar to SERVER: default -- 127.0.0.1
;; WHEN: Sat Dec 16 01:13:48 2000
;; MSG SIZE  sent: 40  rcvd: 110

위에서 127.0.0.1에서 localhost를 찾는데 성공했다. 이제 주요 작업인 linux.bogus 도메인을 만들어 보자. named.conf의 'zone'섹션에 추가하라

zone "linux.bogus" {
	notify no;
	type master;
	file "pz/linux.bogus";
};

named.conf 파일의 도메인 이름에는 '.'이 없다는 것을 다시한번 상기하자.

linux.bogus의 존파일에는 전부 가짜 데이터를 넣을 것이다.

;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@	IN	SOA	ns.linux.bogus. hostmaster.linux.bogus. (
			199802151	; serial, todays date + todays serial #
			8H		; refresh, seconds
			2H		; retry, seconds
			4W		; expire, seconds
			1D )		; minimum, seconds
;
		NS	ns		; Inet Address of name server
		MX	10 mail.linux.bogus	; Primary Mail Exchanger
		MX	20 mail.friend.bogus.	; Secondary Mail Exchanger
;
localhost	A	127.0.0.1
ns		A	192.168.196.2
mail		A	192.168.196.4

SOA 레코드 부분에서 2가지 부분을 주의해서 보자. ns.linux.bogus는 A 레코드를 가진 실제 컴퓨터여야 한다. SOA레코드가 이야기하는 컴퓨터의 이름을 CNAME으로 하는 것은 규정에 어긋난다. 이 이름에 'ns'가 들어갈 필요는 없으며 아무 이름이라도 규정에만 어긋나지 않으면 된다. 다음으로 hostmaster.linux.bogus 는 hostmaster@linux.bogus로 봐야 한다. 이것은 mail alias나 mailbox로서, DNS관리자가 이 주소로 메일을 받게 될 것이다. 이름이 꼭 hostmaster일 필요는 없다. 일반 메일주소를 넣어도 되지만 'hostmaster' 인 것이 효율적일 것이다.

MX라는 새로운 레코드가 보인다. 이것은 Mail eXchanger로 메일 시스템에게 어디로 메일을 보내는지 알려준다. mail.linux.bogus 혹은 mail.friend.bogus로 인해 주소는 someone@linux.bogus가 된다. 각 computer이름앞의 숫자는 MX레코드의 우선 순위를 나타낸다. 가장 낮은 숫자의 레코드(10)에 가능한 우선 순위가 주어진다. 이것이 실패할 경우 더 큰 숫자를 찾아서 가는에 여기에서는 20번의 mail.friend.bogus가 된다.

다시 ndc restart한 후 dig 결과를 살펴보자.

$ dig any linux.bogus +pfmin
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23499
;; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1
;; QUERY SECTION:
;;      linux.bogus, type = ANY, class = IN

;; ANSWER SECTION:
linux.bogus.            3D IN MX        10 mail.linux.bogus.linux.bogus.
linux.bogus.            3D IN MX        20 mail.friend.bogus.
linux.bogus.            3D IN NS        ns.linux.bogus.
linux.bogus.            3D IN SOA       ns.linux.bogus. hostmaster.linux.bogus. (
                                        199802151       ; serial
                                        8H              ; refresh
                                        2H              ; retry
                                        4W              ; expiry
                                        1D )            ; minimum

잘 보면 버그가 있다. 라인의

linux.bogus.            3D IN MX        10 mail.linux.bogus.linux.bogus.

가 잘못되었다.이것은

linux.bogus.            3D IN MX        10 mail.linux.bogus.

로 나와야 한다. 일부러 버그를 만들어서 보여줬다. 존 파일 부분에서 우리가 찾아낸 부분을 살펴보자

		MX	10 mail.linux.bogus	; Primary Mail Exchanger

마침표가 없거나 'linux.bogus'가 중복이 되어 있다. 끝부분에 마침표를 찍지 않으면 존파일의 origin이 더해져서 linux.bogus.linux.bogus형태가 된다. 그래서

		MX	10 mail.linux.bogus.	; Primary Mail Exchanger

이거나

		MX	10 mail			; Primary Mail Exchanger

의 형태로 되어야 한다. 나는 후자를 선호한다. 타이핑수를 줄이게 되니까. BIND 전문가들은 이러한 부분을 동의하기도 하고 반대하기도 한다. 존 파일에서 도메인은 끝이 `.'로 끝나던가 아니면 전부 포함되지 말아야 하며 전부 포함되지 않을 경우는 디폴트로 origin이 들어간다.

분명히 named.conf 파일에는 `.' 이 들어가지 않는다고 했다. `.'이 도메인 이름 다음에 얼마나 많게 혹은 적게 쓰이거나 하는 차이로 세팅이 안되고 사람들을 혼란스럽게 하는 일이 다반사이다.

그래서 새로운 존 파일의 생성시에는 그에 맞게 추가 정보가 주어져야 한다.

;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@	IN	SOA	ns.linux.bogus. hostmaster.linux.bogus. (
			199802151	; serial, todays date + todays serial #
			8H		; refresh, seconds
			2H		; retry, seconds
			4W		; expire, seconds
			1D )		; minimum, seconds
;
		TXT	"Linux.Bogus, your DNS consultants"
		NS	ns		; Inet Address of name server
		NS	ns.friend.bogus.
		MX	10 mail		; Primary Mail Exchanger
		MX	20 mail.friend.bogus. ; Secondary Mail Exchanger

localhost	A	127.0.0.1

gw		A	192.168.196.1
		HINFO	"Cisco" "IOS"
		TXT	"The router"

ns		A	192.168.196.2
		MX	10 mail
		MX	20 mail.friend.bogus.
		HINFO	"Pentium" "Linux 2.0"
www		CNAME	ns

donald		A	192.168.196.3
		MX	10 mail
		MX	20 mail.friend.bogus.
		HINFO	"i486"	"Linux 2.0"
		TXT	"DEK"

mail		A	192.168.196.4
		MX	10 mail
		MX	20 mail.friend.bogus.
		HINFO	"386sx" "Linux 1.2"

ftp		A	192.168.196.5
		MX	10 mail
		MX	20 mail.friend.bogus.
		HINFO	"P6" "Linux 2.1.86"

새로운 레코드가 보인다. HINFO(Host INFOmation)는 2개의 파트로 구성되어 있다. 첫째 부분은 하드웨어나 cpu부분, 둘째 부분은 소프트웨어나 OS를 표시한다. 'ns'라 불리는 컴퓨터는 펜티엄 cpu를 가지고 있고 Linux 2.0으로 구현된다. CNAME(Canonical Name)은 각 computer에게 여러 이름을 주는 방법이다. 그래서 www는 ns의 alias가 된다.

CNAME 레코드는 약간의 문제점이 있다. 그러나 규정대로만 하면 문제될 부분은 없다. MX,CNAME,SOA 레코드가 CNAME 레코드에 연계되어서는 안된다. 이것들은 A 레코드에만 연계되어야 하기 때문이다. 그래서 아래와 같은 경우는 안된다.(www가 이미 CNAME이다.)

foobar		CNAME	www			; NO!

그러나 이런 경우는 된다.

foobar		CNAME	ns			; Yes!

CNAME이 email 주소를 위한 hostname으로 쓰기에는 적합하지 않다고 여기는 것이 현명할 것이다. webmaster@www.linux.bogus는 위의 setup과 다른 잘못된 경우이다. 많은 mail 관리자들이 이것이 설령 되더라도 이 방식을 거의 사용하지 않을 것이다. 이러한 오류를 피하는 방식은 A 레코드를 사용하는 것이다.(다른 MX 레코드 처럼)

www		A	192.168.196.2

많은 DNS전문가들이 CNAME을 사용하지 않을 것을 권고한다. 그러나 사용가능 여부는 이 HOWTO에서 논할 부분은 아니다.

하지만 많은 HOWTO와 많은 싸이트들이 이 규칙을 따르지는 않는다.

새 database를 로딩하고 ndc reload를 실행해보자.

$ dig linux.bogus axfr

; <<>> DiG 8.2 <<>> linux.bogus axfr 
$ORIGIN linux.bogus.
@                       3D IN SOA       ns hostmaster (
                                        199802151       ; serial
                                        8H              ; refresh
                                        2H              ; retry
                                        4W              ; expiry
                                        1D )            ; minimum

                        3D IN NS        ns
                        3D IN NS        ns.friend.bogus.
                        3D IN MX        10 mail
                        3D IN MX        20 mail.friend.bogus.
                        3D IN TXT       "Linux.Bogus, your DNS consultants"
gw                      3D IN TXT       "The router"
                        3D IN HINFO     "Cisco" "IOS"
                        3D IN A         192.168.196.1
localhost               3D IN A         127.0.0.1
mail                    3D IN HINFO     "386sx" "Linux 1.2"
                        3D IN MX        10 mail
                        3D IN MX        20 mail.friend.bogus.
                        3D IN A         192.168.196.4
www                     3D IN CNAME     ns
donald                  3D IN TXT       "DEK"
                        3D IN HINFO     "i486" "Linux 2.0"
                        3D IN MX        10 mail
                        3D IN MX        20 mail.friend.bogus.
                        3D IN A         192.168.196.3
ns                      3D IN HINFO     "Pentium" "Linux 2.0"
                        3D IN MX        10 mail
                        3D IN MX        20 mail.friend.bogus.
                        3D IN A         192.168.196.2
ftp                     3D IN HINFO     "P6" "Linux 2.1.86"
                        3D IN MX        10 mail
                        3D IN MX        20 mail.friend.bogus.
                        3D IN A         192.168.196.5
@                       3D IN SOA       ns hostmaster (
                                        199802151       ; serial
                                        8H              ; refresh
                                        2H              ; retry
                                        4W              ; expiry
                                        1D )            ; minimum

;; Received 29 answers (29 records).
;; FROM: lookfar to SERVER: 127.0.0.1
;; WHEN: Sat Dec 16 01:35:05 2000

good! 결과가 존 파일과 비슷하게 보인다. www부분에 대한 정보를 확인해보자

$�ig www.linux.bogus +pfmin
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27345
;; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; QUERY SECTION:
;;      www.linux.bogus, type = A, class = IN

;; ANSWER SECTION:
www.linux.bogus.        3D IN CNAME     ns.linux.bogus.
ns.linux.bogus.         3D IN A         192.168.196.2

다시 보면 www.linux.bogus의 실제 이름은 ns.linux.bogus이다. 그리고 ns가 가진 정보도 보여주며 충분히 연결될 수 있다.

이제 절반 했다.

5.3. The reverse zone(역변환존)

프로그램들은 linux.bogus의 이름을 접속가능한 주소로 바꿔야 접속이 가능하다. 그러나 역변환존(reverse zone)이 있어야 DNS가 주소를 이름으로 바꾸는 것이 가능하다. 이러한 이름은 당신이 이 서비스를 사용할지 말지, 그리고 사용한다면 얼마만큼의 우선순위가 주어지는지등을 결정할 다양한 종류의 서버 이름들(FTP,IRC,WWW 그외)에서 사용된다. 인터넷에서 모든 서비스에 대한 완전한 접속을 위해서는 reverse zone이 필요하다.

named.conf에 추가해 보자

zone "196.168.192.in-addr.arpa" {
	notify no;
        type master;
        file "pz/192.168.196";
};

0.0.127.in-addr.arpa와 같다. 내용도 유사하다.

$TTL 3D
@	IN	SOA	ns.linux.bogus. hostmaster.linux.bogus. (
			199802151 ; Serial, todays date + todays serial
			8H	; Refresh
			2H      ; Retry
			4W	; Expire
			1D)	; Minimum TTL
		NS      ns.linux.bogus.

1		PTR	gw.linux.bogus.
2		PTR	ns.linux.bogus.
3		PTR	donald.linux.bogus.
4		PTR	mail.linux.bogus.
5		PTR	ftp.linux.bogus.

이제 named를 재구동시키고(ndc restart) dig로 다시 검사해 보자

$ dig -x 192.168.196.4 +pfmin
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8764
;; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUERY SECTION:
;;      4.196.168.192.in-addr.arpa, type = ANY, class = IN

;; ANSWER SECTION:
4.196.168.192.in-addr.arpa.  3D IN PTR  mail.linux.bogus.

괜찮아 보인다. 모든 부분을 검사해 보자

dig -x 192.168.196 AXFR

; <<>> DiG 8.2 <<>> -x AXFR 
$ORIGIN 196.168.192.in-addr.arpa.
@                       3D IN SOA       ns.linux.bogus. hostmaster.linux.bogus. (
                                        199802151       ; serial
                                        8H              ; refresh
                                        2H              ; retry
                                        4W              ; expiry
                                        1D )            ; minimum

                        3D IN NS        ns.linux.bogus.
4                       3D IN PTR       mail.linux.bogus.
2                       3D IN PTR       ns.linux.bogus.
5                       3D IN PTR       ftp.linux.bogus.
3                       3D IN PTR       donald.linux.bogus.
1                       3D IN PTR       gw.linux.bogus.
@                       3D IN SOA       ns.linux.bogus. hostmaster.linux.bogus. (
                                        199802151       ; serial
                                        8H              ; refresh
                                        2H              ; retry
                                        4W              ; expiry
                                        1D )            ; minimum

;; Received 8 answers (8 records).
;; FROM: lookfar to SERVER: 127.0.0.1
;; WHEN: Sat Dec 16 01:44:03 2000

잘 된다! 결과가 위와 같지 않으면 syslog의 에러 메시지를 봐라. 이미 첫부분의 Starting Named에서 설명해 놨다.

5.4. 주의사항

추가할 부분이 있다. 위에 명시된 IP 주소들은 전부 '사설망'에 국한된 예시이다. 이것은 일반 인터넷에는 적용되지 않는다. 그래서 안전하게 예시를 다룰 수 있다. 두번째 부분은 'notify no;'라는 부분이다. named가 존파일이 업데이트 될 때 슬레이브서버에 공지가 되어서는 안된다는 이야기이다. BIND-8 버젼의 named는 zone파일이 업데이트 될 때 zone 파일에 있는 NS레코드에 등록되 있는 다른 서버들에게 공지를 하기 때문이다. 이것은 일반적인 이용에는 편할 것이지만 개인적인 연습에서는 이러한 부분을 사용하지 말아야 할 것이다. 우리가 이러한 것으로 인터넷을 어지럽힐 수는 없지 않는가?

그리고 이것은 물론 완전히 허구이다. 실례를 보려면 다음 장을 참조하라

5.5. 왜 reverse lookups 이 작동하지 않는가?

역변환 존이 설정되었을 때 가끔 name lookup(이름검사)이 되지 않아서 '아차'하는 순간들이 있다. 수행전에 당신의 nameserver에 대해 역변환 검사 (reverse lookups)를 할 필요가 있다. 작동하지 않으면 이 세팅을 진행하기 전에 뒤로 가서 고쳐야 한다.

일반적으로 역변환 검사가(reverse looksup) 되지 않는 2가지 이유를 들어 보겠다.

5.5.1. 역변환존이 제대로 위임되지 않는 경우.

네트워크 주소와 도메인을 공급하는 업체에 일반적으로 도메인 이름을 위탁하게 된다. 그러면 업체는 NS 레코드에 추가하고 앞에서 설명한 이론대로 네임서버를 찾는다. 읽어봤겠지만 제대로 작동되지 않으면 다시 돌아가서 읽어봐라.

역변환 존 역시 맡겨질 것인데 만약 192.168.196대의 망을 업체로부터 linux.bogus라고 얻었다면 NS레코드에 포워드 존처럼 역변환존을 추가할 것이다. in-addr.arpa를 따르고 이것으로 망을 구성하면 이 안의 오류를 찾아야 할 것이며 대부분은 업체의 문제이다. 업체와 연락해서 에러를 수정하라.

5.5.2. 클래스가 없는 서브넷을 얻는 경우

좀더 발전된 형식이지만 요사이는 당신이 소규모 업체이면 가지고 있을 법한 일반적인 기술이 되었다.

classless 서브넷은 요새 인터넷의 추세이다. 얼마전만해도 IP 부족으로 고생이 많았다. IETF(Internet Engineering Task Force)의 똑똑한 이들이 머리를 맞대고 문제를 해결했다. 그 결과로 C 클래스보다 작은 서브넷을 얻게 되었는데 여기에 약간의 문제가 있다. Mr. DNS의 사이트에 가서 사용법과 해결법도 참고하라.

읽어보지 않았다면 확인하길 바란다.

첫번째 부분은 인터넷 공급업체가 Mr.DNS의 기술을 인식하지 못한다는 문제이다. 모든 인터넷 업체가 다 그러는 것은 아니지만 만약 이런 경우가 생기면 당신이 원인을 설명하고 보충해 줘야 한다. 물론 당신이 이 부분을 먼저 이해하고 있어야 한다. 그러면 그들이 역변환 존을 설정하고 dig로 확인할 것이다.

두번째 부분은 기술을 명확하게 이해하지 못한다는 것이다. 앞부분이 확실하지 않다면 다시 돌아가서 확인해보길. 그들은 Dr.DNS에서 나온 데로 클래스 없는 역변환 존을 생성할 것이다.

또다른 복병이 있다. 오래된 resolver는 CNAME 트릭을 따르지 않고 역변환 존의 가동을 막을 것이다. 잘못된 클래스를 할당하고 접속을 거부하기도한다. 이러한 경우의 해결책은 인터넷 공급업체에 문의해서 classless 존 파일에 CNAME 대신 PTR레코드를 직접 넣는 것이다.

몇몇 ISP업체들은 automasical system이나 역도메인을 메핑하는 식의 웹기반 폼으로 이것을 조절하기도 한다.

5.6. Slave servers(2차 네임서버)

master 서버에 존파일 설정을 제대로 했다면 이제는 하나 이상의 slave서버도 설정해야 할 것이다. slave 서버는 꼭 필요한 것이다. 1차 도메인이 죽어 버려도 사람들은 2차 네임서버로 찾아가 정보를 얻게 될 것이다. slave 서버는 1차 서버와 멀리 떨어져 있는것이 좋다. 1차 DNS서버와 2차 DNS서버는 될 수 있으면 Power Supply,LAN,ISP,도시, 국가등.. 공유하는 것이 적을 수록 좋다. master와 slave 가 위의 사항들이 모두 다른 경우라면 당신의 slave는 매우 잘된 예이다.

slave는 단순히 master로부터 존파일들을 복사해온다. 아래와 같이 설정하면 된다.

zone "linux.bogus" {
	type slave;
	file "sz/linux.bogus";
	masters { 192.168.196.2; };
};

단순히 데이터가 복사되는 구조이다. 이러한 파일복사는 SOA에 의해 조정된다.

@	IN	SOA	ns.linux.bogus. hostmaster.linux.bogus. (
			199802151	; serial, todays date + todays serial #
			8H		; refresh, seconds
			2H		; retry, seconds
			4W		; expire, seconds
			1D )		; minimum, seconds

master의 시리얼넘버가 단지 slave보다 크기만 하면 존파일이 전송된다. slave의 refresh는 master가 업데이트 될 때마다 체크할 것이다. 만약에 체크가 되지 않으면(master가 죽어서) 매번 재시도 하면서 체크할 것이다. expire기간까지 실패를 한다면 slave는 존파일을 제거하고 더이상 네임서버의 기능을 하지 않을 것이다.

이전처음으로다음
Forwarding 기본보안옵션