[별첨] INTERNET Service를 위한
       NAME Service의 바른이해

이 문서는 2000.6.27에 Linux Start 에 기고 되었던 원고를 정리한 것입니다.

이 문서는 Internet Server를 운영하려는 초보자들의 이해를 돕고자 작성 되어 졌다. 이 문서가 초보자들을 위한것임을 내세우기는 하나 리눅스를 설치를 할줄 알고, name server를 셋팅을 해 본 경험이 있는 사람들과 네임서버를 셋팅할 준비를 하고 있는 사람들을 대상으로 한다. 때로는 초보자들을 쉽게 이해시키기 위하여 약간 왜곡된 정보를 줄수도 있을 것이다. 이는 필자가 공부를 하면서 약간 왜곡되게 얻은 정보들 때문에 쉽게 이해를 하고 나중에 또한 쉽게 바로 잡을수 있었던 부분들이 있었기 때문에 이렇게 표현을 하고자 한다.

이 문서를 100% 믿으려고는 하지 말기 바란다. 위에서 언급한 데로 고의적인 왜곡된 부분이 있다. 다만 참고를 하기 바란다.

이 문서에서 Daemon들을 설정법을 설명하지는 않는다. 여기서 언급 되는 daemon들의 설정법이 궁금하다면 앞의 Name Server 강좌를 참조 하기 바란다.

[차례]

1. Name Server란..
2. 그렇다면 왜 NS 설정이 중요한가?
3. 실례
   3-1. NS 설정과 System resource
   3-2. 외부에서는 안되요.
   3-3. NS와 Sendamil
   3-4. dot(.) 의 철학
   3-5. Inverse domain 이란 놈은 뭐하는 놈인가?
4. Debugging 을 잘하자
5. 후기

1. Name Server란..

Internet 상의 host들은 ip address라는 숫자로 구성된 주소를 가지고 있다. 하지만 이 숫자로 된 주소들은 외우기가 힘들고 모두 비슷비슷하게 생겨서 구분하기가 참 힘들며, 더우기 이 주소로 사이트의 특성을 알기는 정말 힘이든다. 그래서 외우기 쉽고 주소만으로도 그 site의 특성을 알기 쉽게 하기 위하여 만든 것이 DNS(Domain Name Service) 이다. 그리고 이 DNS를 관리 하는 것이 바로 Name Server 이다. 우리가 Windows 에서 internet 연결을 위한 셋팅을 할때 TCP/IP 설정에서 주 DNS서버 보조 DNS 서버(또는 이름해석 서버라고도 한다) 라는 항목이 바로 domain name을 ip address로 해석을 해줄 Name Server를 지정을 하는 것이다.

2. 그렇다면 왜 NS 설정이 중요한가?

이 항목에서 설명할 부분은 왜 중요한가 보다 다른 Daemon들 처럼 그냥 공식적으로 설정을 하면 안되고 반듯이 이해를 해야 하는가를 다루려고 한다.

Name Service란 아주 중요한 것이다. 예전에는 IP address 기반의 서비스이기 때문에 별 상관이 없을지는 모르겠지만 현재의 Internet은 IP address 기반이기 보다는 Name 기반의 서비스가 주가 된다. 그러므로 Name Daemon 외의 다른 Daemon(http의 virtualhost 기능, sendmail 등등)들은 거의 절대적으로 NS에 의존을 하게 된다. 그러므로 NS의 설정이 잘못되었을 경우에는 자기의 host에만 문제를 주는 것이 아니라 다른 사람 아니 다른 지역의(여기서 다른 지역이란 local뿐 아니라 global을 의미한다) 네트워크까지 마비를 시킬수 있기 때문이다. 즉 그만큼 자기가 하는 설정이 간단한 문제가 아니라 다른 나라까지도 영향을 미칠수 있는 중요한 작업이라는 것을 의식을 해야 한다.

3. 실례

3-1. NS 설정과 System resource

대부분의 daemon들은 해당 설정들을 memory에 올려 놓게 된다. 그러므로 설정 파일을 변경을 하고 나면 memory에 올려져 있는 설정 내용들을 reflesh를 해 줘야지만 변경값들이 적용이 된다.

그럼 여기서 resource 얘기는 무었때문에 나온것인가를 보겠다. 즉 골자는 설정 파일에 설정 한줄이 더 들어 가면 들어 갈수록 차지하는 메모리 양은 많아 진다는 것이다.

