안녕하세요
뚱보 프로그래머입니다.
아들과 와이프가 A감염으로 시름시름 앓고 있네요...
에휴....
오늘 DNS입니다..
1. DNS 개요
name service는 domain name을 IP 주소로 대응시켜주는 서비스이다. 인터넷 프로토콜 상위의 응용프로그램들은 IP 주소를 사용하여 서로를 인식하는데 이는 컴퓨터의 입장에서 보면 당연하지만 사람들이 기억하기에는 너무 불편한다. 또한 어떤 컴퓨터가 어떤 서비스를 제공한다는 것을 알기가 쉽지 않다. 이런 불편을 해소하기 위한 노력의 결실이 DNS 서비스이다.
초기의 인터넷인 ARPAnet은 불과 수 백개의 호스트로 이루어진 작은 규모였다. 그 때는 중앙의 한 컴퓨터(NIC, Network Information Center)에서 일정한 주기로 추가되거나 새로 명명된 호스트들의 명단을 파일(HOSTS.TXT)로 전송하였고 각 호스트는 /etc/hosts 에 저장하여 사용하였다. 하지만 네트워크에 연결된 시스템의 수가 늘어나고 그에 따라 hosts 파일의 크기도 늘어났으며 이 파일을 서로 교환한다는 것도 무리가 있었다. 뿐만 아니라 파일의 크기가 늘어남에 따라 검색하는데 소요되는 시간도 상당히 길어지게 마련이다. 이를 대체하기 위한 것이 DNS이다. 그리고 외부 네트워크와 통신하기 위해서는 정확한 호스트의 주소를 가지고 있어야 하며 이 주소를 사람들이 기억하기 쉬운 이름으로 대신한 것이 DNS이다.
컴퓨터가 외부와 통신을 하기 위해 네트워크와 호스트를 구분하는 방법은 물리적인 계층(Physical Layer)에선 MAC(Media Access Control) 주소와 인터넷 계층(Inernet Layer)에선 IP 주소로 구분하게 된다. 그리고 IP 주소를 호스트 이름으로 변환하기 위해 사용할 수 있는 것이 BIND(Berkeley Internet Name Domain service)를 들 수 있다. 리눅스의 경우 유닉스와 마찬가지로 named라는 데몬을 이용하게 되고, named 데몬은 모든 시스템에 설치할 필요는 없으며, 하나의 시스템에만 설치하면 된다. 또한 이것을 외부와 연결하기 위해서는 국제적으로 혹은 국내적으로 서비스하는 곳에 등록을 해야 한다.
BIND는 크게 두가지 버전에 존재하는데, named.conf 파일을 사용하는 bind 8과 named.boot를 사용하는 bind 4(BIND version 4)가 있다. 보통 보안에 문제가 있기 때문에 bind 8을 사용한다. BIND에서 named가 처음 기동될 때는 마스터 파일의 모든 설정을 내부 캐쉬로 읽어 들인 후 외부나 내부에서 이름 해석 요청이 들어오면 이를 처리하는 방식으로 구동된다.
1) FLAT Name Service
internet이 수백개의 host만으로 이루어져 있을 때는 host name이 중앙 집중적으로 관리되었다. 새로운 이름을 추가하려면 NIC(Network Information Center)에 새로운 이름을 보내주면 되었다. NIC는 HOSTS.TXT 파일을 검색하여 같은 이름을 확인하고 새로운 host name이 유일하다고 확인되면 IP 주소와 함께 HOSTS.TXT 파일에 추가한다. 그리고 새로운 hosts 파일이 ftp나 uucp를 이용하여 인터넷 전체에 전파된다. 하지만 이름의 중복(충돌) 가능성, 중앙 집중 관리의 문제, 이름의 배포 문제, 데이터의 일관성을 유지하는 문제들이 잔존하게 된다.
2) FLAT Name Service의 문제 해결
DNS는 중앙 집중적인 name service의 문제를 해결하기 위해 분산 naming 시스템을 도입하였다. 즉,각 호스트에 있는 /etc/hosts 파일을 유지하는 데는 제한이 따르기 때문에 동적인 소프트웨어를 사용하여 계층적인 구조를 이루어서 호스트에 대한 이름 데이터가 즉시 조절 가능하도록 분산시켜 유지 관리하고 root domain 서버는 InterNIC, RIPE, APNIC과 또 다른 국제적 기관이 유지, 관리 하여 일관성 있는 name service를 제공할 수 있도록 한다.
이렇게 계층적으로 설계되고 지역적으로 자동 관리됨으로써 인터넷을 통한 이름의 배포문제가 해결된다.
3) 도메인 계층
호스트에 이름을 부여하는 것은 물리적인 네트워크의 구성(topology)과는 아무런 관계가 없다. 물리적인 네트워크는 모양과 형태가 필요에 따라 자주 변하므로 이와는 ‘독립적’으로 도메인 공간이 형성된다.
도메인은 관리의 분산을 위해 계층적으로 구성된다. 로컬 네트워크에 새로운 시스템이 증설되거나 이름이 바뀔 때 중앙기관에 통보할 필요 없이 간단히 DNS 데이터베이스에서 해당 부분만 변경하면 된다.
도메인 계층은 다음 그림과 같이 구성되어 있다.
최상위 도메인은 “.”으로 표기하는 루트 도메인이다.
하위 트리 구조는 규약에 따라 조직에 관한 도메인과 지역 도메인이 올 수 있다.
조직:
com : 영리단체
edu : 교육기관
gov : 정부기관
net : 통신기관
지역 :
kr : 대한민국
fr : 프랑스
이렇게 계층적으로 이루어진 구조에서 상위 도메인은 하위 도메인에 관한 정보를 유지하고 관리하는 책임을 지게 된다. 루트 도메인은 top 레벨을 , top레벨은 secondary 레벨을 관리한다. 즉, yahoo.com 도메인은 com 도메인의 네임 서버에 등록되어 있고, www.yahoo.com 은 yahoo.com 네임서버에 등록되어 있다. 그러므로 yahoo.com에 새로운 호스트 new.yahoo.com을 등록하려면 yahoo.com 도메인을 관리하는 네임서버에 알려주고 관련 레코드만 수정하면 된다.
이렇게 자신의 하위 도메인에 대해서 유지 관리의 책임을 지는 것을 위임구조라 한다.
4) 도메인 네임의 해석(domain name resolving)
도메인 이름의 해석을 요청하는 클라이언트를 리졸버(resolver)라 한다. 리졸버는 적어도 하나의 네임서버에 접근할 수 있어야 한다.
다음은 클라이언트가 네임서버를 통해 도메인에 해당하는 주소를 얻는 과정이다.
먼저 자신의 로컬 네임 서버에게 www.yahoo.com을 질의한다. 로컬 네임 서버는 자신의 캐쉬에 정보가 있는지 확인하고 없으면 루트 네임 서버에 질의를 한다. 루트 네임 서버는 자신이 질의에 대한 해답을 주지 못하므로 com도메인의 주소를 넘겨준다. 로컬 네임 서버는 다시 com 도메인 네임 서버에 질의를 하고 yahoo.com 의 주소를 받아서 다시 yahoo.com에 질의를 한다. 이 결과를 클라이언트에 넘겨주면 이 주소로 www.yahoo.com 을 찾아갈 수 있다.
2. 네임 서버의 구축
네임 서버는 Primary, Secondary, Cache only server로 구분된다.
1) 네임 서버의 개념
Primary server는 해당 도메인을 관리하는 주 네임 서버이고, Secondary server는 특정 도메인에 대한 back-up 사본을 유지하는 서버이다. Secondary 서버는 주 네임서버가 다운될 때를 위한 대비와 부하를 분산시키는 역할을 한다. 이를 master와 slave라고 부르기도 하는데, 이들의 작용 방식을 보면 모든 데이터는 마스터 파일이나 데이터 파일에서 그 도메인 시스템을 사용하는 호스트에게로 뿌려진다. 이 마스터 파일은 로컬 시스템 관리자가 유지하도록 되어 있다. zone의 변경은 primary server에서 이루어지고 서버는 시작할 때 마스터 파일의 데이터를 복사하여 load한다. Secondary는 zone을 위한 데이터를 복사하고 유지하며 주기적으로 primary 서버를 체크하여 zone을 갱신한다. 즉, primary 서버로부터 갱신된 복사본을 얻게 된다. 클라이언트는 자신의 요청이 primary 서버로 가는지, secondary 서버로 가는지 알지 못한다.
그리고 caching server가 있는데, 신뢰할 만한 복사본을 가지고 있지는 않지만, 요청에 빨리 대응할 수 있다. 보통 이름 해석 과정에 소요되는 시간을 줄이기 위해 로컬 네임 서버는 방금 획득한 정보를 로컬 캐쉬에 저장하게 된다. 그러므로 누군가가 특정 사이트에 접속을 시도하려고 할 때 로컬 서버가 로컬 캐쉬에 저장된 정보를 이용해서 해당 호스트의 IP 주소를 바로 알려준다. 하지만 캐쉬의 속성상 저장된 정보가 영구적으로 보관되는 것은 아니기 때문에 일정 시간이 지나면 자동적으로 지워지게 된다. 캐쉬에 저장되었다가 사라지는 시간까지를 TTL(Time To Live)라고 하며, 각각의 zone을 관리하는 DNS 서버에서 임의로 지정할 수 있다.
2) DNS 데이터베이스
일반적으로 DNS는 특정 호스트의 IP 주소만을 알려주는 이름 해석 역할만을 수행한다. 그러나 네임 서버끼리도 정보를 서로 교환하게 되는데, 실제 DNS 데이터베이스 내부는 다양한 형태의 구성 요소들을 가지고 있다.
DNS 데이터베이스에서 하나의 정보를 “자원 레코드(resource record)”라고 하며, DNS가 제공하는 정보의 최소 단위가 된다. 자원 레코드에는 데이터의 종류를 나타내는 데이터형과 레코드가 적용될 네트워크 타입을 지정하는 클래스가 있다. 나중의 클래스는 다른 주소 체계를 위한 것으로, IN 클래스의 경우에는 IP 주소 체계의 적용되고, MIT의 커브로스(Kerberos) 시스템을 위해서는 Hesiod 주소 체계 등이 사용된다. 자원 레코드의 기본형은 A 레코드로 IP 주소를 FQDN과 연관을 시키게 된다.
3) 클라이언트 (client resolver) 설정
호스트의 이름 혹은 서비스의 이름을 IP 주소로 변환시켜 주는 기능을 가진 시스템 혹은 C 라이브러리의 이름이나 서비스가 필요한 프로그램을 resolver라 한다. 정확한 의미에서의 resolver는 표준 C 라이브러리에 해당한다. 그래서 리졸버에 대한 매뉴얼(#man resolver)를 살펴보면 DNS와 관련된 각종 C 라이브러리에 대한 설명들을 볼 수 있다. 그 중에서 가장 핵심은 gethostbyname()과 gethostbyaddr()이다. 이들의 기능은 해당 라이브러리의 이름에서 의미하는 것과 같이 “호스트의 이름”으로 시스템을 찾고, “호스트의 주소”로 시스템을 찾게 된다. 이 함수들은 DNS, /etc/hosts 파일, NIS 등을 참조해서 시스템이나 서비스를 찾게 된다.
위의 함수들이 호출될 때 참조하는 파일은 리눅스 표준 라이브러리 버전에 따라 다르게 되는데, 이전부터 사용하던 libc가 사용자의 시스템에 설치되어 있다면 /etc/host.conf 파일을 읽게 되고, 최근에 등장한 GNU 표준 라이브러리의 두번째 버전인 glibc를 사용할 경우에는 /etc/nsswitch.conf 파일을 참조하게 된다.
하지만 일반적으로 resolver인 클라이언트가 참조하는 파일은 /etc/host.conf, /etc/resolve.conf 파일이며 네임서버를 설정하기 위해 /etc/resolv.conf 파일을 수정한다. 클라이언트의 이름 서비스는 /etc/host.conf 파일이 조절한다.
1] /etc/host.conf
[root @edu00 linux]#vi /etc/host.conf
order hosts, bind
이 파일은 도메인 서비스를 필요로 하는 클라이언트가 참조할 순서를 정해준다. 외부에서나 내부에서 호스트 이름에 대한 해석이 요구되면 가장 먼저 / etc/hosts 파일을 참조하고, hosts 파일에서 이름에 대한 해석이 불가능하면 다음 순서로 bind를 이용하라는 의미이다. bind 항목을 가지고 있으면 (/etc/resolve.conf 의 정보에 따라) 서버에게 질의를 보낸다. 네트웍에 참여하고 싶은 컴퓨터는 반드시 resolving 서비스를 이용하도록 설정될 필요가 있다
(1) 옵션
다음은 host.conf 파일에 사용되는 옵션들이며, 옵션이 사용될 때는 반드시 한 줄에 하나씩만 사용되어야 한다. 옵션과 옵션에 해당하는 데이타값은 공백으로 분리되어야 하며, 다른 설정파일처럼 #으로 시작하는 줄은 주석으로 처리된다.
| 옵션 | 설명 |
| order | 이름 해석의 순서를 지정하는 것으로, bind 값은 /etc/resolv.conf 파일에 지정된 네임서버(name server)에 이름 해석을 요청하고, hosts 값은 /etc/hosts 파일을 참조하도록 하고, nis/nisplus의 경우네는 NIS/NIS+를 참조하도록 한다. |
| multi | 멀티홈 호스트를 위해 모든 가능한 주소가 반환되도록 지정하는 것으로 하나의 호스트에 대해 /etc/hosts 파일내에 여러 개의 IP 주소가 있는 경우에 사용하는 옵션으로, DNS나 NIS를 사용할 경우에는 쓸모가 없다. 값으로는 on/off를 가지면 기본값은 off이다. |
| nospoof | 네임 서버가 잘못된 이름을 해석하여 제공해 주기 위한 시도를 spoofing이라고 하는데, 이를 방지하고 해석기가 호스트 이름과 IP 주소가 정말 일치하는지 검사하도록 설정할 필요가 있을 경우에 nospoof on으로 설정하면 된다. |
| alert | on/off로 설정되며, on으로 설정된 경우 spoof에 대한 시도가 있을 경우 syslog를 이용해 메시지를 남기게 된다. |
| trim | 호스트 이름을 검색할 때 도메인 명을 제거할 필요가 있을 때 사용한다. 즉, 로컬 호스트에 대한 검색을 하면서 로컬 도메인 명을 전달할 필요는 없기 때문에, 로컬 도메인 명을 제거하고 호스트명만을 전달하여 검색하도록 할 때 유용하다. |
(2) 환경 변수
/etc/host.conf 파일에서 정의된 내용들은 환경 변수에 의해서 변경될 수 있다. 즉, 다음의 환경 변수가 사용자 로그인 당시에 정의되었다면 /etc/host.conf 파일보다 먼저 적용된다.
다음은 환경 변수명들에 대한 설명이다.
| 변수명 | 설명 |
| RESOV_HOST_CONF | /etc/host.conf 파일 대신에 읽어들일 파일을 지정 |
| RESOV_SERV_ORDER | order 옵션과 같은 기능을 하며, hosts, dns, nis 등이 공백이나 쉼표, 세미콜론(;)에 의해서 구분된다. |
| RESOV_SPOOF_CHECK | 기본적으로 off이며, nospoof 옵션과 같은 기능을 수행 |
| RESOV_MULTI | multi 옵션과 같은 기능을 수행하며 on/off 값을 가짐 |
| RESOV_OVERRIDE_TRIM_DOMAINS | trim 옵션과 같은 기능을 수행 |
| RESOV_ADD_TRIM_DOMAINS | 이름을 해석할 때 생략할 도메인 명을 추가 |
2] /etc/resolv.conf
클라이언트에서 BIND가 설치된 DNS를 이용해서 호스트 이름을 해석하려면 어떤 네임서버를 이용할 것인지를 지정해야 하는데, 이때 사용되는 파일이 /etc/resolv.conf 파일이다. 하지만 시스템에 이 파일이 존재하지 않거나 파일의 내용이 비어있다면 응용 프로그램은 로컬 호스트를 네임서버로 생각하게 된다. 따라서 반드시 둘(/etc/resolv.conf 파일이나 named 데몬) 중의 하나는 있어야 인터넷을 사용할 수 있다. 만약 로컬 네트워크에 DNS 서비스를 제공하는 네임서버가 존재하거나 모뎀을 이용해 ISP(Inernet Service Provider)에 연결할 경우에는 반드시 /etc/resolv.conf 파일을 채워야 한다.
[root @edu00 linux]#vi /etc/resolv.conf
search edu00.net dacom.com
nameserver 192.168.1.1
nameserver 210.181.87.2
naming 서비스를 필요로 하는 서비스가 시작될 때마다 /etc/resolve.conf를 찾아보고 프로세스가 동작하는 동안 그 정보를 사용하게 된다. search 라인은 네임서버에 질의하기 전에 호스트명을 확장하는데 사용되는 도메인 목록을 적어준다. 예를 들어 edu00.net이라는 도메인이 있을 때, ping edu00.net하면 nameserver에 질의하기 전에 edu00.net을 먼저 찾아본다. 주된 기능은 매번 이름 전체를 타이핑하는 수고를 덜어주는 것이다. 최대 6개의 도메인 이름을 공백으로 구분하여 넣을 수 있다.
nameserver <xxx.xxx.xxx.xxx> 라인은 네임 서버를 지정한다. 네임 서버는 3개까지 지정할 수 있는데, 나열된 순서대로 질의한다. 따라서 가장 신뢰할 수 있는 네임 서버를 가장 앞에 기록하는 것이 좋다.그리고 세 개의 nameserver 항목이 모두 질의를 받으면 시간이 오래 걸리므로 바람직하지 않고 보통 2개 정도면 충분하다.
/etc/resolv.conf 파일이 없으면 로컬 도메인을 “추측(guess)" 하기위해 hostname 명령을 사용하는데 그 결과가 www.edu00.net이라면 default 도메인은 edu00.net이 된다. 이때 default 설정이 사용되면 로컬 호스트가 name 서버라고 가정한다. resolv.conf에 nameserver 항목이 없기 때문이다.
(1) domain
/etc/resolv.conf 파일에 사용될 수 있는 다른 항목들은 domain과 search로, 로컬 도메인에서 검색을 할 때 유리하게 동작하도록 하는 역할을 한다.
예를 들어 linux.edu00.net이라는 호스트가 있고, /etc/resolv.conf 파일내의 domain 항목에 edu00.net이라고 지정을 해두면, 현재 로컬 도메인에서 linux라는 이름을 갖는 호스트의 IP 주소만을 찾으면 되기 때문에 빠른 해석이 가능하다. 뿐만 아니라 로컬 도메인 내에서 다른 시스템으로 연결할 필요가 있을 때 도메인 이름을 모두 사용하기 않고 단순히 linux라고 호스트의 이름만을 사용하더라도 쉽게 연결을 할 수 있기 때문에 편리하다. 즉, 도메인 내에서 이름을 해석하고자 할 때, 응용 프로그램에서 자동적으로 로컬 도메인 이름을 추가해서 찾아주기 때문에 편리하다. 만약 로컬 도메인 내에 linux라는 호스트를 검색하고자 하는데, /etc/resolv.conf 파일에 domain 항목이 없다고 하자. 그럼 호스트 이름 해석 작업을 실패로 끝나게 된다. 하지만 /etc/resolv.conf 파일의 domain 항목에 “edu00.net”이라는 값을 부여해 두었다면 이름 해석 작업은 성공하게 될 것이다.
(2) search
만약 다른 도메인에 속한 호스트를 편리하게 찾고자 한다면 /etc/resolv.conf 파일 내의 search를 이용해서 검색할 도메인 리스트를 나열하면 된다.
다음의 예를 보자.
| domain edu00.net search edu00.net linux00.net nameserver 164.124.101.2 nameserver 192.168.10.2 |
edu00.net이라는 도메인에는 public이라는 이름을 갖는 시스템이 없고 linux00.net이라는 도메인에 소속되어 있다면 $telnet public라고 명령을 내리면 자연스레 public.linux00.net 시스템에 연결이 이루어진다.
위의 과정은 다음의 순서대로 이름이 해석된다.
자신이 속한 도메인이 edu00.net이기 때문에 응용 프로그램은 가장 먼저 자신의 도메인 내에서 public이라는 시스템에 대한 IP 주소를 찾게 된다. 하지만 DNS에서는 그런 이름을 가진 시스템이 edu00.net 도메인에는 존재하지 않음을 알려주게 된다. 그럼 다시 search 항목에 있는 linux00.net 도메인에서 public이라는 시스템을 찾게 된다. 성공하게 되면 telnet은 연결이 될 것이고, .linux00.net에서도 public이라는 시스템에 대한 이름 찾기에 실패했다면 “unknown host”라는 오류 메시지가 화면에 출력될 것이다. 이름 해석이 진행되는 과정은 search 항목 다음에 나오는 도메인 리스트 중에서 왼쪽부터 오른쪽으로 차례대로 검색하게 된다.
(3) nameserver
nameserver 항목은 사용할 DNS 서버의 IP 주소를 나타내게 된다. 만약 자신이 속한 도메인에서 둘 이상의 네임 서버를 사용할 경우에는 이 항목을 둘 이상 사용하여 각각의 DNS 서버의 IP 주소를 기록하면 된다. 이 경우 첫번째 네임 서버에 접근이 되지 않거나 정상적인 동작이 이루어지지 않을 경우에 다음 줄의 네임 서버에 접속을 시도하게 된다.
만약 /etc/resolv.conf 파일에 아무런 항목도 제시되지 않는다면 해석기는 getdomainname()이라는 시스템 호출을 이용해 로컬 호스트가 속한 로컬 도메인의 이름을 이용하게 된다.
3] /etc/nsswitch.conf.
GNU의 표준 라이브러리의 두번째 버전인 glibc를 이용할 경우에 사용되는 파일로, /etc/host.conf 파일에 비해 훨씬 강력하고 융통성이 있다. 단순히 호스트 이름을 해석하기 위해서만 사용되는 /etc/host.conf 파일에 비해, 패스워드나 프로토콜 등에 대한 다양한 해석 방법을 지정할 수 있기 때문이다.
/etc/host.conf 파일에서와 마찬가지로 각각의 옵션들은 한 줄을 차지해야 하며, 옵션에 해당하는 값들은 공백이나 탭 등으로 구분되고, 주석은 #으로 시작하게 된다.
파일 내부의 형식은 다음과 같다.
service : hostname resolution
첫번째 service 항목은 서비스 데이터베이스를 지정하고(서비스 명 다음에는 반드시 콜론[:]) 두번째 hostname resolution 항목은 해당 서버스를 어떤 방법을 이용해서 호스트 명을 찾을 것인지를 지정하게 된다.
예를 들어보자.
| hosts: dns files networks: files [NOTFOUND=return] nisplus |
먼저 호스트(hosts)에 대한 해석이 필요한 경우 먼저 DNS를 검색하게 되고, DNS에서 찾지 못할 경우 /etc/hosts 파일을 이용해서 호스트 이름을 해석하라는 의미이다.
그리고 네트워크(networks)의 이름을 검색할 때, 가장 먼저 /etc/networks 파일을 이용해서 검색을 하고, /etc/networks 파일에서 찾지 못했을 경우(NOTFOUND)에는 즉시 해석 작업을 멈추라는 것을 의미한다.
(1) 옵션
| 옵션 | 설명 |
| Dns | 호스트 이름을 해석하기 위해서 DNS를 사용하도록 지정. DNS의 경우에는 호스트 이름에 대해서만 해석이 가능하고, 네트워크 이름에 대해서는 해석이 불가능하다. dns가 지정되면 /etc/resolv.conf 파일을 참조하게 된다. |
| Files | 호스트나 네트워크 이름을 해석하기 위해서 /etc 디렉토리에 포함된 파일들(hosts, networks)를 사용하도록 한다. |
| nis/nisplus | 호스트 이름과 네트워크 이름을 해석하기 위해서 NIS/NIS+를 사용하도록 지정 |
| compat | 오래된 파일 형식과의 호환을 위한 것이다. |
| db | /var/db 디렉토리에 존재하는 DBM 파일로부터 정보를 읽어오도록 지정하는 옵션으로, NIS 맵 파일이 DBM 파일을 이용할 때 사용하는 옵션 |
/etc/nsswitch.conf 파일에서 서비스 이름 다음에 나열되는 순서대로 호스트 이름이나 네트워크 이름에 대해서 해석이 이루어진다. 그래서 /etc/host.conf 파일에처럼 order라는 옵션은 필요가 없다. 또한 순서대록 검색하는 과정에서 해석이 성공하게 되면 그 즉시 해석 과정이 중단된다.
(2) 행위 항목(action item)
위의 예에서 []속에 지시어가 포함되어 있는데, 이(action_item라 하는데, “행위 항목”이라 하자)는 앞에서 이루어진 해석 결과를 이용하는 것이다. 행위 항목은 반드시 [] 형식으로 해야 하며, 그 안에 해석 방법이 존재해야 한다.
다음은 사용 방법이다.
| service : resolution1 [ [!] status = action …] resolution2 |
행위 항목은 return과 continue가 있으며, return의 경우에는 이름 해석을 요구한 프로그램에게 제어권을 넘기게 되고, 이름 해석이 성공적이면 자세한 사항을 함께 리턴하고, 그렇지 않으면 0(zero)를 리턴한다. continue 행위 항목은 앞쪽의 이름 해석 과정(resolution1)이 어떻든지 다음의 이름 해석 과정(resolution2)으로 넘어가게 된다.
다음은 행위 항목과 함께 사용되는 status 항목으로 앞쪽의 이름 해석 과정의 상태가 어떠한지를 나타내며 아래의 값들이 올 수 있으며, status 앞에 !는 “NOT”을 의미한다.
| 상태 | 상태에 대한 설명 |
| SUCCESS | 이름 해석 과정이 오류 없이 성공적인 해석이 이루어졌을 경우에 반환되는 상태로 이에 대한 기본 행위 항목은 return이다. |
| NOTFOUND | 이름 해석 과정에서 오류는 없지만 호스트나 네트워크를 찾지 못한 경우에 반환되는 상태로 기본 행위 항목은 continue이다. |
| UNAVAIL | 제시된 이름 해석 방법을 사용할 수 없을 때 반환되는 상태로, hosts, networks 파일을 읽지 못하거나, DNS 혹은 NIS 등의 서비스를 이용할 수 없을 때 반환되며, 기본 행위 항목은 continue이다. |
| TRYAGAIN | 이름 해석을 잠시동안 사용 못할 경우에 반환되는 상태로, 파일에 대한 경우에는 다른 프로세스가 파일을 잠그고(lock) 있는 상태일 때 발생하며, DNS나 NIS의 경우에는 잠시동안 서비스가 불가능할 경우이다. 이 상태에 대한 기본 행위 항목은 continue이다. |
4) 이름 역해석(Reverse Lookup)
이름의 역해석은 호스트의 이름을 가지고 IP 주소를 찾는 과정의 역과정이다. 즉, IP 주소를 이용해서 호스트의 공식 명칭을 찾거나 서비스 이름을 찾는 과정을 의미한다. 이렇게 호스트의 이름을 찾는 과정을 reverse mapping이라고 한다.
hosts 파일만을 이용할 경우에는 이름 역해석도 시간이 많이 소모되는 작업은 아니다. 단순히 텍스트 파일만을 검색하면 되기 때문이다. 하지만 DNS를 사용해서 역해석 과정을 수행하려면 특별히 고안된 도메인을 사용하는데, 이는 in-addr.arpa라는 이름을 가지고 다니게 된다. 그리고 이 이름 앞에는 모든 호스트의 IP 주소가 역순으로 붙게 된다. 예를 들어 111.222.11.22의 IP 주소는 22.11.222.111.in-addr.arpa에 해당한다.
zone을 생성할 수 있는 권한을 가지고 있다는 것은 이름을 주소에 할당할 수 있는 완전한 권한을 가지고 있음을 의미하며, 그 결과 관리자는 하나나 둘 이상의 IP 네트워크 주소 혹은 서브넷을 관리하게 되고, DNS의 zone과 IP 네트워크 사이에는 일대 다의 관계가 성립할 수 있다. 예를 들어 linux는 222.222.222.0, 222.222.223.0, 222.222.224.0 등의 네트워크로 구성될 수 있다.
즉, in-addr.arpa 도메인에 속하는 새로운 zone은 linux라는 zone이 생성될 때 함께 생성되어야 하며, 222.222.222.in-addr.arpa, 223.222.222.in-addr.arpa, 224.222.222.in-addr.arpa zone을 관리하는 관리자에게 권한을 위임할 수 있다. 그렇지 않으면 특정 zone에서 새로운 시스템을 추가할 때마다 상위 도메인 관리자에게 연락을 해서 새로운 주소를 부여받아야 할 뿐만 아니라 in-addr.arpa에도 추가를 해야 하는 불편함이 존재한다.
In-addr.arpa 시스템에서 zone은 IP 네트워크의 슈퍼셋(superset)으로만 생성될 수 있다. 즉, 네트워크의 서브넷 마스크가 바이트 단위로만 경계가 구성된다는 것이다. 예를 들어 linux의 경우에 255.255.255.0이라는 서브넷 마스크를 가지기 때문에 하나의 서브넷이 각각의 in-addr.arpa zone으로 구성될 수 있다. 하지만 서브넷 마스크가 255.255.255.128이 사용된 경우(C 클래스를 두개의 서브넷으로 나눌 경우)에는 222.222.222.128에 해당하는 zone을 생성할 수 없다. 이유는 222.222.222.in-addr.arpa 도메인을 1부터 127까지와 128부터 255까지의 두 zone으로 나눌 수 가 없기 때문이다.
3. 네임 서버의 설정(CONFIGURATION THE DOMAIN NAME SERVER
주 설정 파일 : /etc/named.conf
[root @edu00 linux]#vi /etc/named.conf
options {
directory “/var/named”;
};
zone “.” in {
type hint;
file “named.ca”;
};
zone “edu00.net” in {
type master;
file “edu00.zone”;
};
zone “edu.edu01.net” in {
type slave;
file “edu.bak”;
masters { 192.168.1.254; };
};
-----------------------------------
이 파일에서 가장 중요한 두 부분은 option과 zone이다.
1] option 섹션
option 섹션은 option { }; 모양으로 네임 서버에 대한 전체적인 옵션을 설정해준다.
정의 가능한 인수들
directory : named의 zone 파일들이 위치하는 작업 디렉터리를 정의하는 것으로, 파일 이름만 제공되는 것들은 모두 이 옵션으로 지정된 디렉토리 아래에 존재하게 된다. 보통 /var/named이다.
forwarders : 이 옵션은 공백으로 분리된 주소들을 인자로 가지는데, 이 주소들은 로컬 캐쉬에서 주소를 해석하려고 시도했을 때 실패하게 되면 연결하게 될 네임 서버의 IP 주소들이다. 이름 해석이 성공할 때까지 앞에서부터 차례대로 각 네임 서버로 접속을 시도하게 된다. 일반적으로 네트워크 서비스 제공자가 사용하는 네임 서버를 사용하거나 잘 알려진 네임 서버를 사용하면 좋다. 이 옵션은 자신의 캐시에서 resolve되지 않는 질의를 지정된 다른 서버에게 보내도록 로컬 서버에게 알려준다.
dump-file : SIGINT 호출로 정보가 dump되는 곳을 지정한다.
pid-file : PID가 저장되는 파일의 위치를 지정한다.
dial-up : zone 정보를 가능한 한 짧은 시간 안에 집중시켜서 dial-up 갱신을 감소시킬지 여부
notify : default는 yes로 다른 권위있는 서버에게 메시지를 보낼지 여부, 보통 directory만 정의하여도 충분하다.
2] zone 섹션
zone 섹션은 zone “도메인” { 구문1 ; 구문 2 ; }; 형식이다. 모든 네임 서버는 zone 정보를 유지하고 있으며 네임서버가 서비스하는 zone을 정의하는 부분이다.
정의 가능한 인수들
type 네임서버의 type을 결정(hint, master, slave 등)한다.
file zone을 위한 도메인 정보의 자원을 정의하는 파일을 지정한다.
master slave server에서 zone정보를 검색(retrieve)할 마스터 서버를 정의한다.
4. 기본 서버 구축
[root @edu00 /home]#vi /etc/resolv.conf
search edu00.net dacom.com
nameserver 192.168.0.10
# 호스트 시스템을 네임서버로 설정하기 위해 자신의 IP를 적는다.
#nameserver 192.168.0.254
name server의 IP를 주석으로 막는다.
[root @edu00 /home]#vi /etc/hosts
127.0.0.1 localhost.localdomain localhost
192.168.0.10 edu00.net edu00
[root @edu00 /home]#cat /etc/host.conf
네임서버 질의 순서를 설정한다. 일반적으로 /etc/hosts 파일을 먼저 검색한 후 name server를 이용한다.
[root @edu00 /home]#cat /etc/nsswitch.conf
질의 순서를 보안을 염두에 두고 설정한 파일이다.
[root @edu00 /home]#cp /var/named/named.local /var/named/edu00.zone
[root @edu00 /home]#cp /var/named/named.local /var/named/edu00.rev
[root @edu00 /home]#vi /etc/named.conf
option {
directory "/var/named"
# zone 파일에 대한 기본 디렉토리
};
zone "." {
# cache 파일에 대한 정의
type hint;
# root nameserver의 주소를 제공하는 zone 파일을 규정
file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
# localhost를 위한 주 도메인 설정
type master;
file "named.local";
};
zone "edu00.net" {
type master;
file "edu00.zone";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "edu00.rev";
};
[root @edu00 /home]#vi /var/named/edu00.zone
@ IN SOA ns.edu00.net. root.edu00.net.
(....... .생략
)
IN NS ns.edu00.net.
IN NS ftp.edu00.net.
IN MX 10 mail.edu00.net.
IN A 192.168.0.10
# A는 Address의 의미로 호스트 이름에 IP주소를 매핑시킨다.
NS IN A 192.168.0.10
Mail IN A 192.168.0.10
www IN A 192.168.0.10
ftp IN A 192.168.0.10
[root @edu00 /home]#vi /var/named/edu00.rev
@ IN SOA ns.edu00.net. root.edu00.net.
(
....... 생략
)
IN NS ns.edu00.net.
IN NS ftp.eduxx.net.
10 IN PTR ns.edu00.net.
IN PTR www.edu00.net.
IN PTR ftp.edu00.net.
IN PTR mail.edu00.net.
[root @edu00 /home]#/etc/rc.d/init.d/named start
[root @edu00 /home]#nslookup
>ftp
>set type=ns
>chollian.net
>exit
[root @edu00 /home]#nslookup -type=a www.ttl.co.kr ns.yahoo.co.kr
[root @edu00 /home]#dig www.yahoo.co.kr
[root @edu00 /home]#host www.yahoo.co.kr
[root @edu00 /home]#whois linuxone.co.kr
5. DNS 작동 방식
1) 도메인 네임 스페이스(Domain Name Space)
도메인 네임 공간은 UNIX Filesystem 구조와 비슷한 트리구조이며 UNIX Filesystem과 동일한 방법으로 root로부터의 절대적인 경로와 어떤 위치로부터의 상대적인 경로가 있다. 하지만 보통 URL을 표시할 때는 절대경로로서 표기한다.
"www.edu00.co.kr."으로 표기하는데, 일반적으로 "."을 생략한다. 그리고 인터넷상의 네임 공간에서 하나의 위치, 즉 edu00과 같은 하나의 노드를 도메인(domain)이라 한다.
도메인이 하나의 서브트리를 형성할 수도 있다. 또한 edu00같은 하나의 도메인 노드는 가지가 다르다면 중복되어도 상관없다.(예:/bin과 /usr/bin)
2) Zone & Delegation(위임)
인터넷에서의 네임 공간은 root 도메인(.)밑으로 top level 도메인들(com, edu, net, org 등과 kr, jp 등의 지역도메인)이 있고, 밑으로 second level, third level(이하는 보통 서브 도메인) 도메인이 트리 구조를 이루고 있다. 이런 구조는 도메인 네임의 분산관리를 위해서 필요하다. 도메인 네임의 분산관리는 권한의 위임(delegation)으로 이루어진다.
하나의 도메인을 KRNIC에 신청하고 받아오는 일련의 과정은 신청한 도메인에 대한 권한과 책임을 넘겨받는 절차라 할 수 있다. 즉, "edu00.co.kr"이라는 도메인을 신청하고 받아왔다면, 전체 네임공간에서 하나의 노드를 위임받아 운영하게 되었음을 말하는 것으로, 받아온 네임영역에 관해서는 권한을 행사할 수 있고(www.edu00.co.kr이라는 호스트를 임의로 지정하고, ttl.edu00.co.kr이라는 하부도메인을 다시 위임하고...), 받아온 네임영역에 대해서는 정확한 정보를 제공해야 한다.
3) Resolution(해석)
URL은 도메인 네임이라는 문자주소이므로, 브라우져와 같은 클라이언트 프로그램들이 웹서버에 접속하기 위해서는 웹서버의 IP주소를 알아야 한다. 그런데, 도메인네임/IP주소 변환작업을 브라우져가 할 수 없기 때문에, resolver를 통해서 네임서버에게 문의하게 된다. 문의를 받은 네임서버는 네임공간을 뒤져서 답을 얻고 resolver를 통해서 클라이언트 프로그램에게 알려주어, 클라이언트가 웹서버에 접속할 수 있다.
참고
URL은 Uniform Resource Locator의 약자로 인터넷 상의 각종 자원이 있는 위치를 나타내는 표준 명령 체계로 web 사용자가 원하는 정보를 보기 위해서는 정보가 위치하는 장소를 입력해야 하는데, 이때 입력하는 방법은 URL에 의해 결정된다. URL은 [프로토콜://서버/디렉토리/파일이름:포트]의 형식을 가진다.
4) Resolver의 역할
resolver는 네임 서버에 접근해서 문의하는 클라이언트로서, 도메인 네임 공간의 정보를 필요로 하는 호스트내의 모든 프로그램들이 이 resolver를 이용하게 된다. BIND에서 리졸버는 telnet/ftp 등의 프로그램에 링크되는 라이브러리 루틴의 집합일 뿐, 별다른 기능은 없다. 그래서 프로그램으로부터 요청이 오면 무조건 네임서버로 질의를 던진다.
(1) 네임서버에게 질의(query)를 보낸다.
(2) 응답(리소스 레코드/에러)을 해석한다.
(3) 요청했던 프로그램(브라우져)에게 정보를 보낸다.
1] 참조 순서 결정
[root @edu00 linux]#vi /etc/host.conf
order hosts,bind
[root @edu00 linux]#cat /etc/nsswitch.conf
클라이언트의 이름 서비스는 /etc/host.conf가 조절한다. 즉 이 파일은 이름 서비스를 필요로 하는 클라이언트가 참조할 순서를 정해준다. 먼저 /etc/hosts 파일을 참조하고 다음 bind를 이용하라는 의미이다. bind 항목은 /etc/resolv.conf의 정보에 따라 서버에게 질의를 한다. 네트워크에 참여하고 싶은 컴퓨터는 반드시 resolving 서비스를 이용하도록 설정될 필요가 있다.
하지만 Library 버전에 따라 /etc/host.conf 파일과 /etc/nsswitch.conf 파일을 주의할 필요가 있다. 라이브러리 버전에 따라 이 두개의 파일에 참조 우선권이 있기 때문이다.
2] 네임서버 등록
[root @edu00 linux]#vi /etc/resolv.conf
search edu00.net dacom.com
nameserver 192.168.1.1
nameserver 192.168.1.2
5) NameServer의 역할
(1) 네임서버 자신이 authority(권한)를 갖는 영역에 대한 정보를 서비스한다.
(2) authority를 갖지 않은 영역에 대한 정보를 얻기 위해 네임공간을 돌아다닌다.
(3) 질의했던 내용을 기억하고, 유사한 요청시 신속한 응답을 준다.
6) Zone Transfer
nslookup을 실행한 후 ls 명령어를 이용하여 영역 전체를 모두 전송해 올 수 있다. 장애처리를 할 때, 원격 호스트의 이름이 잘 기억나지 않을 때, 그 도메인에 얼마나 많은 호스트가 있는지 확인할 때 사용한다.
현재는 대부분의 호스트들이 보안상의 이유나 네임서버의 부하때문에 영역정보를 가져가지 못하도록 설정해 놓고 있다.
[root @edu00 home]#nslookup - ns.yahoo.co.kr
....
>ls -d yahoo.co.kr > yahoo.co.kr
....
[root @edu00 home]#vi yahoo.co.kr
이런 형식의 설정이 가능했지만 현재는 ls 명령에 대해 제한을 가한 상태이기 때문에 적용은 되지 않는다.
6. 네임서버 설정의 기본사항
네임서버는 두가지 역할을 한다. 첫번째는 도메인 공간에서 할당받은 하나의 도메인 영역(자신이 Authority를 갖는 영역)에 대해서 정보를 서비스한다. 두번째는 Authority를 갖지 않은 영역에 대해서는 정보를 얻기 위해서 네임공간을 돌아다니게 된다.
다음의 두 파일은 네임 서비스에 대한 기본 설정 파일들이다.
존 정의를 위한 파일 -> /etc/named.conf
정의된 존에 대한 DB 파일들 -> /var/named 디렉토리
다음은 자원 레코드와 각각의 레코드 타입에 대한 사항을 알아보고 이러한 레코드를 이용해서 캐쉬 네임 서버와 마스터 네임 서버에 대한 기본 설정 사항을 점검한다.
1) 자원 레코드(RR : Resouce Records)
마스터 파일에 포함된 데이터는 자원 레코드(RR : Resouce Records)로 구분된다.
RR은 DNS를 통해 사용할 수 있는 최소의 정보 단위이다. 각 RR은 호스트 이름을 IP 주소에 매핑시키는 A 타입 레코드, 공식 호스트 이름에 대한 별칭을 제공하는 CNAME 레코드 등을 갖게 된다.
다음은 자원 레코드에 대한 형식이다.
[domain] [ttl] [class] type rdata
각각의 필드는 공백이나 탭으로 구분되며, 괄호({})를 사용하게 되면 여러 줄을 하나의 자원 레코드로 등록시킬 수 있다. 여러 줄을 사용할 경우 세미콜론 다음의 내용은 모두 무시된다.
다음은 각 항목들이다.
| 항목 | 설명 |
| domain | 자원을 사용하게 될 도메인 이름을 의미한다. 만약 도메인 이름이 주어지지 않는다면, 해당 자원 레코드는 이전 자원 레코드가 적용된 도메인에 적용하게 된다. |
| ttl | 일정 시간 내에 이름 해석을 못한 경우에는 리졸버의 정보를 제거하기 위해서 각각의 자원 레코드는 ttl(time to live)를 가진다. ttl은 네임 서버로부터 제공된 정보가 유효한 시간을 초단위로 설정하는 것으로 10진수로 표현된다. ttl이 주어지지 않았다면 SOA 레코드에서 설정된 최소의 시간이 기본값으로 설정된다. |
| class | IP 주소를 위한 IN처럼 주소 클래스로, TCP/IP 네트워크에서는 IN을 지정하면 된다. 클래스가 정의되지 않는다면 이전 자원 레코드의 클래스에 적용하게 된다. |
| type | 자원 레코드의 타입을 설명하는 것으로, 많이 사용되는 타입으로는 A, SOA, PTR, NS, CNAME, MX, HINFO 등이 있다. |
| rdata | 자원 레코드와 연관된 정보를 포함하는 것으로, 자원 레코드의 타입에 따라서 사용형식이 달라진다. |
2) 레코드 종류
1] SOA(Start of Authority) 레코드
zone 데이터 파일은 항상 SOA 레코드로 시작한다. 이 레코드는 네임 서버가 항상 최적의 상태로 관리되도록 해준다. @은 자기 자신을 참조하며 FQDN 형식의 호스트네임이다.
다음으로 필드의 내용을 보면
origin은 해당 도메인의 주 네임 서버의 공식적인 호스트 이름을 나타낸다.
contact은 도메인 관리자의 E-mail 주소를 나타낸다. 단 주의할 것은 E-mail에서 사용되는 @은 점(.)으로 변경되어야 한다.
serial은 숫자로 표현되며, zone 파일의 버전을 의미한다. zone 파일의 데이터가 변경될 때마다, 이 숫자는 변경되어야 한다. 통용되는 방법은 zone 파일이 변경된 날짜를 의미하는 숫자를 많이 사용한다. 이 숫자는 secondary 서버가 zone 정보가 변경되었는지를 확인할 때 사용하는 것으로, 부 네임 서버는 최신 정보를 유지하기 위해 일정 시간 간격으로 주 네임 서버의 SOA 레코드 중에서 serial을 비교해서 업데이트를 하게 된다. 예를 들어 부 네임서버의 캐쉬에 존재하는 serial 번호와 주 네임 서버의 serial 번호가 다르면 주 네임 서버로부터 zone 데이터베이스를 가져오게 된다. 그렇기 때문에 반드시 zone 파일의 변경 후 serial을 변경시켜야만 부 네임서버에 영향을 줄 수 있다. 부 네임 서버가 없다면 이 항목은 의미가 없다.
refresh는 부 네임 서버와 주 네임 서버의 SOA 레코드를 검사하기 위해 기다리는 시간을 초단위로 지정하기 위해서 사용된다. 최대 8자리의 10진수가 사용된다. 일반적으로 네트워크의 위상이 자주 변하지는 않기 때문에 대규모 네트워크에서는 하루 정도를 사용하는 것이 좋다.
retry는 zone 파일을 복사하는 과정이나 부 네임 서버가 주 네임 서버와 연결을 실패했을 때 재시도의 시간 주기를 나타낸다. 여기에 입력되는 값은 refresh 시간보다 짧을 때 의미가 있으며, 일반적으로 한시간이나 한시간 반 정도의 시간을 부여하는 것이 좋다.
expire는 부 네임서버가 주 네임 서버에 연결할 수 없을 때, 얼마동안 부 네임 서버가 가지고 있는 정보를 유효하게 판단할 것인가를 지정하는 것으로, 보통 일주일의 시간(604,800초)을 부여하는데, 한달이나 그 이상이 좋다.
minimum은 명시적으로 지정하지 않았을 때의 기본 ttl값을 지정하는 것으로, 다른 네임 서버가 현재 네임 서버에 포함된 zone 파일을 가져갔을 때 가져간 zone 데이터의 유효기간을 설정한다. 여기서 설정된 시간은 일반적인 이름 해석에 적용되는 것이고, 부 네임 서버가 zone 정보를 업데이트하는 데는 영향을 미치지 않는다. 네트워크의 위상이 자주 변경되지 않는다면 일주일이나 그 이상 지정하는 것이 좋다. 만약 자원 레코드가 자주 변경된다면 각각의 ttl을 작게 설정하는 것이 좋고, 네트워크의 위상이 자주 변경될 때는 이 값을 하루(86,400초)로 설정하는 것이 좋다.
2] NS (Name Server) 레코드
NS 레코드는 zone의 주 네임 서버와 모든 부 네임 서버를 지정하는데 사용된다. NS 레코드가 해당 zone의 주 네임 서버를 지정할 때, 자원 데이터에는 네임 서버의 호스트 이름이 와야 한다. 호스트 이름은 당연히 IP 주소로 해석되어야 한다.
간혹 네임 서버가 서비스하는 도메인에 포함되는 경우에 끝없는 이름 해석 과정을 거치게 된다. 이 경우 상위 zone의 네임 서버에 특별한 A 레코드를 설정함으로써 문제를 해결할 수 있다. 상위 zone의 네임서버에 존재하는 특별한 A 레코드가 무한 루프에 빠진 이름 해석과정을 종식시키게 된다. 이런 레코드를 글루(glue) 레코드라 한다.
그리고 NS는 아주 많은 호스트를 포함하고 있는 도메인에서 하부 도메인에 대한 이름 해석 과정을 다른 네임 서버로 위임할 때 사용할 수도 있다.
3] A(Address) 레코드
호스트 이름에 IP 주소를 연결하는 것으로, 레코드 데이터에는 해당 도메인에 포함된 IP 주소를 입력한다. 각 호스트 이름에는 하나의 A 레코드가 존재해야 한다. A 레코드에 사용된 호스트의 이름은 공식적인 호스트의 이름 혹은 서비스에 사용될 수 있는 이름이어야 한다. 그 이외의 호스트들에 대해서는 CNAME 레코드를 이용해서 공식 이름과 매핑되어야 한다.
4] MX (Mail Exchanger) 레코드
해당 도메인에 대한 메일 라우팅 경로를 지정하는 레코드로, 다음과 같은 사용 형식을 취한다.
| [domain] [ttl] [class] MX priority host |
host는 해당 도메인에서 메일을 서비스하는 시스템이고, priority는 숫자가 기록되는데, 낮은 숫자일수록 우선권이 높다. 외부의 메일 전송 에이전트(MTA: Mail Transfer Agent)는 해당 도메인에 메일을 제대로 전송하기 위해서 MX 레코드에 등록된 모든 호스트에게 메일 전송을 성공할 때까지 시도할 것이다.
아래의 예를 보자.
| edu00.net IN MX 10 mail.edu00.net. IN MX 20 www.edu00.net. mail.edu00.net IN A 222.222.222.4 www.edu00.net. IN A 222.222.222.3 |
위의 예를 참고할 경우 외부에서 guest@edu00.net으로 메일을 보내게 되면 메일은 mail.edu00.net으로 전송이 된다. 만약 mail.edu00.net에 이상이 있어 전송이 불가능하다면 다음으로 www.edu00.net으로 메일을 전송하게 된다.
하지만 다음의 예를 보자.
| mail.edu00.net. IN CNAME www.edu00.net. www.edu00.net. IN A 222.222.222.3 |
위의 예와 같이 MX 레코드에 CNAME으로 설정된 도메인을 넣게 되면 MTA가 메일의 전송 경로를 찾지 못하여 메일 송수신이 불가능하기 때문에 제대로 동작하지 않는다.
5] CNAME (Canonical Name) 레코드
CNAME 레코드는 공식적인 호스트 이름의 별칭과 연관이 있다. 즉, 호스트의 공식적인 이름을 이용해서 또 다른 이름을 사용자에게 제공할 수 있다는 것이다. 호스트의 공식적인 이름은 마스터 파일에서 A 레코드에 의해 제공되는 이름이고, 별칭은 공식적인 이름에 CNAME 레코드를 이용해서 제공된다. 일반적으로 NS, MX 등의 레코드에는 CNAME으로 설정된 도메인을 사용해서는 안된다는 점에 유의하자.
또한 별명이나 별칭을 지정해서 부하 분산 등의 관리를 하기도 한다.
6] PTR(PoinTeR) 레코드
이 레코드는 IP 주소에 대한 도메인 명을 찾을 때 사용하는 것으로, in-addr.arpa 도메인과 연관이 있다. 이름 역해석 과정에서 제공되는 호스트의 이름은 공식적인 이름이 된다.
다음의 예를 보자
| 9.10.168.192.in-addr.arpa IN PTR web.linux.net |
정방향 이름 해석 과정을 제어하는 zone 파일에는 여러 개의 호스트 이름이 A나 CNAME 레코드를 통해 하나의 IP 주소에 매핑이 되지만, PTR 레코드에서는 중복이 허용되지 않기 때문에 하나의 IP 주소에 대한 대표 도메인 명을 하나만 설정하여야 한다.
7] HINFO
시스템의 하드웨어와 소프트웨어 정보를 제공한다.
사용 식은 다음과 같다.
| [domain] [ttl] [class] HINFO hardware software |
hardware 항목은 해당 호스트의 하드웨어에 대한 정보를 제공하기 위해서 사용되는데, 이곳에 사용될 수 있는 기계 이름은 RFC 1700에 정의되어 있다. 하드웨어 이름이 공백을 포함하고 있는 경우에는 반드시 따옴표로 묶어야 한다. Software 항목은 시스템에서 사용하고 있는 운영체제의 이름을 지정하는 것으로 이 역시 RFC 1700에 정의되어 있다.
2) Caching Only NameServer
로컬 네트웍에서의 인터넷 속도를 향상시키기 위해서 로컬 네트웍에 자체적인 네임서버를 구축하게 되는데, 이때 설정하게 되는 서버는 자신이 Authority를 가지고 서비스하는 네임영역은 없고, 단지 도메인네임을 IP 주소로 변환하기 위해 네임공간을 돌아다니며 획득한 정보를 기억하여 다음번 요청에 신속하게 답을 줄 수 있도록 하기 위함이다. /var/named/named.ca는 루트 네임 서버에 대한 정보(이름과 주소)를 가지고 있는 데이터베이스 파일(캐시 파일)이다. 이 파일은 RPM으로 설치하면 자동으로 생성되며 따로 수정할 필요는 없다. 하지만 네임 서버 관리자는 최소한 한달에 한번 캐시 파일을 갱신할 필요는 있다.
[root @edu00 /home]#vi /etc/named.conf
캐시 파일의 경로명과 파일명을 확인한다.
[root @edu00 /home]#vi /var/named/named.ca
[root @edu00 /home]#grep -v "^;" /var/named/named.ca
[root @edu00 /home]#vi /var/named/named.local
3) Master NameServer
네임공간에서 하나의 영역을 할당받고 해당영역에 대한 Authority를 가지고 해당 영역에 대한 서비스를 하게 된다. /etc/named.conf 파일에 할당받은 네임영역을 정의하고 설정에서 지시한 DB 파일을 생성하면 된다.
[root @edu00 /home]#vi /etc/named.conf
options {
directory "/var/named";
};
기본 설정 내용에 다음을 추가한다.
zone "43.170.211.in-addr.arpa"
{
type master;
file "db.43.170.211";
};
zone "god.edu00.co.kr"
{type master;
file "db.god.edu00.co.kr";
};
[root @edu00 /home]#vi /var/named/db.god.edu00.co.kr
@ IN SOA ns.god.edu00.co.kr. root.localhost. (2000061301 28800 14400 3600000 2 )
IN NS ns
IN A 211.170.43.124
IN MX 10 mail
ns IN A 211.170.43.124
mail IN A 211.170.43.124
www IN A 211.170.43.124
ftp IN A 211.170.43.124
ttl IN CNAME ns
[root @edu00 /home]#vi /var/named/db.43.170.211
@ IN SOA ns.god.edu00.co.kr. root.localhost. (2000061301 28800
14400 3600000 2 )
IN NS ns.god.edu00.co.kr.
74 IN PTR ns.god.edu00.co.kr.
74 IN PTR www.god.edu00.co.kr.
74 IN PTR ftp.god.edu00.co.kr.
74 IN PTR mail.god.edu00.co.kr.
[root @edu00 /home]#/etc/rc.d/init.d/named restart
[root @edu00 /home]#nslookup
7. 파일들을 조직적으로 관리하기
관리해야 할 도메인의 수가 증가하는 경우 관련 파일들을 하나의 디렉토리로 묶어서 조직적으로 관리할 수 있다.
[root @edu00 /home]#cd /var/named
[root @edu00 named]#mkdir cache master conf
[root @edu00 named]#mv named* cache
[root @edu00 named]#mv db* master
[root @edu00 named]#vi /etc/named.conf
options {
directory "/var/named";
};
zone "." { type hint; file "cache/named.ca"; };
zone "0.0.127.in-addr.arpa" { type master; file cache/named.local"; };
zone "43.170.211.in-addr.arpa" { type master; file "master/db.43.170.211"; };
zone "god.edu00.co.kr" { type master; file "master/db.god.edu00.co.kr"; };
[root @edu00 named]#/etc/rc.d/init.d/named restart
[root @edu00 named]#tail -n 15 /var/log/messages
[root @edu00 named]#nslookup
관리해야 할 도메인이 많은 경우 cache 관련 파일들은 cache 디렉토리에, db 파일들은 master 디렉토리에, 그리고 설정 파일들은 conf 디렉토리에 관리를 한다면 한결 도메인 관리가 수월해질 것이다.
8. 새로운 도메인 영역 추가하기
BIND 패키지에서는 서비스해야 할 도메인영역이 늘어났을 때 네임서버에 zone을 추가하고 해당 DB 파일을 생성한 후, 네임서버를 재가동 시키는 것으로 간단하게 새 영역을 추가할 수 있다.
[root @edu00 named]#vi /etc/named.conf
options {
directory "/var/named";
};
zone "." { type hint; file "cache/named.ca"; };
zone "0.0.127.in-addr.arpa" { type master; file cache/named.local"; };
zone "43.170.211.in-addr.arpa" { type master; file "master/db.43.170.211"; };
zone "god.edu00.co.kr" { type master; file "master/db.god.edu00.co.kr"; };
include "conf/god2.master"
[root @edu00 named]#vi /var/named/conf/god2.master
zone "god2.edu00.co.kr" { type master; file "master/db.god2.edu00.co.kr"; };
[root @edu00 named]#vi /var/named/master/db.god2.edu00.co.kr
@ IN SOA ns.god2.edu00.co.kr. root.localhost. (2000061301 28800 14400 3600000 2 )
IN NS ns
IN A 211.170.43.124
IN MX 10 mail
ns IN A 211.170.43.124
mail IN A 211.170.43.123
www IN A 211.170.43.123
ftp IN A 211.170.43.123
[root @edu00 named]#nslookup -type=ns god2.edu00.co.kr ns1.lycos.co.kr
[root @edu00 named]#/etc/rc.d/init.d/named restart
[root @edu00 named]#tail -n 15 /var/log/messages
[root @edu00 named]#nslookup www.god2.edu00.co.kr ns1.lycos.co.kr
9. 다중 네임서버 운영하기
주 네임서버의 부하를 덜어주고 주 네임 서버가 다운되었을 때의 사태에 대비하기 위해서 네임서버를 분산해서 관리한다.
1) Master NameServer 설정(ns.god.edu00.co.kr)
master서버는 slave서버의 zone transfer를 허락하고 서비스할 zone DB 파일의 Serial 및 Refresh, Retry, Expire 기간을 설정한다.
[root @edu00 named]#vi /etc/named.conf
options {
directory "/var/named";
allow-transfer { 211.170.43.80; };
# slave 네임 서버에 대한 transfer를 허용한다.
};
.......
[root @edu00 named]#vi /var/named/master/db.god.edu00.co.kr
@ IN SOA ns.god.edu00.co.kr. root.localhost. (
2000101102 ; Serial
60 ; Refresh (6h)
10 ; Retry (1h)
360000 ; Expire (7d)
2 ) ; Minimum TTL (1d)
생략
2) Slave NameServer 설정(ns.slave.linux00.co.kr)
slave 네임서버는 master서버의 네임 영역을 서비스하게 되는데, 이는 /etc/named.conf에 해당 zone을 정의함으로써 가능하다.
zone 정의시 master서버가 어디인지를 명시한다.
slave name server의 IP를 211.170.43.80으로 설정한다.
[root @edu00 named]#telnet 211.170.43.80
login:slave
Password:
Last login: Tue .....
[slave @linux00 slave]$su -
Password:
[root @linux00 slave]#cat >> /etc/named.conf
include "conf/slave/slave.conf
^D
[root @linux00 slave]#vi /var/named/conf/slave/slave.conf
; 슬레이브 서비스 ZONE (slave.linux00.co.kr)
zone "slave.linux00.co.kr" {
type slave;
masters { 211.170.43.72; };
file "slave/db.slave.linux00.co.kr";
};
[root @linux00 slave]#mkdir /var/named/slave
[root @linux00 slave]#chgrp named /var/named/slave
[root @linux00 slave]#chmod 775 /var/named/slave
[root @linux00 slave]#ls -ld /var/named/slave
[root @linux00 slave]#/etc/rc.d/init.d/named restart
[root @linux00 slave]#ls /var/named/slave
db.slave.linux00.co.kr
[root @linux00 slave]#vi /var/named/slave/db.slave.linux00.co.kr
; 이 파일은 사용자가 작성하는 파일은 아니다.
; master name server에 있는 정보를 slave name server에서 읽어들이는 것이다.
; BIND version named 8.2...
: root@localhost:/usr/src/redhat/BUILD/bind-8.2.2_p5/src/bin/named
; zone 'god.edu00.co.kr' first transfer
; from 211.170.43.72:53 (local 211.170.43.80) ....
$ORIGIN edu00.co.kr.
god 2 IN SOA ns.god.edu00.co.kr. root.localhost.
( 2000101102 60 10 3600000 2 )
2 IN NS ns.god.edu00.co.kr.
2 IN MX 10 mail.god.edu00.co.kr.
2 IN A 211.170.43.72
$ORIGIN god.edu00.co.kr.
ttl 2 IN CNAME ns.god.edu00.co.kr.
mail 2 IN A 211.170.43.72
www 2 IN A 211.170.43.72
ftp 2 IN A 211.170.43.72
ns 2 IN A 211.170.43.72
[root @linux00 slave]#exit
3) Slave NameServer Service Testing
slave 네임서버는 master 네임서버로부터 전달받은 zone 파일을 가지고 master 서버의 네임영역("god.edu00.co.kr")을 서비스하게 된다.
이를 test하기 위해 master 네임서버를 다운시키고 난 후, 해당 네임영역 ("god.edu00.co.kr")의 호스트에 대해서 질의를 한다.
#/etc/rc.d/init.d/named stop
#nslookup -type=ns god.edu00.co.kr ns.linuxone.co.kr
#nslookup -type=ns god.edu00.co.kr ns.yahoo.co.kr
10. 서브 도메인으로 나누기
해당 도메인에 속한 호스트의 수가 많아져서 관리에 어려움이 있거나 여러 기관들에게 도메인을 위임하고 관리를 분산시키고 싶을 때는 서브 도메인으로 나누어야 한다.
1) 도메인을 위임하지 않고 상위 영역에서 서브 도메인 만들기
서브 도메인의 호스트들이 별로 없다면 도메인 위임없이 상위영역에서 서브 도메인을 생성할 수 있다. 하지만 도메인이 너무 길어져서 불편할 경우 해당 도메인을 주로 검색하는 호스트들은 resolver의 search값을 설정할 수 있다.
[root @edu00 /root]#vi /var/named/master/db.god.edu00.co.kr
생략
; 서브도메인 web.god.edu00.co.kr 영역할당 (위임 no)
$ORIGIN web.god.edu00.co.kr
$INCLUDE sub_domain/db.web.god.edu00.co.kr
[root @edu00 /root]#mkdir /var/named/sub_domain
[root @edu00 /root]#vi /var/named/sub_domain/db.web.god.edu00.co.kr
생략
dabang IN A 211.170.43.80
db IN CNAME dabang
file IN CNAME dabang
[root @edu00 /root]#cat >> /var/named/master/db.43.170.211
80 IN PTR dabang.web.god.edu00.co.kr
[root @edu00 /root]#/etc/rc.d/init.d/named restart
[root @edu00 /root]#nslookup db.web.god.edu00.co.kr ns.daum.net
2) 하부 네임서버에게 서브 도메인 위임하기
학교와 같이 서브도메인이 다수의 호스트들을 가지고 있을 때는 위임을 통해서 서브도메인을 생성할 수 있다.
도메인 등록과 같은 과정을 거친다.
[root @edu00 /root]#vi /var/named/master/db.god.edu00.co.kr
; 서브도메인 web2.god.edu00.co.kr 영역할당 (위임 ok)
web2 IN NS ns.web2
ns.web2 IN NS 211.170.43.80
; 서브도메인 web.god.edu00.co.kr 영역할당 (위임 no)
$ORIGIN web.god.edu00.co.kr
$INCLUDE sub_domain/db.web
[root @edu00 /root]#/etc/rc.d/init.d/named restart
[root @edu00 /root]#nslookup -type=ns web2.god.edu00.co.kr
[root @edu00 /root]#telnet 211.170.43.80
login:wind
Password:
Last .........
[wind @edu00 wind]$su -
Password:
[root @edu00 wind]#cat >> /etc/named.conf
include "conf/master/web2.god.conf";
^D
[root @edu00 wind]#vi /var/named/conf/master/web2.god.conf
;
; 마스터 서비스 ZONE ( web2.god.edu00.co.kr )
;
zone "43.170.211.in-addr.arpa" {
type master;
file "master/db.43.170.211";
};
zone "web2.god.edu00.co.kr" {
type master;
file "master/db.web2.god.edu00.co.kr";
};
[root @edu00 wind]#vi /var/named/master/db.web2.god.edu00.co.kr
@ IN SOA ns.linux.edu00.co.kr. root.localhost
( 1 28800 14400 3600000 2 )
IN NS ns.linux.edu00.co.kr.
a1 IN A 211.170.43.100
b1 IN A 211.170.43.101
c1 IN A 211.170.43.102
[root @edu00 wind]#vi /var/named/master/db.43.170.211
@ IN SOA ns.linux.edu00.co.kr. root.localhost
( 1 28800 14400 3600000 2 )
IN NS ns.linux.edu00.co.kr.
100 IN PTR a1.web2.god.edu00.co.kr.
101 IN PTR b1.web2.god.edu00.co.kr.
102 IN PTR c1.web2.god.edu00.co.kr.
[root @edu00 wind]#/etc/rc.d/init.d/named restart
[root @edu00 wind]#nslookup a1.web2.linux.edu00.co.kr ns.yahoo.co.kr
[root @edu00 wind]#exit
11. DNS를 이용한 라운드로빈 웹서버 분산
일반적으로 웹서버의 부하를 덜기 위해서 분산이라는 개념을 도입하는데, 이는 동일한 사이트를 서비스해주는 웹서버를 여러 개 두고, 접속자들을 적절하게 배분하여 해당 서비스를 행하도록 하는 것이다.
분산 서비스에 있어서 우선하는 개념은 로드밸런싱이다. 외부로부터 서버로 접속이 들어왔을 때, 로드밸런서(디렉터)가 서버들의 부하를 판단해서 외부 접속자를 어느 서버로 안내할 것인지 정해준다.
DNS를 이용한 분산 방식은 라운드로빈 방식에 의해 외부 접속자들을 특정 서버로 보내주게 된다. 하지만 DNS는 각 서버들의 부하를 체크하지 못하며 심지어 다운여부조차 판단하지 못하기 때문에 다운되어 있는 웹서버로 안내받은 외부 접속자는 웹사이트를 볼 수 없는 일이 생길 수 있다.
1) 다수의 A 레코드를 이용한 라운드로빈 웹서버 분산
다수의 A 레코드를 이용한 라운드로빈 분산 방식은 로컬 NS가 Authority NS에서 다수의 IP를 넘겨받아 캐쉬에 저장한 후, 자체적인 라운드로빈 처리를 하게 된다.
[root @edu00 wind]#vi /var/named/master/db.god.edu00.co.kr
생략
www IN A 211.170.43.72
IN A 211.170.43.70
IN A 211.170.43.73
생략
[root @edu00 wind]#vi /var/named/master/db.43.170.211
생략
72 IN PTR www.god.edu00.co.kr.
70 IN PTR www.god.edu00.co.kr.
73 IN PTR www.god.edu00.co.kr.
생략
[root @edu00 wind]#/etc/rc.d/init.d/named restart
[root @edu00 wind]#nslookup www.god.edu00.co.kr ns.yahoo.co.kr
[root @edu00 wind]#nslookup www.god.edu00.co.kr ns.yahoo.co.kr
[root @edu00 wind]#ping -c 1 www.god.edu00.co.kr
[root @edu00 wind]#ping -c 1 www.god.edu00.co.kr
[root @edu00 wind]#ping -c 1 www.god.edu00.co.kr
2) CNAME을 이용한 라운드로빈 웹서버 분산
bind 8 이후부터 CNAME을 이용한 라운드로빈 분산 서비스 설정을 지원하고 있다. 일반적으로 웹 브라우져에 "www.edu00.co.kr"이라는 URL을 입력했을 때, 주소가 "ttl.edu00.co.kr"이라고 바뀌는 것이 CNAME을 이용해서 웹서버를 분산 운영하고 있는 곳이다.
CNAME의 역할에 맞게, www라는 호스트를 지정했을 때, Canonical-Name, www1이나 www2, www3 등의 호스트 정보(Address 등)를 받아오는 것이다. CNAME을 이용한 라운드로빈 분산 방식은 로컬 NS가 한 개의 주소만을 넘겨받기 때문에 자체적인 라운드로빈 처리가 불가능하다.
[root @edu00 wind]#vi /etc/named.conf
options {
directory "/var/named";
multiple-cnames yes;
};
생략
[root @edu00 wind]#vi /var/named/master/db.god.edu00.co.kr
생략
www1 IN A 211.170.43.89
www2 IN A 211.170.43.88
www3 IN A 211.170.43.90
www IN CNAME www1
IN CNAME www2
IN CNAME www3
[root @edu00 wind]#vi /var/named/master/db.43.170.211
생략
80 IN PTR ns.god.edu00.co.kr.
70 IN PTR www1.god.edu00.co.kr.
88 IN PTR www2.god.edu00.co.kr.
90 IN PTR www3.god.edu00.co.kr.
89 IN PTR ftp.god.edu00.co.kr.
89 IN PTR mail.god.edu00.co.kr.
[root @edu00 wind]#nslookup www.god.edu00.co.kr
[root @edu00 wind]#nslookup www.god.edu00.co.kr