리눅스 관련 강좌란

제목	네임서버 #2 1998/12/11 (13:34)
이름	김효원
번호	69
조회	280
본문	~~~~~ 서브도메인의 구성 [참고상자] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    흠 많은 분들이 고민하는것 중에 하나가 도데체 서브도메인을 어떻게 지정해줘야    하지일껍니다. 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 의 약자로 보시면  됩니다. 하는 역활은 특정 도메인로 오는 메일을 지정한 서버로 넘겨 주는 역활을  합니다. 적어주는 방법은 아주 간단하지요.  <doamin>              IN       MX <preference>    <mail server>  이런식으로 적게 됩니다. 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  .  <file>" ;       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     <TAB>       /dev/tty12 이렇게 해줄수 있겠군요. 참 출력할 정보에 대한 위치와 출력파일 사이는 꼭 <TAB> 을 사용하셔야 합니다. 네임서버를 시작할때 (또는 다른 데몬을) 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 서버로써 일정 시간 자료를 달라는 요청만을 받게 됩니다. 큰 부하가 걸리지 않겠지요. 단과대의 서버는 각 과서버가 요청하는 데이타만을 전송하게 되고 과서버들이 학생들의 문의를 받아 처리를 하게 되지요. 시스템의 부하가 전체적으로 분산되는 결과를 가져오겠군요. 이런식의 구성은 어떤가요? 모든 정보와 엄청난 크기의 캐쉬가 하나의 네임서버에 몰리는 것과 각계전투는 엄연한 차이가 있지요. 부산의 모대학처럼 수시로 네임서버가 사망신고를 하는 일도 없어질테구요. (허기사 서울의 모대학도 마찬가지군요. 관리를 하는것인지 방치를 하는 것인지 구분이 안가는 곳이 많더군요. 정말) 마지막으로 이 작은 글이 리눅스와 더불어 즐거움을 느낌에 작은 도움이 될수 있었으면 하는 바램입니다.

1998 by swindler