실례로 하나의 호스트에서 ns, web, ftp, mail 같은 것을 다 같이 처리하는 호스트가 대부분일 것이다. (특히 개인 서버에서..) 이 경우 보통 ns를 처리 하는 것을 보면 ns.domain.com , www.domain.com, ftp.domain.com, mail.domain.com 과 같은 식으로 하나의 IP에 A record나 CNAME record를 다 잡아 주는 경우가 허다하다. 하지만 이런식의 셋팅은 거의 무의미 하다고 보면 된다. domain.com으로 접속을 하거나 www.domain.com으로 접속을 하거나, mail.doamin.com 으로 접속을 하거나 하등의 차이가 없다. (물론 virtual hosting으로 사용이 된다면 차이가 있을수도 있다) 그럼에도 불구하고 보기에.. 아니면 습관적으로.. 또는 아무런 생각도 없이 남들이 이렇게 하니까 해야 한다고 생각을 하여 잡아 주는 경우가 대부분이다. 하지만 이러한 셋팅 하나하나가 시스템의 resource 를 조금씩 잡아 먹고 간다는 것은 거의 생각을 하지 않는 것이 대부분이다.

보기에 있어야 한다고 생각이 된다면 위에서 처럼 하나하나씩 잡아 주는 것 보다는 네트워크 소통량을 생각하여 *.domain.com(bind-8.x 대 부터 지원) 를 이용하여 잡아 주는 것이 더욱 낫다. 위에서 *으로 잡아 주게 된다면 memory상에는 한줄분의 용량만 차지하여 몇줄분의 memory를 절약 할수 있으며, 또한 suffer가 미스 스펠링을 하거나 또는 심심하여 아무 sub domain으로 찾아 볼때, 찾지를 못하여 대기 상태에 들어가는 네트워크 부하를 줄여 줄수 있다는 장점을 가질수도 있다.

3-2. 외부에서는 안되요.

무슨 FAQ 같은 기분은 들지만.. NS 설정에서 가장 많이 듣는 질문이다. 이 질문이 나오게 되는 가장 큰 이유는 아마 필자의 생각으로는 두가지로 압축이 된다.

1) Nic에 domain을 신청한지 얼마 되지 않았을때.. ( 이 경우는 등록이 되었다는
   메일을 NIC으로 부터 받고 나서를 기준으로 한다.)
2) DNS의 ip address를 이전 하였을때

대충 이 경우가 대부분이다. 1)번의 경우에는 참 답답한 경우가 많다. 즉 whois에서는 이미 등록이 완료가 되었는데 죽으라고 name 설정값이 외부에서는 인식이 되지 않는 경우이다. 이 경우에는 대부분의 이유가 NIC에서 해당 도메인에 ns record값을 부여 하게 되는데 이 record값이 외부로 퍼지는데 걸리는 시간이 있기 때문이다. 그러므로 시간이 지나가기를 기다려야 할 뿐이다. :-)

2)번의 경우도 마찬가지 이다. whois에서 이전이 완료가 되었는데 이전된 값이 NIC에서 다른 하위 서버들로 퍼지는데 걸리는 시간과 다른 DNS server들의 cache에 남아 있는 기존의 값이 아직 timeout이 되지 않아서 예전의 정보를 뿌려주는 경우가 다반사 이다.

이 때에는 NIC에서 변경된 시간 (whois에서 변경된 값이 기준은 아니다. whois의 정보는 단순히 DB 정보에서 뿌려주는 것 뿐이며, 실제로 NIC의 DNS에서 변경이 되어져야 하는데 이 시간은 정확히 알수가 없다. 그러므로 whois에서 변경이 되어도 며칠은 더 기다려야 하는 이유가 여기에 있다) 을 기준으로 이전에 설정했던 TTL 값 만큼의 시간은 기다려 줘야 한다.

3-3. NS와 Sendamil

name server와 sendmail은 아주 밀접한 관련을 가진다. sendmail 자체가 name을 기반으로 서비스를 하게끔 설계가 되어 있기 때문에 sendmail은 NS에 아주 의존적이다.

