| Unix/Solaris 관련게시판 |
|---|
| 2000/09/22(17:41) from 203.254.154.69 | |
| 작성자 : 강줄기 (jkkang65@hanmail.net) | 조회수 : 2207 , 줄수 : 1061 |
| 네임서버 설정하는 방법 |
|---|
|
몇번을 다시 적으려고 벼르고 벼르다 오늘에야 vi 를 실행 시켰습니다. 그동안 알짜 5.0 을 만든다는 핑계로 홈페이지 업데이트도 하지 않고 빈둥 빈둥 놀다보니 이리 되었네요. 이번에는 욕 안 먹을 정도로 쓸수 있기를 빌어봅니다. 이 글에서는 도메인명이 무엇인지, 네임서버는 또 무엇인지 그리고 마지막으로 네임 서버를 어떻게 구축하고 테스트 할 수 있는지 정도를 적으려 합니다. 다시 O'Reilly 의 DNS & BIND 를 뒤적여야 할꺼 같군요. 이 글이 네임서버를 구축, 관리하시는 분들에게 도움이 되었으면 합니다. 무엇을 공부하던지 직접 해보는 것 이상은 없습니다. 잘못될 것을 두려워 하기 보단 먼져 일을 저지르고 보십시오. _______________________________________________________________________________ ------------------------------------------------------------------------------- [ 도메인 & 네임서버 ] ▶ 도메인명이란 무엇인가? 네임서버를 구축하기 전에 우선적으로 도메인명이 무엇인가 정도는 알아야 하지 않을까 생각합니다. 다들 너무나 잘 알고 있는 부분인가요? 도메인명이 별거 있겠습니까? 그냥 nownuri.net 이라던지 linux.sarang.net 같은 것이 도메인명이지요. 인터넷에서 어떠한 호스트로 접속을 하고 싶다면? (웹이건 텔넷이건) 그 호스트의 주소를 알아야 하겠지요. 인터넷에 물려 있는 모든 호스트는 자신만의 IP 주소를 가지고 있습니다. 이것이 바로 인터넷에서의 주소입니다. 저의 리눅스 박스인 linux.sarang.net 의 경우 IP 주소가 168.126.127.250 입니다. 세계에서 유일하게 저만이 가지고 있는 주소지요. ^^ (집주소가 똑같은게 두개 있는거 보셨습니까?) 그런데 사실 사람이란게 숫자의 연속을 잘 외우지 못하지요. 168.126.127.250, 203.238.128.51 이렇게 해서 몇개나 기억할수 있을까요? 좀 더 쉽게 살아가기 원하는것은 당연한 것이고 덕분에 도메인명이라는 것을 사용하게 되었다고 생각합니다. ^^ linux.sarang.net 과 168.126.127.250 중에 무엇이 더 외우기 쉬운지는 잘 아시리라 생각됩니다. 그런데 하나 생각하고 넘어갈 것은 도메인명은 (정확히 말해서 FQDN, A Fully Qulified Domain Name) 실제 인터넷의 주소가 아니란 것입니다. 실제적으로 접속할 수 있기 위해서는 IP 주소를 알아야 할 필요가 있는데 둘다 외우면 더 불편하지 편하겠습니까? 네임서버가 바로 도메인명을 IP 주소로 바꾸어 주는 역활을 (또는 그 반대로 IP 주소를 도메인명으로 바꾸어 주는 역활) 하게 됩니다. ▶ 네임서버의 역활 그럼 네임서버는 어떤식으로 도메인명 <-> IP 주소의 역활을 수행할수 있을까요? 계속 이렇게 설명해 나가면 한도 끝도 없겠지만 그래도 꿋꿋이 GO! 아까부터 계속 예로 들었던 제 서버의 도메인명과 IP 주소를 가지고 설명을 하겠습니다. 네임 서버가 도메인명으로 IP 주소를 찾아내는 과정은 아주 질서 정연합니다. 하나 하나 차례대로 차근차근 찾아 나가는 것입니다. linux.sarang.net 의 IP 주소를 찾기 위해서 네임 서버가 어떤 행동을 하는지 살펴볼까요? ----- 도메인명 -> IP 주소의 과정 ---------------------------------------------- linux.sarang.net.┌──────────┐ ┌─────────〉│A.ROOT-SERVERS.NET. │ │NS ns.sarang.net └──────────┘ ┌────┐ │ │local │ │ linux.sarang.net.┌───────┐ │ name │〈─┼───────────〉│ns.sarang.net.│ │ server│ │ NS ns.linux.sarang.net.└───────┘ └────┘ │ ∧ │ linux.sarang.net.┌───────────┐ │ └─────────〉│ ns.linux.sarang.net. │ │ A 168.126.127.250 └───────────┘ ∨ ┌────────┐ A : IP 주소 │사용자(resolver)│ NS : 네임 서버 └────────┘ ------------------------------------------------------------------------------- linux.sarang.net 을 찾을 때 우선 네임서버는 자신이 가지고 있는 네임서버 루트 정보를 참조하여 최상위도메인을 관리하는 네임서버에 sarang.net 도메인에 정보를 요청하게 됩니다. 그러면 루트 네임 서버는 sarang.net zone 을 관리하는 네임서버가 ns.sarang.net 이란것을 알려 줄것입니다. 그럼 다시 우리의 무적 네임서버는 ns.sarang.net 으로 linux.sarang.net 에 대한 정보를 달라고 요청합니다. ns.sarang.net 은 요청을 받고 linux.sarang.net zone 을 관리하는 네임서버가 ns.linux.sarang.net 이라는 것을 알려줄것이고, 마지막으로 ns.linux.sarang.net 에 정보를 요청하면 자신의 데이타베이스에서 linux.sarang.net 의 IP 주소가 168.126.127.250 이라는 것을 알려줄 것입니다. (상당히 간단하지요? 물론 저렇게 움직인다는것을 보여주지는 않겠지만 ^^) 상위도메인부터 ( "." 으로 구분해서 뒤쪽에 있을수록 상위도메인명입니다.) 순차적으로 질문을 수행해서 최종적인 결과를 얻는것입니다. 마치 탐문수사하는것 같지요. ----- 외부에서도 도메인을 찾을려면? ------------------------------------------- 하나 집고 넘어가야 할것이 있습니다. 많은 분들이 자신의 서버에 네임서버를 만들기만 하면 외부에서 지정한 도메인을 찾을수 있으리라는 생각을 하는것을 보았습니다. 위에서 설명한것처럼 도메인명을 IP 주소로 바꾸기 위해서 네임서버는 상위 네임서버로부터 차례대로 질문을 하고 정보를 얻는데 중간에 이빨이 빠져 있다면 과연 찾을수 있을까요? 자신의 서버에 네임서버가 돌고 있다고 해도 상위 네임서버에 어떤 zone 을 관리하는 네임서버로 지정이 되어 있지 않다면 그 곳까지는 질문도 들어오지 않을 것입니다. 절대로 건너뛰는 일은 없거든요. 누구나 네임서버를 만들면 도메인을 마음대로 만들어서 사용할 수 있다면 아마 인터넷은 지옥이 될껍니다. ^^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 위에서 간략하게 네임서버의 역활을 언급한적이 있는데 과연 이녀석을 무엇을 하는 존재일까 하는 존재의 가치를 생각해 보면서 조금 더 적을까요? 벌써 여러번 말했듯이 가장 큰 역활은 도메인명을 IP 주소로 전환해서 알려주고 또한 IP 주소를 도메인명으로 전환해줄 때 쓰입니다. 그리고 또 하나, 특정 지역(zone)에 대한 데이타를 가지고 외부에서 오는 질문에 대한 정보를 보내주게 됩니다. 질문만 하는것이 아니라 답변도 하는 것이지요. 네임서버의 구축이란것은 다름이 아니라 답변을 하기 위한 정보를 가질 수 있도록 해주는 것이겠지요. 질문만 수행하는 네임서버라면 구축이라는 말을 붙일 필요도 없을 정도로 간단합니다. (파일 하나 달랑 넣어 주면 끝이거든요. caching only name server 라고 합니다. 후에 설명할께요.) 네임서버가 가지는 정보를 이용해서 도메인명 <-> IP 주소의 역활을 해내는 것이지요. 자신이 정보를 가지고 있지 않다면? 위에서 말한 것처럼 정보를 찾아서 다른 네임서버들에게 질문을 하게 되는 것입니다. (그러고보니 하는 일은 딱 한가지군요. 원하는 것을 찾아다 준다!^^) 슬슬 실제로 구축하는 예를 들어 볼까요? 이제 기본이니 머니 하는것도 지겨워 질꺼 같은 생각이 듭니다. 실제로 만들어 가는 과정을 보면서 중간 중간에 부수적인 설명을 하도록 하지요. [ 네임서버 만들기 ] 이 글에서 네임서버 프로그램인 bind 를 컴파일하고 설치하고 하는것은 전혀 적지 않겠습니다. 요즘에야 워낙에 패키지들이 잘 나와서 굳이 컴파일 하지 않아도 기본적으로 다 동작하니까요. 끝까지 컴파일해서 쓰셔야 겠다면 ftp.isc.org 에서 bind 소스를 받아오셔서 그 안의 문서를 잘 읽어 보시고 스스로 해보시기 바랍니다. ▶ 초기화 파일의 설정 (named.boot) 네임서버의 기본 설정 파일은 하나입니다. 바로 /etc/named.boot 입니다. 그 외의 부분은 사용자가 설정하기 나름입니다. 네임서버가 시작할때 /etc/named.boot 의 내용을 읽어 들인후에 그안에 설정한대로 다른 정보를 포함하기도 하고 시키는대로 작동을 하게 됩니다. 아무래도 안을 들여다 보아야 겠지요? ----- /etc/named.boot 파일 내용 ----------------------------------------------- directory /var/named cache . named.root primary linux.sarang.net linux.zone primary 0.0.127.in-addr.arpa local.rev primary 127.126.168.in-addr.arpa linux.rev ------------------------------------------------------------------------------- 저의 시스템에 설정되어 있는것을 배껴다 넣었습니다. 간결하지요. 기본적으로 쓰이는 옵션? 태크?는 딱 3가지 입니다. 그것만 쓰면 네임서버 하나를 뚝딱 해결할 수 있습니다. 괜히 복잡하게 꾸밀 생각은 하지도 말고 주지도 맙시다. (무슨 소리 하는거지?) directory, cache, primary 이렇게 3가지 입니다. 설명을 해보도록 하지요. - directory 네임서버의 정보를 가진 데이타 파일들이 위치할 디렉토리를 지정하는 것입니다. 다른 옵션에서 지정하는 파일들을 여기서 지정한 디렉토리 밑에서 찾게 되는 것입니다. 이게 이녀석이 하는 역활의 전부입니다. - cache 루트 네임서버들에 대한 정보를 가지고 있는 파일을 지정합니다. 흠 이부분에서 또 하나 알고 넘어가야 할것이 생겼군요. 보통 우리가 도메인명을 적을때 linux.sarang.net 이렇게 적지요. 사실 정확하게 적으려면 마지막에 "." 을 하나 더 붙여줘야 합니다. 그러니까 우리가 일반적으로 쓰는 것은 "." 이 생략되어 있는 것입니다. 그러니까 최상위 도메인은 "." 가 되는 것이지요. 역시 네임서버가 정보를 찾기 시작할때 가장 먼저 질문을 보내는 곳도 "." 를 관리하는 네임서버가 되겠지요. 왜 domain 을 적는 부분에 "." 이 적혀 있는지 이해가 되시는지요? 위에서 지정하는 cache 파일엔 "." 도메인을 관리하는 네임서버들에 대한 정보가 기록되어 있고 그 정보를 이용해서 정보를 찾게 되는 겁니다. 아주 중요한 파일이겠지요? 어떤식으로 네임서버를 구성하던지 이 파일은 항상 존재해야 합니다. 파일 이름은 보통 named.root 라고 쓰는데 지정해 주기 나름입니다. 이 파일은 사용자가 만드는 것이 아니라 인터닉에서 배포하는 것을 받아서 쓰게 됩니다. ftp://ftp.rs.internic.net/domain 에서 named.root 파일을 받아서 사용하면 됩니다. bind 소스나 패키지에도 포함되어 있습니다. 파일 내용에 관해선 조금 후에 알아 보도록 하지요. - primary 이 서버가 관리하는 지역도메인(zone)과 그 정보를 가진 파일을 지정합니다. 위에서 보면 domain 부분에 linux.sarang.net 이라고 적혀 있지요. 그러니까 네임서버로 문의(query)가 들어올때 linux.sarang.net 하의 도메인명에 대해서는 지정한 파일에서 정보를 찾아 오는 것입니다. linux.sarang.net 하의 도메인이라고 하면 좀 헷갈릴지도 모르겠습니다. 간단하게 하자면 *.linux.sarang.net 을 관리 하는 것입니다. ( * 이 무엇을 뜻하는지 아시리라 믿쑵니다.) 흠 하나 생각해볼까요? 여러개의 지역도메인을 하나의 네임서버에서 관리 할 수 있는 것인지? 당연히 가능하겠지요? 그저 관리할 지역도메인을 적어 주고 데이타를 가진 파일만 적어준다면? 열개이던 백개이던 정보를 가지지 못할 이유가 없겠지요? ----- IP -> 도메인명 찾기 ----------------------------------------------------- 흠 domain 부분에 적혀 있는 0.0.127.in-addr.arpa 는 도데체 무엇일까요? 다시 한번 존재의 가치를 생각해 봐야 겠군요. 네임서버에서 하는 역활중에 도메인명을 IP 주소로 바꾸는것과 IP 주소를 도메인명으로 바꾸는 것이 있다는것은 글을 잘 읽으셨으면 아시겠지요. in-addr.arpa 부분은 IP 를 도메인으로 바꾸기 위한 것입니다. 0.0.127.in-addr.arpa 가 뜻하는 것은 127.0.0.* 의 지역 IP 를 관리 한다는 것입니다. 좀 이상하지요? 우리가 보통 쓰는 방식이 아니라 역순이지요. IP 라고 해서 도메인과 틀릴께 전혀 없습니다. 한번 찾는 방법을 알아 볼까요? 역시 linux.sarang.net 을 가지고 해봐야 겠지요. 흠 IP 주소가 168.126.127.250 이니까 하나 하나 순차적으로 찾아가 봅시다. (흠 앞부분부터 찾아야 겠지요? named.boot 에 적는 형식으로 적어 보면 250.127.126.168.in-addr.arpa 이렇게 되네요. 도메인과 마찬가지로 뒤에서부터 찾게 되지요. 히힛) ----- IP 주소 -> 도메인명의 과정 ---------------------------------------------- 250.127.126.168.in-addr.arpa. ┌──────────┐ ┌─────────〉│A.ROOT-SERVERS.NET. │ │NS ns.kornet.nm.kr └──────────┘ ┌────┐ │ │local │ │ 203.127.126.168.in... ┌────────┐ │ name │〈─┴───────────〉│ns.kornet.nm.kr.│ │ server│ co-H1-250.kornet.nm.kr └────────┘ └────┘ ∧ NS : 네임 서버 │ ∨ ┌────────┐ │사용자(resolver)│ └────────┘ ------------------------------------------------------------------------------- 흑 제 IP 를 찾아보면 도메인명이 co-H1-250.kornet.nm.kr 로 나오는군요. 에궁, 어쨋든 찾는 순서를 얘기 해보도록 하지요. 도메인의 최상위가 "." 이엇듯이 IP 주소의 최상위는 in-addr.arpa. 입니다. 역시 최상위 IP 를 관리하는 네임서버로 문의를 하겠지요. 그러면 최상위 서버에서 168.126.*.* 을 관리하는 네임서버가 ns.kornet.nm.kr 이라는 정보를 줍니다. (중간이 생략되었다구요? 168 까지는 최상위서버인 인터닉이 가지고 있어서 그렇습니다.) 그럼 ns.kornet.nm.kr 로 문의를 하게 되고 문의한 IP 에 맞는 도메인이 co-H1-250.kornet.nm.kr 이라는것을 알려주지요. 여기서 보시면 한가지 미심쩍은것이 있을것입니다. 분명히 linux.sarang.net 의 IP 가 168.126.127.250 이었는데 IP 로부터 찾아보니 엉뚱한 도메인이 나오지요? IP 와 도메인 사이에 어떠한 상관관계가 없는 것인지? 상당히 헛갈리기 쉬운 부분입니다. 도메인을 IP 로 바꾸어 주는것은 그 지역도메인을 관리하는 네임서버에서 담당합니다. IP 를 도메인으로 바꾸어 주는 것은 역시 그 지역 IP 를 관리하는 네임서버에서 해주게 됩니다. 서로 일치해야만 할까요? 전혀 아닙니다. 제가 203.251.92.* 라는 C 클래스의 IP 를 소유하고 sarang.net 이라는 도메인을 가지고 있다고 해볼까요? 168.126.127.250 이라는 IP 에 linux.sarang.net 이라는 도메인을 주고 싶습니다. 저희 지역 IP 가 아니지요? 불가능할까요? 아닙니다. 아무런 관계 없이 부여해줄수 있습니다. 관리하는 사람 마음입니다. nownuri.net 의 IP 인 203.238.128.51 에다가 slow.sarang.net 을 주고 그 도메인으로 접속해도 됩니다. (느려터진 나우누리 T_T) 그럼 IP 쪽은 어떨까요? nownuri.net 이라는 도메인을 203.251.92.250 에다가 주고 싶다면? 주면 됩니다. 아무런 문제가 없습니다. ^^ 다시 말해서 자신이 가진 도메인을 자신의 지역 IP 에만 부여해줄 수 있는 것도 자신이 가진 IP 에 자신의 지역 도메인만을 부여해줄수 있는 것도 아닙니다. 그냥 원하는데로 ^^ 물론 sarang.net 이라는 지역도메인을 가지고 있는데 엉뚱하게 linux.net 이런것을 부여해줄수 있는 것은 아니지만요. 이해가 가실러는지 모르겠습니다. 글 재주가 워낙에 없어서... ------------------------------------------------------------------------------- - secondary [backup-file] 이 서버가 관리하는 지역 도메인(zone)과 그 정보를 가져올 서버 그리고 저장 될 파일을 지정합니다. 네임서버에는 두가지 타입이 있습니다. 위에서 설명했던 (다른 부분까지 곁들였지만 ) primary master 와 secondary master 입니다. (ide 하드 얘기 하는거 같군요.) 둘의 차이는 직접 데이타 파일을 만들어 주느냐 아니냐 하는 정도입니다. 모든 기능은 똑같습니다. primary 의 경우는 직접 모든 데이타 파일을 만들어 주어야 하지만 secondary 는 다른 서버로 부터 데이타를 받아 와서 저장합니다. ip-address-list 부분에 정보를 가져올 서버의 ip 를 적게 됩니다. 그러면 지정한 지역 도메인에 대한 정보를 그 서버에서 가져오게 됩니다. 백업 서버로써 사용할 때 쓸수도 있을 것이고 심심할때 해봐도 될 것입니다. SOA 필드와 secondary 서버와 관계가 깊으니 그 부분에서 더 자세한 얘기를 해보도록 하지요. 대충 위의 예제에서 본 것들은 다 설명한것 같지요? 아직도 엄청나게 남아 있습니다. 모두를 설명할 수는 없겠지만 몇개는 설명해야겠지요. - forwarders 자신에게 오는 문의를 다른 서버로 떠넘기는 것을 지정합니다. ip-address-list 부분엔 여러개의 ip 를 적어도 됩니다. 앞에 적은 서버가 죽어 있으면 그 다음 그 다음 이런식으로 문의를 떠 넘겨 버립니다. 자신의 서버에 오는 문의를 모두 168.126.127.250 IP 를 가진 서버로 넘기고 싶다면 이렇게 하면 됩니다. forwarders 168.126.127.250 - include 다른 파일의 내용을 포함시킵니다. 간단하지요? primary 따로 secondry 따로 지정하고 named.boot 에서 각 파일을 불러 오게 하면 관리가 편하겠지요. (과연 편할까?) - options 몇가지의 옵션이 있습니다. (윽 위에서 설명하는것들은 태그라구 해야 하나? 머라고 불러야 하는건지... 아시는분?) options + forward-only 그냥 forwarders 만 지정했을 경우는 지정한 서버들이 응답이 없을시에는 자신이 네임서버의 역활을 수행하게 되는데 (루트 네임 서버에 문의를 하고 다시 탐문 수사를 하는거지요.) forward-only 옵션을 줄 경우는 그것마저도 하지 않습니다. 지정한 서버에서 응답이 없으면 난 몰라 하고는 그냥 놀아 버립니다. (게으른 녀석이지요 쩝) + query-log 자신에게로 들어오는 모든 문의를 syslog 에 전달하게 됩니다. (syslog 는 그것을 받아서 /var/log/message 정도에 저장하겠지요) 로그 파일이 상당히 커질껍니다. ^^ + debug 디버깅 메세지를 출력해 줍니다. 네임서버에 문제가 있을때 사용할수 있겠지요. ▶ 지역도메인(zone) 파일 이제 /var/named 디렉토리로 이동해볼까요. named.boot 예제에서 linux.sarang.net 지역 도메인의 정보를 가지고 있는 파일이라고 지정한 linux.zone 파일을 예로 들어가면서 데이타 파일의 기본적인 구성을 알아 보도록 하지요. ------------------------------- linux.zone ------------------------------------ @ IN SOA ns.linux.sarang.net. root.linux.sarang.net. ( 1998020700 ;Serial 10800 ;Refresh 3600 ;Retry 3600000 ;Expire 43200 ;Minimum ) IN NS ns.linux.sarang.net. IN A 168.126.127.250 IN HINFO "Interm Pentium" "ALzzA Linux" localhost IN A 127.0.0.1 ns IN A 168.126.127.250 www IN A 168.126.127.250 w3 IN CNAME @ irc IN CNAME @ ftp IN CNAME @ news IN CNAME @ ------------------------------------------------------------------------------- 도메인 정보를 저장하는 파일은 일정한 규칙이 있습니다. 그 규칙을 따라서 작성하기만 한다면 아무런 문제가 없습니다. ^^ 이 파일은 3 개 정도의 Record 로 나뉘어 집니다. SOA, NS, 그리고 그외 나머지 하나 하나 알아 보아야 겠지요? - SOA Records 맨 위에서 ( ) 로 닫힌 부분까지가 SOA 부분입니다. @ IN SOA ns.linux.sarang.net. root.linux.sarang.net. ( 1998020700 ;Serial 10800 ;Refresh 3600 ;Retry 3600000 ;Expire 43200 ;Minimum ) 이 부분이 빠지면 네임서버는 동작을 하지 않게 됩니다. 언제나 있어야 하고 없어서는 안되는 부분입니다. 여기서 가지고 있는 정보는 지역 도메인명, primary 네임서버, 관리자 이메일, 그리고 secondary 와 상관있는 몇가지, 마지막으로 TTL 시간을 지정합니다. 처음부터 차근 차근히 알아 보도록 할까요. @ IN SOA ns.linux.sarang.net. root.linux.sarang.net 여기서 @ 는 지정했던 지역도메인을 지칭합니다. named.boot 파일에서 지정을 해주었었지요? primary linux.sarang.net linux.zone 가운데 부분이 지역도메인을 적어 놓은것이지요. 그러니까 지금 이 파일에서 @ 는 linux.sarang.net. 을 나타내게 되는 것입니다. (지정한것에 따라 다르겠지요.) @ 대신에 linux.sarang.net. 을 적어도 상관이 없습니다. ----- "." 의 중요성 ----------------------------------------------------------- 한가지 중요한 것이 있습니다. 데이타 파일을 만들때 가장 실수하기 쉬운 부분이 "." 입니다. 이것을 적느냐 적지 않느냐에 따라서 네임서버가 제대로 돌아가느냐 아니면 반쯤 돌아 버리느냐의 웃음과 눈물의 교차로에 서게 되지요. "." 을 마지막에 붙임으로써 완전한 도메인명이라는 것을 나타낼수 있는 것입니다. "." 이 최상위 도메인이라는 것은 누차 얘기 했엇지요. (기억 하실런지?) 만약에 위에서 @ 대신에 linux.sarang.net. 을 적는다고 할때 마지막의 "." 을 뺏다고 하면? 흠 이렇게 적을수 있지요. linux.sarang.net IN SOA ns.linux.sarang.net. ..... 이렇게 되면 실제 네임서버에서 인식하기는 이런식으로 인식할 것입니다. linux.sarang.net.linux.sarang.net. IN SOA ..... 재밌게 되지요? 지정했던 지역 도메인명이 뒤에 슬쩍 붙어 버립니다. 이러면 과연 제대로 돌아갈까요? SOA 부분이 아니라 다른 모든 부분에서 마찬가지 입니다. ------------------------------------------------------------------------------- SOA 는 현재 Record 의 유형(type)을 지정하는 부분입니다. (참 영어와 한국어는 예매하군요.) 여러가지의 유형이 있는데 몇가지를 설명 드리겠습니다. + SOA 도메인 정보에 대한 authority 를 지정한다고 하는데 저 단어를 도데체 어떻게 한글로 바꿀까요? + NS 네임 서버를 지정할때 쓰이구요. + A 도메인명 -> IP 주소를 지정할때 쓰입니다. + PTR IP -> 도메인명을 지정할때 쓰이지요. + CNAME 별명(alias)를 지정할때 쓰입니다. + MX 메일 익스체인져를 지정합니다. 나중에 상세한 설명을 하지요. 이 정도만 알면 다 이루었노라 라고 해도 됩니다. 별로 어려울께 없습니다. 욱! 이거 그만하고 빨리 SOA 필드들에 대한 설명을 해야겠네요. 마감 시간이 무섭게 다가오고 있습니다. 뒤의 ns.linux.sarang.net. 부분은 primary 네임서버를 적게 됩니다. 그리고 마지막의 root.linux.sarang.net. 은 관리자의 이메일 주소입니다. 네임서버에 문제가 있거나 외부에서 관리자와 연락하고 싶을 때는 이것을 보고 연락하게 되겠지요. 아 보통 이메일을 적는 것과는 좀 틀리지요. root@linux.sarang.net. 이렇게 적어야 정상일텐데 말이죠. 왜 그럴까요? 간단합니다. 네임서버 데이타 파일에선 @ 를 다른 의미로 쓰고 있기 때문이지요. 위에서 열심히 썼자나요. ^^ (한번더 강조! 마지막의 "." 을 잊지 마세요.) 다음으로 넘어 갑니다. 후후 팍팍 넘어 갑니다. 벌써 새벽 5시군요. 이메일로 영어 강좌가 날라 오는군요. 오늘은 "You are a real turkey!" 를 가르켜 주는군요. 저보고 하는 소리 같아요. 흑 T_T ( 1998020700 ;Serial 10800 ;Refresh 3600 ;Retry 3600000 ;Expire 43200 ;Minimum ) 이 부분이 아주 중요한 부분이면서도 알 필요 없을수도 있는 부분입니다. Serial 부터 Expire 까지는 primary <-> secondary 에 필요한 부분이라고 보시면 됩니다. (물론 없으면 안됩니다.) + Serial 이 정보의 버젼?을 나타냅니다. secondary 서버에서 primary 서버의 데이타를 가지고 올때 우선 primary 서버에 serial 번호를 달라고 요청을 하게 됩니다. 그리고 자신이 가진 데이타보의 serial 번호보다 높다면 나머지 데이타를 받아오게 됩니다. 같거나 낮다면 갱신되지 않은 것으로 생각하고 거기서 그냥 멈춥니다. ^^ 보통 날짜+두자리수 로 쓰게 됩니다. 이유는 알아 보기 쉽기 때문이지요. 언제 고쳤다는 것을 ^^ 항상 네임서버 정보를 수정한 후에는 serial 번호를 하나라도 올려주는 버릇을 가지시기 바랍니다. 나중에 secondary 서버까지 관리하게 되고 그러면 3살 버릇이 후회될껍니다. + Refresh secondary 측에서 새로운 정보를 요청할때까지의 시간을 지정합니다. 초단위로 지정하는데 저기에 지정한 시간 이후에 secondary 서버에서는 primary 서버로 갱신된 정보가 있는지를 문의하게 되지요. + Retry 말 그대로 재시도 하는것입니다. primary 서버에 접속을 할수 없으면 저기에 지정한 시간후에 다시 접속을 시도하게 됩니다. + Expire 일정기간 이상 primary 서버에 접속하지 못한다면 이전에 가져왔던 정보들을 파기할 기간을 지정합니다. 위에서 설명한 모든것은 primary 서버에서 지정을 하는것이지요. secondary 서버는 받아온 정보에서 저 부분을 읽어서 그대로 행동을 할 뿐입니다. 손 하나 까딱 안해도 되는 것입니다. + Menium TTL(Time to Live) 상당히 재미있는 부분입니다. 네임서버는 한번 찾았던 정보에 대해서 캐슁을 합니다. 예를 들면서 설명을 하는것이 가장 좋겠지요. 네임서버가 linux.sarang.net 을 찾는다고 합시다. 그럼 루트 네임 서버에 우선 문의를 할 것이고 sarang.net 지역도메인의 네임서버가 ns.sarang.net 이라는것을 알아낼 것이고 linux.sarang.net 지역도메인의 네임서버가 ns.linux.sarang.net 이라는 정보를 얻어낼 것입니다. 그 다음에 다시 www.sarang.net 을 찾는다고 한다면 과연 루트 서버에 문의를 시작해서 처음부터 찾아서 내려올까요? 그렇지 않습니다. 이미 sarang.net 지역도메인의 네임서버가 ns.sarang.net 이란 것을 캐슁해서 가지고 있기 때문에 sarang.net 지역도메인에 속해 있는 www.sarang.net 을 찾고자 한다면 바로 ns.sarang.net 으로 문의를 하게 됩니다. 꽤나 똑똑하지요. 그리고 다시 한번 linux.sarang.net 을 찾는다고 하면 이미 그냥 자신의 캐쉬에서 정보를 내줍니다. (이것 때문에 네임서버 정보를 고쳐도 일정 기간 이전 정보가 인터넷상을 떠도는 것입니다.) TTL 은 무엇이냐면 다른 서버에서 자신의 정보를 가져 갔을때 그쪽 서버의 캐쉬에 이 정보가 얼마나 머물것이냐를 지정합니다. 3600 초로 정해준다면 이 정보를 가져간 다른 네임서버는 정확히 3600 초 후에 캐쉬에서 가져갔던 정보를 지울 것입니다. 그리고 누군가 그 정보를 요청한다면 처음부터 다시 찾기 시작할 것입니다. 그런데 도데체 이것이 무엇이 재밌는 것일까 궁금하신 분도 있을꺼 같습니다. 다른 서버의 캐쉬에 자신의 정보가 얼마나 유지될 것인지를 그 정보를 가져간 서버가 아니라 이쪽에서 지정한다는 것이지요. (재미 없나요? 전 재밌는데 ^^) 시간을 길게도 짧게도 마음데로 조종이 가능한 것입니다. ----- TTL 시간 설정 ----------------------------------------------------------- TTL 시간을 짧게 지정한다면 정보를 고치면 짧은 시간안에 다른 서버에서도 새로운 정보를 가져가게 될 것입니다. 다만 캐쉬가 빨리 빨리 비워지기 때문에 계속해서 문의가 들어오게 되지요. dyn.ml.org 같은 것이 TTL 타임을 아주 짧게 잡고 쓰는 예입니다. 다이나믹 IP 를 가진 PPP 사용자등에게 도메인을 부여 하는것이기 때문에 계속해서 정보가 바뀌게 되고 최대한 빨리 적용을 시켜야 하기 때문이지요. (아마 5분으로 잡고 쓰고 있을껍니다.) 시간을 아주 길게 지정한다면 아주 오랫동안 다른 서버의 캐쉬에 저장이 될 것입니다. 자신의 네임서버가 잠시 죽어 있다고 해도 정보가 사라지지 않을 것입니다. 그렇지만 정보를 수정하였을때 그 정보가 완전히 갱신되기 까지의 시간이 오래 걸리겠지요. (사람 미치게 합니다.) 보통 43200 ~ 86400(1일) 정도로 지정해서 사용하게 됩니다. 물론 자신의 네임서버의 용도에 따라 지정해야 겠지요. 어느 정도 감이 잡히시는지요? ------------------------------------------------------------------------------- + NS Records 네임서버를 지정하는 부분입니다. 지정한 지역도메인의 네임서버를 지정할 때나 서브도메인을 구성할때 사용하게 됩니다. linux.sarang.net. IN NS ns.linux.sarang.net. 이런 부분이 될것입니다. linux.sarang.net. ("." 이 마지막에 붙으면 완전한 도메인이라는것을 기억하시지요!!!) 지역도메인의 네임서버는 ns.linux.sarang.net 이라고 지정하였습니다. 위의 예제와는 조금 다른 모양이지요? @ IN SOA ... ( 생략 ) IN NS ns.linux.sarang.net. 이렇게 지정이 되 있지요. 똑같은 표현입니다. @ 가 지정한 지역도메인을 나타낸다는것을 기억하시지요. 위의 예제라면 linux.sarang.net. 을 나타내구요. linux.sarang.net. IN NS ns.linux.sarang.net (linux.sarang.net. 생략됨) IN HINFO i586 linux ( '' ) IN A 168.126.127.250 www IN CNAME @ 이런식으로 적을때 www 위의 "IN A ..." 부분까지는 linux.sarang.net. 에 대한 정보를 적는 부분이 됩니다. 위의 NS 지정부분도 앞에 @ 이 빠졌지만 계속 연결되어 지정되어 있기 때문에 @ 에 대한 것을 정의한 것이 되는 것이지요. ~~~~~ 서브도메인의 구성 [참고상자] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 흠 많은 분들이 고민하는것 중에 하나가 도데체 서브도메인을 어떻게 지정해줘야 하지일껍니다. sarang.net 이라는 지역도메인을 가지고 있다고 합시다. linux.sarang.net 을 서브도메인으로 지정해주고 싶습니다. 네임서버는 168.126.127.250 IP 를 가지고 있는 서버로 지정하구요. ns.linux.sarang.net. IN A 168.126.127.250 linux.sarang.net. IN NS ns.linux.sarang.net. 간단하지요? 우선 네임서버로 쓸 IP 에 대해 ns.linux.sarang.net 이라는 도메인을 부여 했습니다. (꼭 ns 여야 하는것은 절대 아니지요. 그저 이게 네임서버란 것을 알아 보기 쉬우라고 그렇게 적은 것입니다.) 그리고 linux.sarang.net. 지역도메인의 네임서버가 ns.linux.sarang.net 이라고 지정했지요. 하나 설명, ns.linux.sarang.net 을 네임서버로 쓰고자 할때 이 도메인명에 맞는 IP 주소가 있어야 겠지요. 없으면 접근이 불가능하니까요. 잊지 마세요. 네임서버로 사용할 도메인에 대한 IP 지정을 말입니다. 이제부터는 linux.sarang.net 지역도메인(zone)에 대해서는 ns.linux.sarang.net 의 네임서버가 담당하게 됩니다. sarang.net 네임서버는 단지 "그 지역도메인은 저녀석이 관리하는거야 그쪽으로 가봐" 라고 해줄뿐입니다. (자신의 서버가 네임서버의 역활을 하기 위해서는 자신의 상위 네임서버에서 바로 이런 설정이 되어 있어야 하는 것이지요.) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 기본적인 두가지 Record 에 대해서 알아 봤구요. 다른것들을 좀 볼까요? @ IN SOA ... ( 생략 ) IN NS ns.linux.sarang.net. IN A 168.126.127.250 IN HINFO "Interm Pentium" "ALzzA Linux" IN MX 10 mail.linux.sarang.net. IN MX 20 mail.sarang.net. localhost IN A 127.0.0.1 ns IN A 168.126.127.250 mail IN A 203.251.92.8 www IN A 168.126.127.250 w3 IN CNAME www irc IN CNAME @ ftp IN CNAME @ news IN CNAME @ 설명할껀 다 나온거 같군요. 여기 있는거만 설명 하면 다 되겠는걸요? (윽 PTR 이 빠졌군요.) 자 계속 하지요. A 는 도메인명 -> IP 주소를 지정한다고 설명 드렸었지요. 여기서 설명할 부분은 그렇게 많지 않은 것 같군요. ns IN A 168.126.127.250 이 부분을 볼까요. 상당히 이상하지요? 달랑 ns 만 적어 놓구서 멀 설정한다는 것인지? ns 란 도메인의 IP 가 168.126.127.250 이라는 것일까요? "." 을 기억하십시오. 마지막에 "." 이 들어가지 않으면 완전한 도메인명으로 생각하지 않고 @ 를 붙인다고 했었지요. 그렇다면 실제는 이런식이 될껍니다. ns.linux.sarang.net. IN A 168.126.127.250 맞지요? 둘중에 어떤식으로 써도 문제는 없지요. "." 만 잘 찍는다면... 상당히 간단합니다. 사실 데이타 파일의 구성은 이것으로 끝입니다. 더 이상은 적을만한게 없군요. 아 MX 가 있었군요. 그럼 MX 에 대해서 이야기 해볼까요? MX 는 Mail Exchanger 의 약자로 보시면 됩니다. 하는 역활은 특정 도메인로 오는 메일을 지정한 서버로 넘겨 주는 역활을 합니다. 적어주는 방법은 아주 간단하지요. IN MX 이런식으로 적게 됩니다. domain 부분에 적은 도메인명으로 오는 메일이 지정한 곳으로 옮겨지게 됩니다. preference 부분이 우선순위를 지정하는데 여러개의 MX 가 존재 할경우에 우선적으로 접근을 시도할 순서대로 숫자를 적어주면 되지요. 숫자가 낮을수록 먼저 접근합니다. mail server 에는 말그대로 mail server 의 역활을 하는 도메인명 또는 IP 주소를 적어 주게 됩니다. 그곳으로 메일이 넘겨지는 것이지요. ----- MX 사용의 예 ------------------------------------------------------------ 보통 대형 서버들을 보면 웹서버, 메일서버등이 분리되어 있는 경우가 대부분이지요. 당장 제가 항상 버티는 나우누리만 보더라도 그렇습니다. (아마 웹서버가 NT 라서 심심하면 죽는다는 소문이) 나우누리의 메일서버는 tiger1.nownuri.net 이지요. 이런식의 구성을 어떻게 할수 있을까요? 사용자들이 ID@nownuri.net 으로 메일을 보냈으면 보냈지 tiger1.nownuri.net 으로 메일을 보내지는 않을텐데 말이죠. 이것이 바로 MX 의 역활입니다. 아마 나우누리는 이렇게 되어 있겠지요. nownuri.net. IN MX 0 tiger1.nownuri.net. tiger1.nownuri.net. IN A 203.238.129.52 nownuri.net 도메인으로 오는 메일을 모두 tiger1.nownuri.net 으로 넘기는 것입니다. ~/.forward 파일의 기능을 아시지요? 비슷한 거겠지요. 개인 사용자가 (저 처럼) 자그마하게 네임서버를 돌린다면 굳이 MX 가 필요하지 않습니다. 어차피 한대에서 모든 것을 하게 될터인데 자기한테 당연히 오는 메일을 이쪽으로 보내라고 지정할 이유는 없자나요. 여러개의 MX 를 쓰는곳이 어디 있을가요. 하이텔의 경우를 한번 볼까요? hitel.net preference = 10, mail exchanger = mail.hitel.net hitel.net preference = 200, mail exchanger = mail.UU.NET 두개의 MX 가 지정되 있습니다. (nslookup 으로 본거에요. 그런데 uu.net 하고 무슨 관계가 있다고 저곳으로 MX 가 지정되어 있는건지?) 우선 hitel.net 으로 오는 메일은 mail.hitel.net 으로 넘겨지게 됩니다. mail.hitel.net 이 응답이 없다면 다음 우선순위를 가진 mail.uu.net 으로 메일이 전달되게 됩니다. 물론 이 서버까지 죽는다면 메일은 반송되거나 메일서버가 살아날때까지 대기 하게 되겠지요. 기본 메일서버를 하나 놓고 백업서버를 사용할때에 이런식으로 구성할 수가 있겠지요. ------------------------------------------------------------------------------- 윽, 위에서 말했던 "You are a real turkey!" 가 정말 저를 두고 한 얘기 같군요. (넌 정말 멍청이구나! 라는 뜻이레요. T_T) CNAME 을 은근슬쩍 넘겨 버리려고 했습니다. 도메인명을 지정할때 두가지 방법이 있습니다. 하나는 직접 IP 주소를 지정하는 것이고 또 하나는 이미 지정한 도메인에 alias 를 거는 겁니다. CNAME 이 후자지요. www IN A 168.126.127.250 w3 IN CNAME www 를 보면 www 의 주소가 168.126.127.250 으로 지정되어 있고 w3 는 www 의 alias 로 되어 있지요. w3 로 접속을 시도해도 똑같은 168.126.127.250 으로 접속이 되게 됩니다. 별명으로 부른다고 인간이 바뀌는 것이 아닌 것처럼 말입니다. 한가지 주의할 것이 있다면 @ 를 alias 로 걸면 안된다는 것입니다. @ 가 뜻하는 것이 무엇인지 까먹으셨다면 다시 위로 올라가서 글을 보시기 바라구요. www IN A 168.126.127.250 @ IN CNAME www 이런식으로 @ 를 alias 로 지정해버릴 경우에는 secondary 서버쪽에서 이쪽의 데이타를 가져가지 못합니다. nslookup 했을때 ls 명령으로 등록된 도메인명을 볼수도 없지요. 물론 secondary 서버를 운영하지 않는다면 저렇게 지정해도 별 문제는 없습니다. ----- 시스템 분산 ------------------------------------------------------------- 같은 IP 에 대해서 여러개의 도메인명을 부여 할때 꼭 CNAME 을 써야 하는 것은 아닙니다. 위에 예제 보세요 168.126.127.250 에 도대체 몇개나 들러 붙어 있는지 ^^ 똑같은 IP 를 계속 지정해줘도 문제가 없고 하나더 하나의 도메인에 여러개의 IP 를 부여해도 마찬가지로 문제가 없습니다. home.taegu.net. IN A 203.251.92.86 IN A 203.251.92.190 IN A 203.251.92.9 nslookup 으로 어떻게 나오는지 확인 해볼까요? # nslookup home.taegu.net Server: localhost Address: 127.0.0.1 Name: home.taegu.net Addresses: 203.251.92.86, 203.251.92.190, 203.251.92.9 기차게 잘 나오지요. 이렇게 지정하면 어떤 경우가 발생하느냐? home.taegu.net 으로 접속을 시도하게 되면 지정한 3개의 IP 로 돌아가면서 접속을 시도하게 됩니다. 순식간에 시스템 분산이 이루어 지는것이지요. (실제로 home.taegu.net 이 그렇게 돌아가고 있습니다. NFS 로 자료를 공유하고 CPU 를 분산 시키는 것이지요.) ping 으로 실험을 해볼까요? [root@linux /root]# ping -c 1 home.taegu.net PING home.taegu.net (203.251.92.9): 56 data bytes 64 bytes from 203.251.92.9: icmp_seq=0 ttl=59 time=174.4 ms [root@linux /root]# ping -c 1 home.taegu.net PING home.taegu.net (203.251.92.86): 56 data bytes 64 bytes from 203.251.92.86: icmp_seq=0 ttl=58 time=173.9 ms [root@linux /root]# ping -c 1 home.taegu.net PING home.taegu.net (203.251.92.190): 56 data bytes 64 bytes from 203.251.92.190: icmp_seq=0 ttl=59 time=173.9 ms 똑같은 도메인명인데 ping 을 시도할때마다 IP 주소가 바뀌지요. 나우누리, 하이텔, 코넷등이 모두 이런식으로 부하를 여러 서버로 분산시키지요. 제일 대표적인 곳은 제가 가장 싫어하는 microsoft 의 웹서버일껍니다. nslookup www.microsoft.com 이라고 했더니 16개의 IP 가 출력되는군요. (실제로 그 밑으로 180여대가 더 붙어 있다고 하던데) 부하가 많이 걸리긴 걸리나 봅니다. (공격도 자주 당하겠지요. 껄껄) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 기왕 하는김에 계속 설명 합시다. HINFO 라는 부분도 있지요. Hardware Info 의 약자쯤 되는것인데 하드웨어 정보를 적어 주는 것입니다. linux.sarang.net. IN HINFO "Interm Pentium" "ALzzA Linux" 이렇게 지정을 해주었을때 nslookup 으로 살펴보면 이렇게 나옵니다. linux.sarang.net CPU = Interm Pentium OS = ALzzA Linux 어떻게 사용하는지 번쩍 감이 오시지 않습니까? ▶ reverse map 파일 흠 이제 네임서버 데이타 파일의 유형(type)중 자주 쓰이는것은 PTR 하나 정도 남았군요. 이걸 설명 하려면 0.0.127.in-addr.arpa 에 대한 정보를 가진 local.rev 파일을 뒤집어 봐야 겠네요. ----- local.rev --------------------------------------------------------------- @ IN SOA localhost. root.localhost. ( 1998020700 ;Serial 28800 ;Refresh 14400 ;Retry 3600000 ;Expire 86400 ;Minimum ) IN NS localhost. 1 IN PTR localhost. ------------------------------------------------------------------------------- 정말 간단하지요. local.rev 파일은 0.0.127.in-addr.arpa 지역 IP 에 대한 정보를 가지고 있는것으로 지정했으니 여기서 @ 는 0.0.127.in-addr.arpa 를 나타내겠군요. 역시 도메인 정보를 가지고 있던 파일과 마찬가지로 SOA Record 와 NS Record 를 가지고 있지요. 새롭게 보이는건 마지막 한줄 밖에 없군요. 1 이라는 썰렁한 숫자 하나가 적혀 있군요. 마지막이 "." 으로 끝나지 않았으니 뒤에 지역 도메인 아니 지역 IP 가 붙어야 겠군요. 이렇게 바꿔 쓸수 있겠는데요. 1.0.0.127.in-addr.arpa. IN PTR localhost. .in-addr.arpa 를 빼고 거꾸로 읽으면 127.0.0.1 이 되지요. loopback IP 주소가 되는군요. 127.0.0.1 IP 의 도메인명이 localhost 라고 지정해 주고 있는것이지요. 상당히 간단합니다. 0.0.127.in-addr.arpa 가 아니라 하나 더 있는 127.126.168.in-addr.arpa 의 경우도 마찬가지입니다. 단지 도메인을 IP 로 바꾸어주는 부분이라는 것이고 그 외엔 틀린 것이 없습니다. 상위 IP 를 소유한 네임서버에서 지역 IP 를 관리하는 네임서버를 지정할수도 있고 틀릴것이 없지요. (마지막에 "." 다시 한번 주의하세요.) 아차차, 1 의 앞에 빈칸이 들어가선 안됩니다. 주의하세요. ----- 네임서버와 reverse map -------------------------------------------------- 서강대에서 공개강좌를 마치고 마지막 코스인 만용형의 집에 가서 한가지 중요한 사실을 알게 되었습니다. 도움을 준 주연이에게 무한 감사를... ^^ reverse mapping 이 되지 않는 그러니까 IP 로 도메인이 찾아 지지 않을 경우에 상당한 문제가 발생합니다. 어떤 문제냐면 네임서버를 이용할수가 없게 되는 것입니다. (상당히 큰 문제지요. ^^) 네임서버의 IP 가 168.126.127.250 이라면 이 IP 에 맞는 도메인을 찾지 못할 경우 서버의 기능을 사용할수 없게 되는 것이지요. 아! 자신의 네임서버가 외부에서 IP 주소로 도메인을 찾는것이 되지 않는다고 해도 상관은 없습니다. 로칼에서만이라도 찾을수 있으면 됩니다. 어차피 그 네임서버를 기본서버로 쓴다면 자신이 가지고 있는 정보는 알려주게 되니까요. 필히 위에서 설명한 reverse map 설정에 대한 글을 보시고 네임서버 도메인에 대한 것을 설정해 보시기 바랍니다. ------------------------------------------------------------------------------- 2.2.3. root server cache 파일 마지막 하나의 파일이 남았습니다. 루트 네임서버 정보를 가지고 있는 파일, 지정한 바에 따르면 이름은 named.root 가 되는군요. ----- named.root -------------------------------------------------------------- ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . " ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file /domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher at RS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; file named.root ; ; last update: Aug 22, 1997 ; related version of root zone: 1997082200 ; ; ; formerly NS.INTERNIC.NET ; . 3600000 NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET ; 생략 . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 ; End of File ------------------------------------------------------------------------------- 위의 주석문을 보면 이 파일을 구할수 있는곳을 알려 주고 있지요. 앞서 설명한대로 ftp://rs.internic.net/domain 에서 구할수 있습니다. 역시 설명한 바 있는데 서버를 구축하는 사람이 작성할 필요가 전혀 없지요. 단지 가져오거나 이미 있는 것을 쓰면 됩니다. ^^ 조금 살펴 볼까요. 약간 복잡하게 적어 놓아서 그렇지 이제껏 살펴본 파일들과 틀릴것이 없습니다. . 3600000 NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 . 도메인의 네임서버가 A.ROOT-SERVER.NET. 이고 A.ROOT-SERVER.NET 의 IP 주소가 198.41.0.4 라고 되있군요. 그런식으로 여러개가 나열되어 있는 것에 불과합니다. 새롭게 보이는건 IN 대신에 3600000 이라는 숫자인데 이것은 앞서 설명했던 TTL(Time to Live) 지정입니다. 위에서 지정한 것은 그 데이타 파일 전체에 적용되는 것이고 지금 보시는것은 각각의 도메인명에 대해서 따로 설정을 하는 것입니다. 자 데이타 파일의 양식?에 대한 모든 것이 끝났습니다. 이해 하기 힘드신 부분이 있으신가요? 고민해보세요. (이메일로 질문하라고 하실줄 알았죠?) ----- caching only name server ------------------------------------------------- caching only name server 가 뜻하는 것이 무엇일까요. 위에서 설명했던 네임서버의 역활을 크게 두가지로 나누어 본다면 다른 서버로부터 정보를 찾아 오는 것과 자신이 가진 정보를 알려 주는것으로 나눌수 있겠지요. caching only name server 는 전자의 행동만을 할 뿐입니다. 즉 자신이 가지고 있는 정보는 없고 사용자(resolver)가 어떤 도메인에 대한 IP 주소를 알기를 요청하면 그 정보를 찾아와서 사용자에게 전달해 주는 것입니다. caching only name server 는 단지 2개의 파일만으로 구성됩니다. 이미 짐작하셨으리라 생각되는데 네임서버 초기 설정 파일인 /etc/named.boot 와 루트네임서버 캐쉬 파일입니다. 루트네임서버에 대한 정보가 필요한 이유는 가장 먼저 문의를 해야 할곳이기 때문이지요. 자신이 가지고 있지 않다면 어디서도 구할 수가 없으니까! 그외에도 loopback 에 대한 reverse map 파일 정도를 가지고 있으면 금상첨화입니다. (0.0.127.in-addr.arpa 를 기억하시는지요.) ------------------------------------------------------------------------------- [ 네임서버의 문제점 찾기 ] 네임서버를 구성한 후 이상하게 오동작을 하면서 말을 듣지 않는다면 어떻게 하시겠습니까? 그냥 내버려둘 수는 없겠지요. 어떻게던지 그 문제점을 찾아 해결을 해야 할텐데 그 문제점을 파악하는 방법이 무엇이 있을까요? 그것에 대해서 알아 보도록 하지요. ▶ 네임서버에 적용되는 SIGNAL kill 명령을 사용할때 SIGNAL 에 익숙하신지 모르겠습니다. -HUP 은 모두 아시리라고 생각합니다. restart 나 reload 정도가 되겠지요. 네임서버 역시 httpd 처럼 kill -HUP 을 이용해서 죽이지 않고 정보를 갱신 시킬 수 있습니다. 그것만이 아니라 몇가지가 있는데 설명을? 드려야죠. - HUP 네임서버를 리스타트 시킵니다. 수정한 정보를 갱신하게 되는 것이지요. primary 네임서버는 자신이 가지고 있는 정보를 바탕으로 갱신하게 될것이고 secondary 서버라면 primary 서버로 새로운 내용이 있는지 정보를 요청하게 될 것입니다. killall -HUP named 하면 굳이 pid 를 찾지 않고 한번에 할수 있겠지요. kill -1 $(cat /var/run/named.pid) 해도 됩니다. ^^ - INT 네임서버가 캐쉬에 보관하고 있는 내용을 파일로 출력(dump) 합니다. /usr/tmp/named_dump.db 라는 이름으로 만들어집니다. 메모리에 가지고 있는 모든 것이 파일로 내려지는 것이지요. 꽤 복잡할껍니다. - ABRT 현재 네임 서버의 상황을 파일로 기록합니다. /usr/tmp/named.stats 라는 파일로 기록됩니다. - USR1, USR2 네임서버의 디버깅을 켰다 껐다 할수 있습니다. /usr/tmp/named.run 파일로 저장되고 끌때까지 계속 기록 됩니다. USR1 이 켜기 위한 SIGNAL 이고 USR2 가 끄기 위한 것입니다. 역시나 복잡합니다. T_T - WINCH named.boot 파일을 설정할때 option query-log 를 기억하고 계십니까? 네임서버로 오는 모든 문의를 파일로 syslogd 로 전달하는 기능을 켜고 끌수 있습니다. ^^ 필요할때만 껐다 켰다 하면 되겠지요. 지금 설명한 몇개의 SIGNAL 을 이용해서 네임서버의 문제를 파악할수 있겠지요. 이런 것들을 잘 사용하게 되면 좀더 환상적인 관리자가 될수 있지 않을까요. ▶ syslog 의 이용 제가 사용하고 있는 레드햇의 경우 네임서버가 syslogd 로 보내는 몇몇 메세지가 /var/log/message 에 기록되지 않게 되어 있습니다. /etc/syslogd.conf 의 한줄을 보면 /var/log/message 에 기록될 정보에 대한 정의가 있습니다. *.info;mail.none;news.none;authpriv.none /var/log/messages info 수준의 모든 메세지중 mail, news, 사용자인증 부분을 제외한 부분을 파일에 기록하게 되어 있지요. 네임서버의 메세지는 좀더 낮는 수준에서 나오는 것 같습니다. 이렇게 고치시면 네임서버의 수많은 메세지를 보실수 있을겁니다. (물론 다른 데몬들의 메세지도 마찬가지입니다.) *.*;mail.none;news.none;authpriv.none /var/log/messages 아니면 이런 방법도 있습니다. 가상터미널중 tty12 는 거의 사용할 일이 없지요. 모든 syslog 메세지를 tty12 터미널로 보내서 메세지를 보고 싶을때 파일을 열 것 없이 alt+ctrl+f12 키로 tty12 터미널로 전환하여 실시간으로 메세지를 확인할 수 있습니다. (네임서버만 아니라 어떤 데몬을 구성하더라도 에러 메세지는 중요한 것입니다.) *.*;mail.none;news.none;authpriv.none /dev/tty12 이렇게 해줄수 있겠군요. 참 출력할 정보에 대한 위치와 출력파일 사이는 꼭 을 사용하셔야 합니다. 네임서버를 시작할때 (또는 다른 데몬을) tty12 터미널을 주시하고 있으면 쉽게 원인을 파악할 수 있을껍니다. ▶ nslookup, dig 네임서버를 이용하고 또 네임서버의 문제점을 찾을때 가장 기본적으로 사용되는 도구입니다. 사용법은 간단하며 help 를 보는것 만으로도 대충 사용법을 알 수 있을 것입니다.. 그외에도 dig (domain information groper) 라는 프로그램이 있는데 nslookup 과 비슷하게 사용할 수 있는데 저는 잘 사용하지 않아서 어떤 점이 그렇게 틀린지는 모르겠네요. nslookup 하나로 모든 것을 알아낼 수 있으니까요. ^^ 사용법은 각각의 메뉴얼 페이지를 보는것이 가장 빠르리라 생각합니다. 이곳에 모든 사용법을 쓸 수도 없고 또 간단하게 적는다는것도 상당히 머리 아프군요. [ 네임서버 구축의 예 ] 두어가지 예를 들면서 효율적인 네임서버 관리에 대해서 얘기해 보겠습니다. 간단한 내용입니다. 보통 지역도메인을 관리 하고자 한다면 2 ~ 3개의 네임서버가 필요 합니다. (하나만 있어도 물론 돌아가기야 합니다. 저 보십시오. 잘 돌리자나요.) 인터닉에 도메인을 신청한다고 해도 아마 2개는 기본으로 네임서버를 지정하는 것으로 알고 있습니다. 왜 두개나 또 세개나 되는 네임서버가 필요한 것일까요? 도메인으로 IP 를 찾지 못한다면 그쪽으론 접속도 못한다는것을 익히 들어 아실껍니다. (제가 누차 설명했지요.) 메인 네임서버가 어떠한 이유로 다운이 된다면 외부에서 이쪽으로 접속하고자 하는 사람들은 발을 동동 구를수 밖에 없게 됩니다. 그 지역도메인을 관리하는 네임서버가 죽었으니 접속도 못하고 IP 를 외우고 있는 것도 아니고, 그럴때를 대비하기 위해서 백업 네임서버가 돌아가는 것이 좋겠지요. 이 경우는 secondary 로 구성해서 수동으로 데이타를 작성할 필요 없이 primary 서버측의 데이타를 가져오게 해놓는다면 상당히 쉽게 되겠지요. 하나 더 필요한 경우가 있다면 이쪽의 네트웍이 죽었을때입니다. 내부에 있는 백업 네임서버도 네트웍이 죽었는데 작동을 할까요? 패킷이 들어오지를 못하는데 말이죠. 이럴 때를 대비해서 자신의 서브넷이 아닌 다른 네트웍에 네임서버를 하나 두게 되는것이죠. 보통 isp 등에서 라인을 받아 사용하면 그쪽의 네임서버를 이런 용도로 사용하게 됩니다. 역시 외부 네임서버도 secondary 로 구성하게 되면 상당한 수고를 덜 수 있겠지요. 네트웍이 죽었는데 도메인은 찾아봤자 무슨 소용이냐 라고 얘기하실수 있지만 네임서버가 도메인명을 부여하는것은 자신의 네트웍만이 아니라는 것은 아시죠? 한가지 다른 경우를 또 들어 볼까요. 대학의 네임서버라면 상당히 큰 지역도메인을 관리하게 되지요. 큰 대학이라면 그 하에 단과 대학들과 학과들이 있을 것이고 학생 수도 만만치 않겠지요. 이 모든것을 단 하나의 네임서버가 담당한다면 엄청난 부하와 메모리를 사용하게 될 것입니다. 이럴 경우에 secondary 서버를 적절히 이용해서 서버의 부하를 분산시키는 것도 관리의 기본이 아닐까 생각합니다. ----- 네임서버 구성의 예 ------------------------------------------------------ ┌─────┐ │중앙 서버 │ 〈 primary 서버 └──┬──┘ │ ┌─────────┴────────┐ │ │ │ │ ┌──┴───┐ ┌─────┐ │문리대 서버 │〈 중앙서버에 대한 〉│공대 서버 │ └┬───┬─┘ secondary 서버 └┬───┬┘ │ │ │ │ ┌─┴─┐ └─┐ ┌─┘ └─┐ │영문과│ │ │ │ └───┘ │ ┌─┴─┐ │ ┌─┴─┐ │컴공과│ ┌─┴─┐ ∧ │국문과│ └───┘ │기공과│ │ └───┘ └───┘ │ ∧ │ ∧ │ ∧ │ │ │ │ └─────┴─────┬─────┴──────┘ 단과대 서버에 대한 secondary 서버 ------------------------------------------------------------------------------ 에구 그리는게 너무 힘드네요. ^^ 이런식의 구성이 있다고 봅시다. 중앙서버에 하나의 네임서버만이 있다면 수많은 학생들의 요청을 처리 하느라고 뺑뺑이를 돌겠지요. 상당한 부하가 걸릴것입니다. 그러나 위 그림처럼 각 단과대에서 secondary 서버로써 중앙서버의 데이타를 받아와 네임서버를 돌리고 그 밑에 붙은 각 과에서 단과대 서버의 데이타를 이용해서 secondary 서버를 구성하고 학생들은 각과의 네임서버를 이용한다면 중앙서버는 외부에서 오는 문의와 각 단과대 서버에서 secondary 서버로써 일정 시간 자료를 달라는 요청만을 받게 됩니다. 큰 부하가 걸리지 않겠지요. 단과대의 서버는 각 과서버가 요청하는 데이타만을 전송하게 되고 과서버들이 학생들의 문의를 받아 처리를 하게 되지요. 시스템의 부하가 전체적으로 분산되는 결과를 가져오겠군요. 이런식의 구성은 어떤가요? 모든 정보와 엄청난 크기의 캐쉬가 하나의 네임서버에 몰리는 것과 각계전투는 엄연한 차이가 있지요. 부산의 모대학처럼 수시로 네임서버가 사망신고를 하는 일도 없어질테구요. (허기사 서울의 모대학도 마찬가지군요. 관리를 하는것인지 방치를 하는 것인지 구분이 안가는 곳이 많더군요. 정말) 마지막으로 이 작은 글이 리눅스와 더불어 즐거움을 느낌에 작은 도움이 될수 있었으면 하는 바램입니다. |
|
|