name server 설정을 하다 보면 MX record라는 것을 보게 된다. 이는 MX record를 지정한 주소로 오는 메일을 특정 host로 포워딩을 하는 기능을 한다. (포워딩이라고 하기에는 좀 무리가 있다. 포워딩은 서버가 메일을 받은 다음 서버가 해당 서버로 보내는 것을 포워딩이라고 하지만, MX record의 경우에는 name server로 sendmail이 해당 mail server를 찾으러 올때 미리 MX record로 지정된 호스트를 알려 주는 역할을 하기 때문에 엄격하게 말하면 포워딩이라고는 할수가 없다) 그런데 3-1 항목에서 처럼 한대의 호스트에서 NS와 mail을 다 처리할 경우에는 이는 쓸데 없는 설정이 되어 버린다. 즉 inverse domain이 제대로 설정이 되어 있고 (이는 외부에까지 퍼지지는 않아도 상관이 없다. 단 자기 자신에서는 꼭 찾아 져야지만 올바른 name service가 가능하다) sendmail.cw 에 메일을 처리할 domain만 등록이 잘 되어 있으면 메일을 받는데는 전혀 문제가 없다는 것이다. MX record를 왜 사용하는지에 대한 아무런 지식이 없다면 누군가의 설정을 보고 그대로 host name만 변경을 하여 사용하는 사람 들의 경우에는 또다시 이렇게 MX record를 설정하게 되는 것이 다반사 라는 것이다.

그럼 MX record가 어떻게 작동을 하는 것인지 간단하게 예를 들어 보자.


[ image 를 클릭 하면 명확한 이미지를 볼수 있습니다. ]

위의 그림은 HOST A에서 HOST B로 메일을 보내는 과정을 그린 것이다. 일단 HOST A에서 메일을 보내기 위하여 하는 첫번쨰 작업은 메일 주소에 있는 host에 대한 메일이 어느 곳에서 처리가 되는지를 찾게 된다. 그래서 자신의 호스트에 지정이 되어 있는 DNS로 query를 날리게 된다. 그리고 HOST A에 지정된 DNS에서는 이 query를 다시 해당 도메인을 관리하는 DNS에게 문의를 한다. 만약 이전에 이 정보를 문의한 적이 있으면, 즉 HOST A의 DNS의 cache에 정보가 들어 있다면 2,3 번 과정은 생략이 된다.

여기서 잠깐 참고 할것은 2,3 번의 과정은 이 사이에도 여러 DNS들이 존재 한다. 실제로 왕래가 빈번한 도메인이라면 실제로 해당 도메인의 DNS까지 가기 전에 먼저 다른 중간에 위치한 DNS로 부터 정보를 얻을수도 있을 것이다.

일단 2,3번의 과정을 마치면 다시 HOST A의 DNS는 HOST A에게 해당 정보를 반환 하고(4번 과정), 이 정보를 받은 HOST A는 해당 호스트로 바로 전송을 하게 되는 것이다. 즉 mail servier의 이름이 mail.a.com 임에도 불구하고 a.com 으로 보낸 메일이 a.com으로 가지 않고 mail.a.com 으로 가는 이유가 여기에 있는 것이다.

3-4. dot(.) 의 철학

bind를 설정함에 있어 dot charactor만큼 중요한 문자는 없다. 즉 이것이 있고 없고에 따라 엄청난 결과를 초래하게 된다. 보통 dot를 잘못 사용한 경우의 예는 아래와 같다.

$ nslookup 1.1.1.1
Server: ns.oops.org
Address: x.x.x.x

Name: oops.org.oops.org
Addresss: 1.1.1.1
$

위와 같은 결과가 나오는 경우를 종종 볼수가 있다. 이는 bind의 설정에서 dot는 origin(@) 에 해당이 되기 때문이다. 즉 name의 제일 뒤에 dot가 존재 하면 그 이름을 완전한 이름으로 해석을 하고, 없으면 그 이름뒤에 origin 을 붙여 주기 때문에 위의 현상이 발생을 하게 되는 것이다.

이런 에러를 만났을 경우 이러한 사항만 숙지 하고 있다면 다른 사람에게 질문을 하고 누군가 답을 줄때 까지 기다릴 시간을 낭비하지 않아도 되는 이점이 생긴다는 것을 명심하라!!!!

3-5. Inverse domain 이란 놈은 뭐하는 놈인가?

우선 named를 위한 용어 중에 reverse mapping 이라는 용어가 있다. 이 용어가 먼 뜻인가하면, 즉 ip address를 domain name으로 변환을 하는 것을 뜻한다. 즉 inverse domain은 이 reverse mapping을 가능하게끔 설정을 해 주는 것을 의미하며, bind에서는 ip-pool.in-addr.arpa 로 origin을 표기하게 된다. 이 inverse domain의 설정 파일은 주로 ***.rev의 이름을 가지고 하며, PTR record를 사용하여 지정을 하게 된다.

그렇다면 실제로 자신의 도메인들이 reverse mapping이 되는지 테스트를 해 보라. 거의 안되는 사람들이 대부분일 것이다. 이는 요즘 ipv4방식의 ip address 기반하에서는 C class가 거의 바닥이 난 상태여서 하나의 c class 를 여러개로 나누어 사용을 하다 보니 발생하는 문제이다. 즉 하나의 c class를 여러 subnet 으로 나누어 사용을 하다 보니 뒷쪽의 subnet들은 제일 처음의 subnet에만 inverse domain을 설정할수 있는 권한이 지정이 되기 때문이다. 물론 ISP에 되게 해달라고 항의를 할수도 있지만 뒷쪽으로 inverse doman의 설정 권한을 넘기는 방법은 너무나 노가다 작업이기 때문에 필자 또한 거절을 당한 경험이 있을 정도이다.

그럼 필자가 이 항목을 적는 이유는 무엇일까? 이 항목으로 인한 질문이 많이 발생하기 때문이다. 물론 질문을 하는 이들은 이 항목 때문이라는 걸 별로 인식을 못하는듯 하지만.. :-)

name server setting을 한후에 nslookup을 사용했을 경우

*** ns.oops.org can't find 1.1.1.in-addr.arpa.: Non-existent host/domain

과 같은 에러 메세지를 받아본 경험이 있을 것이다. 이것이 바로 inverse domain 설정을 잘못하여 발생하는 에러인 것이다. 즉 외부로 퍼지지는 않아도 최소한 자신의 호스트에서만은 inverse domain 설정이 되어져야 한다는 것이다.

그래야 자신의 name server를 자신의 host에서 name server로 지정을 할수 있는 것이다. 물론 외부의 host에서는 이러한 에러가 나지를 않는다. !!

또한 위의 에러가 나타난다고 하여 name service가 되지를 않는다는 것은 아니다.

4. Debugging 을 잘하자

name service에서 debugging이라는 것은 무엇을 뜻하는 것일까? 즉 내가 설정한 name들이 제대로 작동을 하는지 살펴 보고, 에러가 나타날 경우 어디서 에러가 발생하는 지를 찾아 내는 작업이 바로 name service를 위한 debugging을 의미한다.

이 작업을 하기 위하여 가장 유용하게 사용을 하는 것이 바로 nslookup 명령어 이다. 단순히 name의 ip address를 찾기 위하여 많이들 사용을 하기는 하지만 실제로 set q=RECORD 를 이용하여 여러가지 query를 날릴수 있다.

즉 이 항목을 마지막에 넣어 두는 이유는, nslookup만 사용을 잘해도 질문하고 답변하는 시간을 줄일수 있다는 것을 알려 주고 싶어서이다. nslookup의 사용법에 대해서는 왠만한 name server 강좌에서 모두 볼수 있을 것이다.

5. 후기

필자가 name server를 셋팅하고 질문을 받으면서 가장 답답했던 점이 남의 설정파일을 받아서 살짝 변경하여 사용하는 사람들이 대부분이라는 점이다. 즉 이해를 할 생각은 하지 않고 그냥 되면 되는 구나 하는 사람들이 대부분이라는 말이다.

위에서도 언급을 했듯이 name service는 이해를 제대로 하지 않고서 운영을 할경우 피해가 global하게 퍼질수 있는 위험 요소를 가지고 있음에도 불구하고, 또 하나를 알았으면 다른것에 응용을 할수 있는 것들을 그저 그냥 그렇게 지나치고 만다는 것이 필자를 너무 당황 스럽게 하는 요소들이다.

그래서 필자가 질문을 받고, 운영을 하면서 어이가 없다 싶은 질문이나 주의를 해야 할 부분들에 대해 이렇게 문서를 만들게 된 것이 이 글의 주요 목적이 될것이다.

또 하나의 목적은 최소한 이글을 읽고 다른 사람, 다른 네트워크에 피해를 입히는 일을 최소한으로 줄여 보았으면 하는 이유도 포함이 될것이다!

>> 이전 : Method of Dynamic Update