네임서버 설정 참고사항 / 다이나믹 DNS 참고 사항

티스토리 뷰

리눅스(유닉스)/네임서버

네임서버 설정 참고사항 / 다이나믹 DNS 참고 사항

프링글 2008. 6. 19. 14:20

DNS와 네임 서버 BIND

1. Domain Name System의 이해

1) 도메인 네임의 사용 배경

TCP/IP 네트워크인 인터넷 상에서 상호 통신이 가능하려면 상대방과 자신의 IP 주소가 필요하다. 그러나 시스템이나 소프트웨어 입장에서는 IP 주소가 편리하지만 사람에게는 불편하여 이름을 사용하는 방안이 고안되었다. 즉, 표기나 입력은 이름으로 하지만, 이름과 이에 대응되는 IP 주소를 데이터베이스에 저장을 하여 IP 주소가 필요할 때마다 데이터베이스를 조회하도록 하는 것이다.

초기 인터넷의 전신인 ARPANET에서는 네트워크 상에 많은 호스트가 존재하지 않아서 NIC (network information center)에 호스트 이름과 이에 대한 IP 주소를 등록하여 hosts.txt 파일에 저장하고, 네트워크 상의 모든 컴퓨터는 NIC에서 관리하는 hosts.txt 파일을 주기적으로 받아와서 /etc/hosts에 저장하여 사용하였다.

호스트의 수가 증가하면서 이러한 방법으로 관리하는 것이 어려워지면서 계층 구조의 이름 형식을 가지며 분산 데이터 베이스로 구성되는 domain name 체계가 1983년에 제안되었다.

2) Domain name 체계

(1) Name space의 계층 구조

최상위에 있는 root (.) domain을 기점으로 트리 형식의 계층 구조를 가진다.

gTLD (.com, .net, .org, .edu, .gov, .mil, .int, .biz, .info, .name)를 이용하는 도메인은 기관-gTLD의 2단계 구조를 가지며, 이 도메인에 속한 호스트의 네임은 호스트명.기관명.gTLD의 3단계 구조를 가진다. ccTLD (ISO에서 정한 알파벳 2자리의 국가코드로 된 도메인)를 이용하는 도메인은 기관-기관종류-ccTLD의 3단계 구조를 가지며 이에 속한 호스트 네임은 호스트명.기관명.기관종류.ccTLD의 4단계 구조를 가진다. 이와 같이 정식으로 등록된 도메인을 가진 기관에서 규칙에 따라 자기 기관의 호스트에 부여한 호스트 이름을 FQDN (fully qualified domain name)이라고 한다.

도메인을 등록한 기관은 그 기관의 호스트에 대해 FQDN을 위의 방법대로 부여하여 관리하고 사용할 수도 있지만, 호스트의 수가 많아지면 이름을 부여하기도 힘들고 관리도 힘들어진다. 예를 들어서 한 기관에 여러 개의 부서가 있고, 각 부서마다 웹서버, 메일서버 등이 필요하다고 하면 이 서버들에 대한 이름을 모두 www나 mail로 할 수도 없다. 그렇다고 부서별로 새로운 도메인을 하나씩 신청을 한다면 비용도 커질 뿐 아니라 도메인의 일관성이 없어지므로 한 기관의 아이덴티티를 가지기도 어렵다. 이럴 경우에 필요에 따라 기관명 아래에 호스트명 대신 하위의 도메인 (subdomain 또는 부 도메인)을 추가로 생성할 수 있는데, 이론적으로는 최대 127 단계까지 도메인의 계층을 늘릴 수 있다. 예를 들어서, yahoo.com 도메인은 야후사가 등록한 도메인이다. yahoo.com 도메인에는 messenger.yahoo.com 이라는 하위 도메인을 두고 있어서, 메신저 서비스를 담당하는 서버들은 국가별로 cn.messenger.yahoo.com (중국), mx.messenger.yahoo.com (멕시코) 등과 같이 호스트 이름을 할당해 주고 있다.

(2) Domain name의 관리

NIC의 단일 서버에서 관리하던 ARPANET과 달리, root domain 네임서버는 top level 도메인을 관리하는 네임서버에 대한 정보를, top level domain 네임서버는 자기 domain의 하위에 있는 second level 도메인을 관리하는 네임서버들에 대한 정보를 … 과 같이 네임 서버는 자신의 하위 레벨 도메인의 네임서버 정보를 관리하고 유지한다.

예를 들면 .com 도메인을 관리하는 top level 도메인 네임서버는 yahoo.com, naver.com, microsoft.com 등의 도메인을 관리하는 네임서버들이 각각 어떻게 되는지를 관리한다. 그리고 yahoo.com 도메인을 관리하는 네임서버는 www.yahoo.com, av.yahoo.com, kr.yahoo.com, mail.yahoo.com 등의 호스트에 대한 정보를 관리한다. 따라서 mail.yahoo.com에 대한 등록과 관리의 책임은 yahoo.com 도메인을 관리하는 서버가 가진다. 마찬가지로 naver.com, microsoft.com 등의 도메인에 대한 관리는 각각의 도메인을 관리하는 네임서버들이 책임을 지기 때문에 도메인의 계층적, 수평적 분산 관리가 이루어진다.

(3) Domain의 위임 (delagation)

전체 도메인 공간을 나타내는 트리 상에 있는 하나의 도메인을 관리하는 네임 서버가 그 도메인 이하의 트리 상의 가지에 있는 하위 도메인 전체에 대한 관리를 할 수도 있겠지만, (2)에서 설명한 바와 같이 그렇게 하지 않는 경우가 대부분이다 (물론 하나의 도메인을 등록하여 사용하는 기관에서는 등록하여 사용하고자 하는 호스트의 수가 많지 않을 경우에는 굳이 부 도메인을 설정하고 이를 관리하기 위한 네임서버를 따로 두지 않고, 하나의 네임서버가 그 도메인에 속하는 호스트 전체를 관리하는 경우가 대부분이다). 이럴 경우 하나의 도메인을 관리하는 네임서버에서는 그 도메인의 하위 도메인을 정의하여 이것을 다른 네임서버에게 관리를 위임하고, 어느 하위 도메인을 어느 서버에게 위임했는가에 대한 정보만을 가진다. 위임을 받은 하위 도메인에 대한 모든 관리 책임은 전적으로 그 하위 도메인 네임서버가 진다.

하위 도메인에 대한 상위 도메인 네임 서버의 책임은 해당 하위 도메인을 관리하는 서버가 누구냐를 정확히 알려 주는 것뿐이다. 하위 도메인을 관리하는 네임서버가 자신의 하위에 새로운 도메인을 만들어서 이것을 위임했을 경우에도 규칙은 동일하게 적용된다.

예를 들면 여러분이 myhome.com이라는 도메인을 신청기관에 신청해서 받게 되었다면 com 도메인을 관리하는 네임서버는 myhome.com이라는 자신의 하위 도메인을 여러분들에게 위임을 하는 셈이다. 도메인을 등록할 때, 여러분은 이 도메인을 관리할 네임서버에 대한 정보를 입력해야 한다. com 도메인 서버는 여러분이 입력한 정보를 바탕으로 myhome.com이라는 도메인을 관리할 서버에 대한 정보만을 유지하며, 실제 myhome.com 도메인의 모든 호스트나 부 도메인에 대한 1차적 관리책임은 여러분이 도메인을 등록할 당시에 입력한 네임서버가 가진다.

물론, 도메인 네임서버는 자기에게 관리 책임이 부여된 도메인 공간 중에서 일부의 하위 도메인에 대해서만 하위 도메인 네임서버에게 위임하고, 해당 도메인의 나머지는 자기가 관리할 수도 있다. 아니면 일부조차도 하위 도메인 네임서버에게 위임하지 않고 자신이 모두 관리할 수 있다. 경우에 따라서는 하위 도메인 자체를 두지 않는 경우도 있을 것이다. 앞서 설명한 것처럼 대부분의 소규모 기관에서 도메인 네임서버를 운영할 때는 자기 기관에서 등록한 도메인을 하나의 도메인 네임서버가 관리하는데, 이 경우가 대표적인 예이다.

자기가 등록한 도메인을 직접 관리할 수 있는 서버를 가지지 못한 기관이나 개인을 위해서 상업적으로 도메인 관리를 대행해 주는 경우가 있는데, 이것은 도메인 호스팅 (domain hosting) 또는 도메인 파킹 (domain parking)이라고 한다.

(4) 도메인 (domain)과 영역 (zone)

(3)에서 설명한 것처럼 네임서버가 어떤 도메인을 관리한다고 할 때, 그 네임서버는 해당 도메인 전체를 관리할 수도 있고 하위 도메인을 만들어서 하위 도메인의 일부 또는 전부를 하위 도메인 서버들에게 위임할 수도 있다. 영역이란 도메인 네임서버가 상위 서버로부터 위임받은 도메인 공간 중에서 하위 도메인 네임서버에게 위임한 부분을 제외하고 자신이 직접 관리하는 부분을 의미한다. 예를 들어서 com 도메인을 관리하는 네임서버는 yahoo.com, naver.com. microsoft.com, ... 등의 도메인을 신청 받아서 등록하고 위임한 나머지를 자신의 영역으로 한다. yahoo.com 도메인을 관리하는 네임서버에서는 messenger.yahoo.com ... 등의 부도메인들을 제외한 나머지 부분이 자신이 관리하는 영역이 된다.

네임서버는 자신이 관리하는 도메인 공간 중에서 위임을 하지 않은 영역 부분은 자신이 직접 관리를 하고, 위임된 하위 도메인에 대해서는 위임 내용과 위임받은 네임서버에 대한 정보만을 관리하는 셈이다. 따라서 네임서버에서 서버가 관리하는 내역을 설정하려면 항상 영역 단위로 설정을 하게 되며, 설정파일도 영역 파일 (zone file) 또는 영역 데이커베이스 파일이라고 한다.

3) Domain name의 번역 (resolving) 과정

ꋯ

C:\>nslookup www.naver.comꎠ

Server: swns.kornet.net ← Local name server

Address: 61.77.63.1

Name: www.naver.com

Address: 211.218.150.200

① Client상의 응용 프로그램이 www.naver.com에 접속하기 위해 클라이언트의 resolver는 자신의 TCP/IP 정보에 설정되어 있는 Local Name Server에 www.naver.com의 IP 주소를 질의한다 (resolver query).

이후 local NS는 스텝 ②～④에 명기된 바와 같이 상위의 네임서버로부터 하위의 네임서버로 차례대로 질의를 하여 그 결과를 얻는다. 이 과정을 recursive query (재귀적 질의)라고 한다. resolver나 각 레벨의 네임서버 자체는 재귀적 질의를 하지 않으며, client resolver가 local NS에게 질의를 할 때 재귀적 질의를 요청하기 때문에 local NS가 그에 대한 응답으로 각 레벨의 네임서버에 재귀적 질의를 하는 것이다.

② Local NS는 먼저 자신의 캐쉬에 자료가 있는지 확인한 후 발견되지 않을시 Root NS(Root NS의 목록은 갖고있다)에 질의를 던진다. 그러나 Root NS도 www.naver.com 의 자료를 갖고 있지 않으므로, com 도메인을 관리하는 NS를 참고하라는 답변을 보내준다.

③ Local NS는 다시 COM NS에 질의를 던지고, COM NS는 다시 naver.com의 NS를 일러준다. (루트(도트)와 COM 도메인은 Root NS에서 같이 관리되기 때문에 실제로 본 과정은 일어나지 않고 ②번에서 바로 naver.com NS를 참고하라는 답변이 나온다.)

④ Local NS는 naver.com NS에 질의한다. naver.com NS는 서브도메인에 대한 자료를 관리하는 실제 NS 이므로, www.naver.com에 대한 IP 주소인 211.218.150.200를 답변 (authoritative answer) 한다.

⑤ 마지막으로, Local NS는 Client에게 결과를 전송한다.

ꋯ Local name server는 각 네임서버로 질의하여 얻은 결과를 cache에 보관하고 있다가, 이후에 client로부터 동일한 질의가 올 경우 일정 기간은 그것을 이용한다.

ꠚ 이렇게 cache의 결과를 돌려준 경우, local name server는 결과에 “Non-authoritative answer"라는 코멘트를 추가한다.

C:\>nslookup www.naver.comꎠ

Server: swns.kornet.net

Address: 61.77.63.1

Non-authoritative answer: ← answer using cache

Name: www.naver.com

Address: 211.218.150.200

4) Domain name의 신청 및 사용

(1) 관리 기관 (registry)과 등록 대행 기관 (registrar)

Domain name과 관련된 기관으로는 등록된 domain name을 유지 관리하는 기관인 registry와, 신청자의 신청을 받아 등록 절차를 대행해 주는 사업자인 registrar로 구분이 된다. 따라서 신청은 registrar에 해야 하고, 그 데이터의 관리는 실제로는 registry에서 이루어진다.

registrar는 등록하고자 하는 domain이 gTLD인지 아니면 ccTLD인지에 따라 구분되는데, 요즘은 많은 사업자가 이를 겸하고 있다. gTLD와 관련된 registrar는 ICANN의 http://www.icann.org/registrars/accredited-list.html에 목록이 있으며, kr 도메인과 관련된 registrar는 KRNIC의 http://domain.nic.or.kr/menu/guide/request.html에 목록이 있다.

(2) 신청 방법

여기서는 새로운 도메인을 신청하고 운영하기 위한 방법을 다룬다. 경우에 따라서는 기존에 등록된 도메인의 하부 도메인을 위임받아서 운영할 수 있는 방법도 있다. 예를 들어 여러분이 소속된 기관에 이미 등록된 도메인이 있다면 여러분은 해당 도메인 관리자와 상의해서 일부 부도메인을 위임받아서 운영할 수 있다. 또한 인터넷 상에는 무료 도메인을 제공하는 사이트도 있는데, 이것 역시 해당 사이트가 하나 (또는 다수)의 등록된 도메인을 가지고 있으면서 그 도메인의 부도메인을 무료로 등록시켜 주는 것이다. 이것은 하나의 도메인을 등록하는데는 등록비와 매년 유지비가 필요하지만, 그 하위 도메인에 대해서는 어떤 부도메인을 만들든지 상위기관에서는 관여도 하지 않고 비용도 요구하지 않기 때문에 가능하다. 이에 대해서는 나중에 부도메인 운영에서 다룬다.

① 준비 사항

ꋯ 먼저, 신청할 domain name을 생각해 둔다. 도메인 네임이 이미 등록이 된 것인지는 registrar 또는 registry의 사이트에서 whois 검색을 할 수 있다. Linux box에서는 다음과 같은 명령어로 확인을 할 수 있다.

# whois domain-nameꎠ 또는 whois가 지원되지 않는다면

# dig ns domain-nameꎠ

ꋯ 그 다음, 이 도메인에 대해 네임 resolving을 해 줄 (즉 관리를 해 줄) 네임 서버를 결정한다. 네임서버의 IP 주소와 hostname을 알고 있어야 한다.

ꋯ 네임 서버가 기존에 운영되고 있는 것이라면 새로 신청한 도메인에 대해 그 네임서버가 resolving 서비스를 하도록 추가로 설정해야 한다. ISP, registrar를 포함한 많은 인터넷 호스팅 업체들이 네임서버를 운영하면서 서버에 신청자가 등록한 도메인에 관한 설정을 추가하여 네임 서비스를 하는 도메인 파킹 서비스를 제공하고 있으므로, 그것을 이용할 수 있다.

ꋯ 서비스 업체를 이용하지 않으려면 직접 네임서버를 구축하여 운영하여야 한다 (아니면 기존에 네임서버를 운영하고 있는 마음씨 좋은 사람을 만나야 한다). 이를 위해서는 공인된 IP 주소를 이용하여 인터넷을 사용할 수 있는 컴퓨터와 네임서버 소프트웨어가 있어야 한다. 이 강좌에서는 후자의 방법을 중심으로 학습한다.

② 신청 과정

ꋯ registrar의 홈페이지에서 원하는 도메인 이름을 입력하고, 신청자 (기관) 및 관리자에 대한 정보를 입력한다. 또한 등록한 도메인의 정보를 관리하게 될 네임서버에 대한 정보를 입력해야 하는데, IP 주소와 도메인 네임을 모두 입력한다. 주로 사용할 primary 서버와 primary 서버의 장애 발생시 사용할 secondary 서버에 대해 모두 입력한다.

ꋯ 도메인 파킹 서비스를 이용하거나 기존에 사용중인 네임서버에서 이 도메인을 관리할 것이라면 그 네임 서버의 IP 주소와 FQDN을 알아내어 그것을 입력하면 된다.

ꋯ 그러나 새로 구축할 네임서버의 호스트 네임을 등록할 도메인에 속한 것으로 할 경우는 이 단계에서 그 서버의 호스트 네임과 IP 주소 정보를 입력을 해도 적용이 되지 않는다. 왜냐하면 도메인 신청 단계에서는 registry의 DNS 서버에는 아직 그 도메인이 등록이 되어 있지 않으므로 그 도메인 이름으로 구성된 네임서버의 호스트 네임을 인식하지 못하기 때문이다.

ꠚ 이 때는 우선 기존에 어디선가 서비스 중인 네임서버의 정보를 임의로 입력하여 도메인을 등록한다. 이 서버가 실제로 새로 등록하는 도메인을 관리하게 되는지의 여부는 중요하지 않다. 단지, 그 네임서버의 FQDN과 IP 주소는 기존에 등록되어 사용 중이어서 인터넷 상에서 인식이 가능한 것이어야 한다.

ꋯ 일단 도메인이 등록되고 나면 registrar의 사이트에서 네임서버에 대한 정보를 실제로 가동할 네임서버의 IP 주소와 호스트 네임 (등록한 도메인에 속하는 네임)으로 지정할 수 있다.

ꠚ 이렇게 하기 위해서는 먼저, registrar의 홈페이지에 있는 설정 메뉴 중에서 ‘호스트 등록’ 메뉴를 찾아서 구축할 네임서버 이름과 IP 주소를 등록한다. 네임서버는 보통 ns.도메인.TLD, ns2.도메인.TLD와 같은 이름을 부여한다. 그러나 이것은 의무사항은 아니고, 알아보기 쉽도록 하기 위한 배려이다. 그러고 나서, ‘등록한 도메인 관리’ 메뉴에 있는 ‘네임서버 변경’ 메뉴를 이용하여 네임 서버를 이것으로 등록 변경해 주면 된다.

아무리 그렇다 해도, 어떻게 하나의 도메인 전체를 그 안에 속해있는 일개 호스트가 관리를 할 수 있나? 하는 의문이 발생할 것이다. 예를 들어서 abc.com 도메인의 관리를 ns.abc.com이 한다고 하면 (그렇지 않은 경우도 많겠지만), ns.abc.com은 누가 관리를 한단 말인가? 분명히 ns.abc.com은 abc.com 아래의 호스트 중 하나일 뿐인데!

이것은 상위 도메인인 .com 도메인을 관리하는 네임 서버에서 abc.com 도메인의 관리를 ns.abc.com이 한다는 정보를 설정해 두기 때문에 가능하다. .com 도메인을 관리하는 네임 서버는 도메인을 등록할 때 입력된 정보에 의거해서 abc.com의 네임서버가 ns.abc.com이라는 것과 그의 IP 주소를 알고 있다 (네임서버의 호스트명과 IP 주소가 기록된 내용을 glue record라고 한다). 따라서 abc.com 도메인에 대한 네임 query가 올 경우 그것을 ns.abc.com에 해당하는 IP 주소로 요청해야 한다는 것을 알려 줄 수 있다.

이렇게 상위 도메인이 그 아래의 하나의 도메인에 대한 관리를 그 하위 네임서버에 맡기는 것을 도메인 위임 (delegation)이라고 하고, 하위에서 맡는 입장에서는 domain parenting이라고 한다. 이것은 비단 도메인 계층간에서 뿐만 아니라 하나의 도메인과 그 sub-domain에 대해서도 마찬가지로 적용이 가능하다.

2. Name server의 구성과 운영

1) Name server의 유형

네임서버는 Authority server, Cache only server로 구분된다.

Authority server는 주어진 도메인에 대한 관리를 위임받은 네임서버로서, primary server와 secondary server로 구분된다. Primary server는 해당 도메인을 관리하는 주 네임서버이고, Secondary server는 그 도메인에 대한 primary 서버의 데이터에 대해 back-up copy를 유지하는 서버이다. Secondary는 Primary 서버에 문제가 발생하였을 때 back-up으로 동작하거나 부하를 분산시키기 위해 운용하며, 다수가 존재할 수 있다(기술적으로는 Primary 만으로도 운영은 가능하나 권고되진 않는다).

Cache only server는 클라이언트 resolver들로부터의 resolving query에 대해 root 도메인 네임서버로부터 순차적으로 authority 네임서버에 resolving query를 하여 결과를 클라이언트에게 알려주는 역할을 수행한다. 특정 도메인에 대해서 데이터 관리를 하지 않기 때문에 다른 네임서버로부터의 resolving query를 받지 않는다. 이 서버는 네트워크 상의 클라이언트에서 네임서버로 설정해 놓은 네임서버의 역할이 바로 cache only server의 역할이다. 물론, primary 및 secondary 네임서버도 cache only server의 역할은 수행할 수 있다.

2) Name server의 설치 확인 및 설치

전세계적으로 가장 많이 이용되는 네임 서버는 BIND (Berkeley Internet Name Domain)이다. 이러한 이름이 붙게 된 이유는 최초에 BIND가 만들어진 것이 버클리 대학원생들의 프로젝트에 의한 결과물이기 때문이다.

(1) 설치 확인

ꋯ

# rpm -qa|grep bindꎠ (확인명령)

bind-9.2.1-16 (설치된 경우)

redhat-config-bind-1.9.0-13

bind-utils-9.2.1-16

ypbind-1.11-4

(2) 미 설치시 설치

① package name

ꋯ (1)의 파란색 패키지 파일명으로 설치 CD 1에서 rpm 파일을 검색한다.

② 설치방법

ꋯ xinetd편 참조

ꋯ 설치후 CD 제거

③ 소스코드를 이용한 설치

ꋯ 이 과정에서는 다루지 않음

ꋯ 자세한 사항은 교재의 14.3.3 참조

(3) 자동실행 설정

ꋯ ntsysv에서 named를 설정 (xinetd편 참조)

ꋯ 다음 부팅시 자동으로 실행됨

ꋯ 지금 즉시 실행하고자 하는 경우는 다음 스크립트 실행

# /etc/rc.d/init.d/named startꎠ

3) Name service와 관련된 파일

(1) Domain name resolving 관련

Client 입장에서 domain name resolving 서비스를 받기 위한 설정파일들로서, 네임서버의 설치 구성 및 운영과는 관계가 없음

① /etc/host.conf

ꋯ 시스템에 특정 host에 대한 IP 주소를 알려주기 위해 사용

ꋯ DNS 서버를 이용하지 않고 resolving을 할 수 있게 해 줌

② /etc/resolv.conf

ꋯ 시스템에서 resolver가 query에 사용할 cache-only name 서버를 정의함

ꋯ 비 FQDN 질의에 대한 hostname의 domain suffix 정의

(2) Name server 설치 구성 및 운영 관련

① /etc/named.conf - named 부트 파일 (BIND 시작시 가장 먼저 읽는 설정)

② /etc/rc.d/init.d/named - BIND 실행관리 스크립트 파일

③ /usr/sbin/named - BIND 실행파일

④ /var/named/zone-* - forward zone 파일 (파일명은 named.conf에서 정의)

⑤ /var/named/*.in-addr.arpa - reverse zone 파일 ( " " " )

⑥ /var/named/named.local - localhost의 forward zone file

⑦ /var/named/localhost.zone - localhost의 reverse zone file

⑧ /var/named/named.ca - root name server 정보 파일

⑨ /usr/sbin/rndc - named를 외부에서 제어하기 위한 유틸리티

⑩ /etc/rndc.conf - rndc 요청에 대한 인증 설정파일

⑪ /etc/rndc.key - rndc 요청 인증을 위한 암호화 키 파일

ꋯ ①은 named에 대한 주 설정파일로, 주로 네임서버가 관리할 영역을 정의한다.

ꋯ ④, ⑤는 네임서버가 관리할 영역에 대한 설정을 하는 영역 데이터베이스 파일로서, 관리자가 ①의 파일에서 파일명을 정의해 주고 내용을 설정해야 한다.

ꋯ ⑥, ⑦, ⑧은 로컬 호스트에 대한 정의와 도메인 query를 위한 root name server에 대한 정보이므로 특별히 설정을 변경할 필요가 없다. 단, ⑧은 root name server에 변동이 발생할 수 있으므로 가끔 갱신할 필요가 있다.

ꠚ 방법은

# wget ftp://ftp.rs.internic.net/domain/named.rootꎠ

# mv named.root /var/named/named.caꎠ

# service named stopꎠ ← 주의:RedHat9의 버그로 인해 실행 안됨

# service named startꎠ

ꠚ 서비스의 start, stop, restart 시에는 항상 [확인] 메시지가 나타나야 원하는 서비스 제어가 이루어지는 것이다. 만일 이것이 나타나지 않는다면 어디엔가 문제가 있는 것이므로 특히 설정 파일의 오류에 중점을 두어 문제점을 찾아 해결해야 한다. 단, RedHat9에는 named 서비스의 stop 또는 restart시 stop 스크립트 부분에 버그가 있어 다른 오류가 없어도 서비스 중지가 되지 않는다. 따라서 이 문제를 해결하기 위해서는 서비스를 다음과 같이 강제로 종료해야 한다.

# pkill namedꎠ ← named 문자가 들어간 프로세스를 kill

# pgrep namedꎠ ← named 관련 프로세스가 더 이상 없음을 확인

ꋯ ⑨, ⑩, ⑪은 rndc 유틸리티를 사용하는데 필요한 파일들이다. rpm으로 named를 설치한다면 암호화 키 파일까지 설정이 되므로 신경 쓰지 않아도 되지만, 소스를 직접 컴파일하여 설치한다면 추가 작업이 필요하다.

4) DNS의 설정 #1 - 기본적인 DNS 운영을 위한 설정

(1) 예제 시나리오

① 이 절에서는 다음의 표와 같이 DNS를 운영하고자 할 때 필요한 설정 방법을 학습한다.

도메인 네임	dtcinfo.net
1차 네임 서버	ns (203.237.160.135)
2차 네임서버	ns2 (218.145.241.59)
웹서버	www (203.237.160.135)
메일서버	mail (218.145.241.229)

② 웹으로의 접속은 http://www.dtcinfo.net 및 http://dtcinfo.net이 모두 가능하도록 한다.

③ 메일 주소는 user@mail.dtcinfo.net 및 user@dtcinfo.net이 모두 가능하도록 한다.

(2) 부트파일 (/etc/named.conf)의 설정 내용

네임서버의 기본 환경 설정 및 관리할 도메인 zone과 그에 필요한 데이터베이스 파일 정의. option, control, zone 선언 부분으로 구분되는데, 이 네임서버에서 관리할 도메인의 영역과 그 영역의 도메인 데이터베이스 파일을 정의한 zone 선언 부분이 핵심.

Master name server와 secondary name server에서 설정할 내용은 대동소이하다. 다음의 규칙을 지켜야 함

ꋯ 주석문의 형식은 C(++)의 그것을 따른다. Shell의 형식도 사용 가능하지만, zone 파일에서 주석문의 시작으로 사용하는 “;”는 사용할 수 없다.

ꋯ 선언문은 “;”로 마치며, 선언문과 선언문 사이는 한 칸 이상을 띄워야 한다.

ꋯ 선언문 안에 부 선언문이 올 수 있다.

Master name server

// generated by named-bootconf.pl

options { // 설정에 관한 각종 옵션 지정

directory "/var/named"; // zone 파일을 저장할 위치 설정

* If there is a firewall between you and nameservers you want

* to talk to, you might need to uncomment the query-source

* directive below. Previous versions of BIND always asked

* questions using port 53, but BIND 8.1 uses an unprivileged

* port by default.

// query-source address * port 53;

};

controls { // 네임서버 관리 채널의 접속 허용 범위 및 인증 암호키를 정의

inet 127.0.0.1 allow { localhost; } keys { rndckey; };

};

// 다음은 cache-only 서버를 위한 설정. root name 서버에 query를 하기 위함

zone "." IN { // Root 도메인 영역에 대한 파일 지정. cache-only 서버에 필요

type hint; // 해당 zone에 대해 Cache-only 서버로서 운영

file "named.ca"; // zone file의 이름. 위에서 정의한 directory에 있어야 함

};

// 여기까지는 cache-only 서버에 반드시 필요.

// 다음은 localhost/루프백 주소에 대한 forward/reverse zone 정의. 모든 시스템에 필수

zone "localhost" IN { // 기본 이름인 "localhost" 에 대한 zone 파일 지정

type master; // 해당 zone에 대해 master (1차) 서버로서 운영됨

file "localhost.zone";

allow-update { none; }; // dynamic update 기능 설정

};

zone "0.0.127.in-addr.arpa" IN { // 루프백 주소에 대한 reverse zone 파일 지정

type master;

file "named.local";

allow-update { none; }; // “"none"의 경우에는 생략 가능

};

// 관리할 forward/reverse zone에 대한 정의 Cache-only 서버는 이하 내용 없음

zone "241.145.218.in-addr.arpa" IN { // 할당 IP 영역에 대한 Reverse Zone 파일 지정

type master;

file "zone-241.145.218.in-addr.arpa";

};

zone "dtcinfo.net" IN { // 도메인 dtcinfo.net 영역에 대한 Forward Zone 파일 지정

type master;

file "zone-dtcinfo.net";

};

include "/etc/rndc.key"; // 설정 내용에 외부 파일을 추가

Secondary name server

// generated by named-bootconf.pl

options {

directory "/var/named";

* If there is a firewall between you and nameservers you want

* to talk to, you might need to uncomment the query-source

* directive below. Previous versions of BIND always asked

* questions using port 53, but BIND 8.1 uses an unprivileged

* port by default.

// query-source address * port 53;

};

controls {

inet 127.0.0.1 allow { localhost; } keys { rndckey; };

};

// caching only nameserver 동작에 필요한 설정

zone "." IN {

type hint;

file "named.ca";

};

// localhost, 루프백 주소는 자기 시스템이므로 이에 대해서는 master로 동작

zone "localhost" IN {

type master;

file "localhost.zone";

allow-update { none; };

};

zone "0.0.127.in-addr.arpa" IN {

type master;

file "named.local";

allow-update { none; };

};

// 나머지 관리하는 forward/reverse zone에 대해서는 slave로 동작

zone "241.145.218.in-addr.arpa" IN { // 할당 IP 블락에 대한 Reverse Zone

type slave; // 해당 영역에 대해 slave (2차) 네임서버로서 운영됨

file "sec-241.145.218.in-addr.arpa"; //자동 생성

masters { 203.237.160.135; }; // Primary 네임서버의 IP 주소

};

zone "dtcinfo.net" IN { // 도메인 dtcinfo.net 에 대한 Forward Zone 파일 지정

type slave;

file "sec-dtcinfo.net"; // 자동 생성

masters { 203.237.160.135; }; // Primary 네임서버의 IP 주소

};

include "/etc/rndc.key";

(3) forward zone database file의 설정 내용 (p.)

ꋯ forward zone file

ꠚ domain name → IP 주소의 매핑 query를 처리하기 위한 정의

ꠚ 해당 영역에 대한 네임서버, 메일서버, 웹서버 등의 호스트 이름, 캐시 사용 기간 등의 사항 정의

zone database 파일은 여러 종류의 DNS 리소스 레코드라는 라인 단위의 항목을 설정하여 해당 영역에 필요한 사항을 설정한다. 위에서 주어진 시나리오에 필요한 내용들을 정의한 파일을 보면 다음과 같다.

ꋯ 파일 작성시 유의사항

ꠚ 띄어쓰기는 TABꍮ 을 이용해서 하도록 한다.

ꠚ 모든 공백라인은 주석 처리를 하도록 한다.

ꠚ 이 파일에서는 “;”로 주석을 시작한다. 주석은 해당 라인의 끝까지 유효하다.

ꠚ 네임 필드가 공란인 경우는 윗 라인의 네임 필드와 동일한 값임을 의미

ꋯ /var/named/zone-dtcinfo.net의 예

$TTL 86400 ; for cache-only server differentiated from Minimum

dtcinfo.net. IN SOA ns.dtcinfo.net. jslee.dtcinfo.net. ( ; SOA record

2003031706 ; Serial - 연월일일련번호 is a good practice

3600 ;Refresh (=1H), for 2nd name server

1800 ;Retry (=30M), for 2nd name server

1209600 ;Expire (=14D), for 2nd name server

86400) ;Minimum (=1D), Negative caching TTL

; SOA record와 다른 record는 한 줄 띄운다.

;네임 [기간] 클래스네임 레코드 종류 주소 또는 네임

@ IN NS ns ; NS record

IN NS ns2

;Host addresses

dtcinfo.net. IN A 203.237.160.135 ; A record

ns IN A 203.237.160.135 ; A record

ns2 IN A 218.145.241.59 ; A record

mail IN A 218.145.241.229 ; A record

www IN CNAME @ ; CNAME record

@ IN MX 10 mail ; MX record

mail IN MX 10 mail ; MX record

① SOA (start of authority) record

ꋯ 우측의 네임서버 (ns.dtcinfo.net.)가 좌측에서 정의한 영역 (dtcinfo.net.)에 대해 관리 권한을 위임받아서 정보를 제공함을 정의. 즉, 그 영역을 관리하도록 위임받은 네임서버를 표시

ꋯ 위임된 영역을 origin이라고 하며, 별도 지정이 없는 한 이 zone 파일을 선언한 named.conf의 zone 선언문에서 정의한 영역을 나타낸다. 다음 중 한 가지로 표현 가능

ꠚ @ : 메일 주소의 그것과는 구별되어야 함에 유의한다.

ꠚ dtcinfo.net. : domain name은 반드시 ROOT domain을 표시하는 “.”으로 종료하여야 함 (이것이 정식으로 도메인 이름을 나타내는 방법임)에 유의한다. 마지막에 “.”이 없는 것은 그 도메인에 속한 hostname으로 간주되어, 네임서버가 그 뒤에 자동으로 origin을 붙여서 해석하게 된다.

ꋯ jslee.dtcinfo.net.은 메일주소 jslee@dtcinfo.net를 의미한다. 단, “@”가 도메인의 표시에 사용되었기 때문에 “@” 대신 “.”을 사용한다.

ꋯ 위의 rule을 적용하면 SOA 레코드위 맨 위줄을 다음과 같이 쓰는 것이 가능

ꠚ

@ IN SOA ns jslee (

ꋯ TTL은 BIND version 8.x의 Minimum을 대체함

ꠚ query 결과를 캐시에 저장해 둘 시간을 초단위 (분, 시간, 일 단위 및 그것을 조합한 표시도 가능)로 표시

ꋯ Minimum (negative caching TTL)은 query 결과를 얻지 못한 것에 대해 TTL을 설정

② NS (name server) record

ꋯ SOA 영역 관리를 담당하는 네임서버를 정의

③ A (address) record

ꋯ 호스트의 IP 주소 정의. 이 레코드를 이용하여 호스트의 도메인네임 → IP 주소의 변환이 가능해짐

ꋯ 여러 개의 A 레코드를 이용하여 하나의 IP 주소에 여러 호스트 네임을 정의할 수 있다 (반대로, 부하 분산을 위해 하나의 호스트 네임에 여러 개의 IP 주소를 정의할 수 도 있음).

ꋯ primary, secondary 네임서버의 IP 주소는 도메인네임 등록시 상위 네임서버에 등록했기 때문에, (이를 glue record라고 함) 이에 대한 A 레코드는 사실상 불필요하다.

ꋯ 도메인 네임 그 자체도 IP 주소에 대응할 수 있다. 이것은 http://domain_name과 같은 형식의 URL 접근을 가능하게 해 준다.

ꠚ

C:\>nslookup dtcinfo.netꎠ

Server: swns.kornet.net ← cache-only server

Address: 61.77.63.1

Non-authoritative answer: ← answer using cache

Name: dtcinfo.net

Address: 203.237.160.135

④ CNAME (canonical name) record

ꋯ A record에서 정의한 실제 호스트네임(CNAME)에 대해 별칭을 지정해 준다.

ꋯ 하나의 CNAME에 대해 여러 개의 별칭을 지정할 수도 있다.

ꋯ default 설정으로는 서로 다른 두 개의 CNAME을 하나의 별칭으로 지정할 수 없다.

ꋯ NS 레코드는 별칭으로 지정할 수 없다.

ꋯ 아래의 MX 레코드는 별칭으로 지정하지 않는 것이 좋다.

ꋯ 동일한 IP 주소에 대해 여러 개의 호스트 네임을 설정하는데 있어서 허용되지 않는 경우를 제외하고는 A 레코드보다 CNAME 레코드를 사용하는 것이 IP 주소 변화에 대해 관리가 용이하다.

ꋯ 위에서 설정한 별칭의 질의 결과

ꠚ

C:\>nslookup www.dtcinfo.net ns.dtcinfo.netꎠ

Server: ns.dtcinfo.net ← primary 네임서버에서 응답

Address: 203.237.160.135

Name: dtcinfo.net ← www에 대한 CNAME

Address: 203.237.160.135

Aliases: www.dtcinfo.net ← www가 alias임을 표시

⑤ MX record

ꋯ 메일주소의 서버 부분이 왼쪽과 같을 때, 실제로 메일을 받을 서버의 이름을 지정

ꋯ 메일서버에 대한 IP 주소를 설정하기 위한 A record 지정

ꋯ Sending MTA (message transfer agent; 메일 서버를 의미)는 메일을 발송하기 위해 메일주소의 도메인 부분을 관리하는 네임서버에 MX 레코드에 대한 질의를 통해 메일서버를 알아내고 (1, 2), 실제로 메일을 받을 서버에 접속 (3)

ꋯ 다음은 nslookup 명령어를 이용하여 dtcinfo.net 도메인의 메일서버를 조회한 결과를 보여준다.

C:\>nslookupꎠ ← interactive 모드로 실행

Default Server: kns.kornet.net

Address: 168.126.63.1

> set type=MXꎠ ← 다음 도메인의 메일서버 조사

> dtcinfo.netꎠ ← dtcinfo.net

Server: kns.kornet.net

Address: 168.126.63.1

dtcinfo.net MX preference = 10, mail exchanger = mail.dtcinfo.net

dtcinfo.net nameserver = ns.dtcinfo.net

dtcinfo.net nameserver = ns2.dtcinfo.net

mail.dtcinfo.net internet address = 218.145.241.229

ꋯ MX 레코드에 대한 상세한 동작 원리와 설정에 관해서는 메일서버에서 다룬다.

(4) reverse zone database file의 설정

ꋯ reverse zone file : IP 주소 → domain name의 매핑 query를 처리

ꠚ 도메인 네임이 “호스트.기관명.TLD"과 같이 우측으로 갈수록 더 상위 계층을 나타내는 것과 달리 IP 주소는 우측으로 갈수록 하위 계층을 나타낸다. 따라서 IP 주소의 구조를 역으로 표현한 가상의 도메인을 구성하면 도메인 이름의 질의 절차와 같은 resolving 절차를 IP 주소의 질의에도 적용할 수 있게 된다.

ꠚ IP 주소 공간을 나타내기 위한 가상의 도메인은 in-addr.arpa 도메인이다. 모든 IP 주소 공간은 이 도메인의 서브도메인으로 표현된다.

ꠚ 아래의 예에서는 218.145.241.0의 C class IP 주소 범위에 대한 가상 도메인으로서 "241.145.218.in-addr.arpa"를 구성하였다.

ꠚ reverse zone은 도메인 신청과는 별도로 ISP에서 IP 주소를 할당받을 때 ISP에 “할당 받은 주소의 범위를 어떤 도메인 네임으로 사용하겠다”는 사항에 해당하는 inverse domain을 신청 (해당 IP 범위에 설정된 domain name을 알려줄 네임 서버를 등록해야 함) 해야 resolving 가능

ꠚ 별도의 등록을 하지 않은 경우에는 의미가 없으므로 생략 가능 (local loop인 127.0.0.1에 대해서는 생략 불가능)

ꋯ 이 파일은 호스트의 IP 주소를 그에 해당하는 도메인 네임으로 변환할 수 있도록 해 주기 위한 데이터베이스로, 앞서 언급한 것처럼 ISP에 reverse zone에 대한 등록이 별도로 되어 있지 않은 경우에는 의미가 없다.

ꋯ 특정한 서비스의 경우에 서비스를 이용할 수 있는 클라이언트의 범위를 제한하기 위해서 클라이언트의 IP 주소로부터 어떤 도메인에 속한 것인지, 호스트 명이 있는지를 검사하는 경우가 있다. 이 때 서버는 도메인네임 서버에 IP 주소에 대한 호스트 네임을 질의하여 이러한 사항을 확인하고 서비스 여부를 결정한다.

ꋯ 설정 파일의 예는 다음과 같다.

;zone-241.145.218.in-addr.arpa

$TTL 86400 ; for cache-only server differentiated from Minimum

@ IN SOA ns jslee (

2003031706 ;Serial

3600 ;Refresh ( 1 hours)

1800 ;Retry (30 minutes)

1209600 ;Expire (14 days)

86400) ;Minimum ( 1 day)

IN NS ns.dtcinfo.net.

IN NS ns2.dtcinfo.net.

;IP-domain mapping here

229 IN PTR redhat.dtcinfo.net.

; 218.145.241.0 class의 IP 주소에 대해 대응시킬 내용을 필요에 따라 계속 추가한다

ꋯ forward zone에서 A 레코드나 CNAME 레코드를 이용해서 하나의 IP 주소에 여러 호스트 네임을 설정할 수 있었던 것과는 달리, 그 역은 성립하지 않는다.

ꠚ 하나의 IP 주소에는 forward zone에서 A 레코드로 정의한 하나의 호스트 네임만이 할당 가능하다.

(5) 설정 결과의 검사 및 적용

① named가 현재 실행중인지 여부 확인

ꋯ

# pgrep namedꎠ

24546

24547

24548

24549

ꋯ 위와 같이 번호 (번호의 값은 다를 수도 있다)가 나타나지 않는다면 실행중인 프로세스가 없는 것이다. 이 경우 부팅시 자동 실행이 설정되어 있지 않은 상태이므로 ②와 같이 설정을 하고 나서 ④와 같이 실행시킨다.

ꋯ 실행중인 named 프로세스가 있다면 설정 내용을 적용하기 위하여 ⑤와 같이 재시동한다.

② 부팅시 자동 실행 설정

ꋯ ntsysv에서 설정한다.

③ 설정 내용의 오류 검사

ꋯ /etc/named.conf의 검사

ꠚ

# named-checkconf /etc/named.confꎠ

ꠚ 오류가 없을 시 아무런 메시지가 없음

ꋯ zone database 파일의 검사

ꠚ

# named-checkzone dtcinfo.net /var/named/zone-dtcinfo.netꎠ

zone-dtcinfo.net/IN: loaded serial 2005040102

④ 즉시 실행

ꋯ named는 standalone 방식으로 실행되므로 해당 대몬 스크립트를 직접 구동한다.

ꋯ

# /etc/rc.d/init.d/named startꎠ

named (을)를 시작합니다: [ 확인 ]

⑤ 재시동

ꋯ

# /etc/rc.d/init.d/named restartꎠ

named 를 정지함: [ 확인 ]

named (을)를 시작합니다: [ 확인 ]

ꋯ 만일 ⑤의 명령어 실행 결과 위의 화면에서와 같은이 named를 정지하는데 [확인]이 나타나지 않는다면 다음과 같은 조치가 필요하다 (RedHat9의 버그 때문).

⑥ named의 강제 종료후 재실행

ꋯ

# pkill -9 namedꎠ

# /etc/rc.d/init.d/named startꎠ

named (을)를 시작합니다: [ 확인 ]

⑦ named의 실행 확인

ꋯ

# pidof named (또는 pgrep named)ꎠ

36943 <--- named의 프로세스 번호

ꋯ 프로세스 번호가 나타나지 않는다면 설정상의 문제가 있어서 named가 가동되지 않았음을 의미하므로, 설정 파일의 오류 수정 작업이 필요하다. checkconf, checkzone 명령어의 실행 결과나 로그파일의 내용을 보면 설정 상에 어떤 문제가 있는지를 어느 정도 알 수 있다.

5) DNS의 설정 #2 - 부 도메인 (subdomain)의 운영과 도메인 위임

(1) 부 도메인의 개요

① 부 도메인에 대하여

ꋯ 일반적인 도메인의 사용법은 등록된 도메인에 대하여

“호스트명.도메인명.TLD"의 계층 형식으로 사용한다.

ꋯ 그러나, 경우에 따라서는 도메인의 아래 계층을 호스트명으로 사용하지 않고 다시 하위 도메인으로 나눌 수가 있다. 이 경우는 도메인명이 다음과 같은 구조를 가진다.

ꠚ 호스트명.1차 부도메인.도메인명.TLD

ꋯ 1차 부 도메인 아래 2차, 3차, … 부도메인을 설정하는 것도 가능하다.

② 부 도메인의 용도

ꋯ 하나의 도메인으로 나타내기에는 호스트의 종류가 너무 많고 광범위한 이름을 가질 경우에 사용

ꠚ 예를 들면 abc.net이라는 다국적 기업이 각 국마다 웹서버, 메일서버, 데이터베이스 서버, 파일서버, … 등을 운영한다면 호스트명 만으로 이들을 구분하기가 어렵다. 이럴 때는 다음과 같이 부 도메인을 나누고, 이 부 도메인에 호스트를 두면 된다.

국가	부 도메인명	호스트명
한국	kr.abc.net	www.kr.abc.net, mail.kr.abc.net, db.kr.abc.net, …
미국	us.abc.net	www.us.abc.net, mail.us.abc.net, db.us.abc.net, …
일본	jp.abc.net	www.jp.abc.net, mail.jp.abc.net, db.jp.abc.net, …
영국	uk.abc.net	www.uk.abc.net, mail.uk.abc.net, db.uk.abc.net, …

ꋯ 또 다른 예로는 sub domain에 대한 등록 서비스 제공을 할 수 있다. 실제로 많은 무료 도메인 제공 서비스가 바로 부 도메인을 제공하는 것이다.

③ 운영 방법

ꋯ 메인 도메인 네임 서버에서 모두 관리하는 방법 1

ꠚ 메인 도메인 네임 서버의 abc.net에 대한 zone 파일에서 부 도메인의 호스트 이름을 A record로 정의한다. 하위 도메인 이름까지 호스트 이름의 일부로 간주된다.

ꠚ

...

www.kr.abc.net. IN A 111.222.111.222 ;모두 abc.net의

mail.kr.abc.net. IN A 111.222.111.223 ; 호스트들로

...

www.us IN A 111.222.111.226 ; 간주하여

mail.us IN A 111.222.111.227 ; 정의됨

...

ꠚ 메인 도메인 네임 서버에서 모두 관리하는 방법 2

o 메인 도메인 네임 서버의 abc.net에 대한 zone 파일에서 하위 부 도메인의 네임 서버를 자기 자신으로 정의하여 위임

o 메인 도메인 네임 서버의 부트파일인 /etc/named.conf 파일에서 부 도메인을 관리할 zone 파일을 선언

o 메인 도메인 네임 서버에서 부 도메인을 관리할 zone 파일을 설정

ꋯ 하위 부 도메인 네임 서버에서 관리하는 방법

ꠚ 메인 도메인 네임 서버의 abc.net에 대한 zone 파일에서 하위 부 도메인 네임 서버를 정의하여 위임

ꠚ 위임받은 하위 부 도메인 네임 서버의 부트파일인 /etc/named.conf 파일에서 부 도메인을 관리할 zone 파일을 선언

ꠚ 위임받은 하위 부 도메인 네임 서버에서 부 도메인을 관리할 zone 파일을 설정

후자의 방법은 전체 도메인 네임 공간에서 상위 네임 서버가 하위 네임 서버에게 관리를 위임하는 전형적인 방식이다. 사실 root 도메인 서버가 .com, .net, .org 네임 서버에게 TLD를 관리하도록 위임하는 것이나, .net 네임서버가 abc.net의 네임서버에게 abc.net 도메인을 관리하도록 위임하는 것도 이와 같은 방법으로 이루어지는 것이다. 차이는 단지 공인을 받은 도메인인가 아닌가 하는 것이지, resolving 되는 계층적 절차나 결과는 똑같다.

이 과정에서는 후자의 방법을 학습하고 실습한다.

(2) 시나리오 (실습)

① 각 실습자는 dtcinfo.net의 부 도메인 sdx.dtcifo.net (x는 PC 번호)을 위임받아 그 영역에 대한 관리를 하는 네임서버를 구축하고 운영한다.

② 부 도메인의 primary 네임서버는 실습자의 서버에 구축하며, ns.sdx.dtcinfo.net의 호스트 이름을 가진다. secondary 네임서버는 구축하지 않는다.

ꋯ 네임서버는 forward zone 만을 관리하며, reverse zone은 설정하지 않는다.

③ 이를 위해 dtcinfo.net의 네임서버 ns.dtcinfo.net는 부 도메인을 네임서버 ns.sdx.dtcinfo.net에게로 위임한다.

④ 각 부 도메인에서 사용할 수 있는 IP 주소는 2개이며, 해당 부 도메인에는 다음과 같은 시스템이 존재한다.

ꋯ

용도	FQDN	IP 주소	비 고
네임서버	ns.sd1.dtcinfo.net	218.145.241.141
웹서버	www.sd1.dtcinfo.net	218.145.241.141	네임서버의 alias
메일서버	mail.sd1.dtcinfo.net	218.145.241.201

ꋯ 4) 절의 시나리오처럼 도메인 이름 (sd1.dtcinfo.net)으로도 웹 (http://sd1.dtcinfo.net) 및 메일 (user_name@sd1.dtcinfo.net) 접속이 가능하여야 함

(3) 서버에 IP 주소를 추가로 할당하기

ꋯ 위의 표에서 네임서버와 메일서버가 별도로 있는 것이 아니라, 1대의 서버에 IP 주소만 2개 할당하여 별도의 2대의 서버인 것처럼 가상으로 운영한다.

ꋯ 이를 위해, 현재 서버의 NIC에 또다른 IP 주소를 할당하고, zone database 설정에서 그에 대해 mail.sd1.dtcinfo.net이라는 도메인명을 지정해 준다.

ꋯ NIC에 또다른 IP 주소를 할당하는 IP aliasing 설정은 xinetd 실습시의 설정을 그대로 유지한다.

(4) hostname 변경

ꋯ hostname을 info1.dtcinfo.net에서 ns.sd1.dtcinfo.net로 변경

ꠚ 반드시 그렇게 해야 하는 사항은 아니지만, sd1.dtcinfo.net 부 도메인을 관리하는 네임서버이므로 그 사항을 명확히 하기 위해 이름 변경

ꠚ /etc/sysconfig/network 파일에서 HOSTNAME을 다음과 같이 편집

...

HOSTNAME=ns.sd1.dtcinfo.net

...

ꋯ 변경 내용을 반영하려면 시스템을 재시동해야 함

(5) dtcinfo.net의 네임서버 설정

① dtcinfo.net 도메인을 관리하는 네임서버 설정

ꋯ ns.dtcinfo.net의 zone database 파일 설정

ꋯ 상위 도메인 (dtcinfo.net) 관리자가 수행할 내용이며, 실습자들이 실습할 사항은 없음

② 설정 내용

ꋯ 실습자들을 위해 (2)의 부 도메인 위임 시나리오에 맞게 위임 사항을 설정하고 반영함

; 위임할 부 도메인과 그를 관리할 네임서버를 설정해 줌

sd1 IN NS ns.sd1 ; sd1 부도메인 위임

ns.sd1 IN A 218.145.241.141 ; glue record

sd2 IN NS ns.sd2 ; sd2 부도메인 위임

ns.sd1 IN A 218.145.241.142 ; glue record

...

(6) sd1.dtcnet.org 부 도메인 네임 서버의 설정

① /etc/named.conf 파일 설정

ꋯ sd1.dtcinfo.net 영역을 정의하고, 이 영역의 설정을 위한 영역 데이터베이스 파일을 지정하는 내용이 추가되어야 한다. 파일명은 적당히 정한다.

ꋯ 4)-(2)를 참고한다.

② 영역 데이터베이스 파일 설정

ꋯ (2)-④에서 정의한 내용대로 데이터베이스 파일을 생성하여 저장한다.

ꋯ 4)-(3)의 예를 참고한다.

ꋯ 설정 테스트 중에는 TTL 및 Minimum의 값을 1분 이내로 매우 짧게 하여 query를 하는 쪽에서 갱신된 내용을 바로 반영할 수 있도록 한다.

(7) 명령어를 이용하여 named.conf 파일과 영역 데이터베이스 파일의 설정 내용에 이상이 없는지 검사

(8) 설정 내용을 반영하여 named를 시작하고, 실행 확인. 실행이 안될 경우는 로그파일의 마지막 부분을 검사하여 문제점 분석 후 다시 설정하여 재실행

(9) 각 팀원은 nslookup 명령어를 이용하여 자신의 서버 및 상대방 서버에 대해 설정이 정확하게 되었는지를 테스트한다. MX 레코드도 확인한다.

(10) 문제가 있는 것을 보고하고, 수정하여 다시 실행한다.

(11) 로그파일에서 실습한 부분에 대한 로그를 찾아 기록한다.

6) DNS의 설정 #3 - 다중 도메인의 운영

(1) 다중 도메인의 개요

① 다중 도메인을 이용한 도메인 파킹 서비스

ꋯ 각 도메인마다 네임서버를 모두 따로 두어 운영을 할 필요는 없다. 즉, 하나의 네임서버가 여러 개의 도메인을 관리할 수 있다.

ꋯ 도메인 파킹을 제공하는 업체에서는 수많은 도메인에 대한 관리 서비스를 제공하고 있는데, 이것이 대표적 사례이다.

② 운영 방법

ꋯ registrar를 통하여 새로운 도메인을 신청, 등록

ꠚ 등록시 네임서버는 도메인 파킹 서비스를 담당할 네임 서버의 FQDN과 IP 주소로 지정

ꋯ 도메인 파킹 서비스를 맡을 네임서버의 부트파일 /etc/named.conf에 관리할 도메인에 대한 zone 설정을 추가

ꋯ 네임서버에 추가된 zone 설정에 해당하는 zone 파일을 생성후 네임서버 재시동

ꋯ 관리할 도메인이 추가될 때마다 위의 과정 반복

(2) 시나리오

ꋯ 새로이 신청한 dtcnet.org 도메인을 네임서버 ns.dtcinfo.net가 도메인 파킹 서비스를 하도록 함

항목	내용	IP 주소	비 고
추가 도메인	dtcnet.org
네임서버	ns.dtcinfo.net ns2.dtcinfo.net	203.237.160.135 218.145.241.59	primary 네임서버, dtcinfo.net의 것 이용 secondary 네임서버, " "
웹서버	www.dtcnet.org	218.145.241.229	접속 URL은 4)-(1)-②와 같은 조건
메일서버	mail.dtcnet.org	203.237.160.135	메일주소는 4)-(1)-③과 같은 조건

ꋯ 도메인 네임 ns.dtcorg.net 등록 신청시 주/보조 네임서버는 위의 표와 같이 각각 ns.dtcinfo.net, ns2.dtcinfo.net으로 설정

(3) 네임서버 설정 방법 #1

① ns.dtcinfo.net (primary 서버)의 부트파일 - /etc/named.conf

ꋯ 새로운 도메인에 대한 zone 설정의 추가

// generated by named-bootconf.pl

//생략 ...

zone "dtcnet.org" IN { // dtcnet.org의 forward Zone 파일 지정

type master;

file "zone-dtcnet.org";

};

// 생략 ...

② ns2.dtcinfo.net (secondary 서버)의 부트파일 - /etc/named.conf

ꋯ 새로운 도메인에 대한 zone 설정의 추가

// generated by named-bootconf.pl

//생략 ...

zone "dtcnet.org" IN { // 도메인 dtcnet.org 에 대한 Forward Zone 파일 지정

type slave;

file "sec-dtcnet.org";

masters { 203.237.160.135; }; // Primary 네임서버의 IP 주소

};

// 생략 ...

③ ns.dtcinfo.net에서 dtcnet.org 도메인 관리를 하기 위한 zone 파일

ꋯ /var/named/zone-dtcnet.org

$TTL 86400 ; for cache-only server differentiated from Minimum

dtcnet.org. IN SOA ns.dtcinfo.net. jslee.dtcnet.org. ( ; SOA record

2003031706 ; Serial

3600 ;Refresh

1800 ;Retry

1209600 ;Expire

86400) ;Minimum

@ IN NS ns.dtcinfo.net. ; 이들에 대한 A record

IN NS ns2.dtcinfo.net. ; 는 필요 없음

;Host addresses

@ IN A 218.145.241.229 ; A record

mail IN A 203.237.160.135 ; A record

www IN A 218.145.241.229 ; A record

@ IN MX 10 mail ; MX record

mail IN MX 10 mail ; MX record

...

(4) 네임서버 설정 방법 #2

ꋯ 도메인 파킹 서버에서는 하나의 네임서버가 여러 개의 도메인을 관리한다. 만일 IP 주소가 하나만 할당된 서버 한 대로 여러 도메인에 대해 웹 호스팅도 한다고 하자

ꋯ 이 경우, 각 도메인의 웹서버의 호스트 네임은 모두 동일한 IP 주소로 대응될 것이다. 만일 이들의 호스트 네임이 모두 www로 같다면 zone 파일을 도메인마다 각각 따로 만들지 않고 좀 더 간단하게 운영하는 것이 가능하다. 즉, 이러한 경우에는 이 네임서버에서 관리할 모든 forward zone을 하나의 zone 파일로 통합하여 설정할 수 있다. 이것이 가능한 이유는 영역 데이터베이스 파일에서 관리 영역에 해당하는 origin의 도메인 이름을 명시적으로 쓰지 않고 “@”로 나타낼 수 있기 때문이다.

ꠚ 관리할 도메인

도메인

웹서버

IP 주소

네임서버

비 고

aaa.com

bbb.com

aaa.net

bbb.net

...

www.aaa.com

www.bbb.com

www.aaa.net

www.bbb.net

...

218.145.241.229

ns.dtcinfo.net

ns2.dtcinfo.net

접속 URL은 4)-(1)-②와 같은 조건

ꠚ /etc/named.conf - 모든 영역에 대해 영역 데이터베이스 파일을 같은 것으로 설정한다 (예: default.zone)

// generated by named-bootconf.pl

//생략 ...

zone "aaa.com" IN { // aaa.com의 forward Zone 파일 지정

type master;

file "default.zone"; // 동일한 영역파일 지정

};

zone "bbb.com" IN { // bbb.com의 forward Zone 파일 지정

type master;

file "default.zone"; // 동일한 영역파일 지정

};

zone "aaa.net" IN { // aaa.net의 forward Zone 파일 지정

type master;

file "default.zone"; // 동일한 영역파일 지정

};

// 생략 ...

ꠚ /var/named/default.zone - 모든 zone의 영역파일을 통일

$TTL 86400 ; for cache-only server differentiated from Minimum

@ IN SOA ns.dtcinfo.net. root ( ; SOA record

2003031706 ; Serial

3600 ;Refresh

1800 ;Retry

1209600 ;Expire

86400) ;Minimum

@ IN NS ns.dtcinfo.net. ; NS record

IN NS ns2.dtcinfo.net.

;Host addresses

@ IN A 218.145.241.229 ; A record

www IN A 218.145.241.229 ; A record

ꋯ 만일 각 도메인 영역마다 설정이 완전히 일치하지 않으면 named.conf 파일에서 영역 파일을 개별적으로 선언하되, 공통되는 부분에 대해서는 공통의 영역파일을 만들어 놓고 개별적인 파일에서 그것을 include 시킨다. 예를 들어서 aaa.net만 별도의 다른 IP 주소를 가지는 ftp, mail 서버가 있다면 다음과 같이 설정한다.

ꠚ /etc/named.conf

// generated by named-bootconf.pl

//생략 ...

zone "aaa.com" IN { // aaa.com의 forward Zone 파일 지정

type master;

file "default.zone"; // 동일한 영역파일 지정

};

zone "bbb.com" IN { // bbb.com의 forward Zone 파일 지정

type master;

file "default.zone"; // 동일한 영역파일 지정

};

zone "aaa.net" IN { // aaa.net의 forward Zone 파일 지정

type master;

file "zone-aaa.net"; // 별도의 영역파일 지정

};

// 생략 ...

ꠚ /var/named/default.zone - 공통의 영역파일 (이전과 동일)

ꠚ /var/named/zone-aaa.net - aaa.net zone 고유의 영역파일

$INCLUDE default.zone ; 공통 부분을 포함시킴

; 아래와 같이 default.zone에서 설정되어 있는 내용 이외의 설정 사항을 추가함

mail IN A 203.237.160.135 ; A record

ftp IN A 218.145.241.229 ; A record

ꠚ 메일 서버, ftp 서버 등도 모든 도메인에 대해 같은 IP 주소라면 별도의 zone 파일로 분리하지 않고 웹서버의 예와 마찬가지로 공통 파일로 관리할 수 있다.

(5) 실습 예제

ꋯ sda1.dtcinfo.net, sd1.dtcnet.org 두 개의 부 도메인을 하나의 영역 데이터베이스 파일로 관리

용도	도메인명	IP 주소	비 고
네임서버	ns.sd1.dtcinfo.net	218.145.241.141	sd1.dtcinfo.net의 네임서버와 동일
웹서버	www.sda1.dtcinfo.net www.sd1.dtcnet.org	218.145.241.201	접속 URL은 4)-(1)-②와 같은 조건
메일서버	mail.sda1.dtcinfo.net mail.sd1.dtcnet.org	218.145.241.141	메일 주소는 4)-(1)-③과 같은 조건

ꋯ 부 도메인의 파킹을 담당하는 priamry 네임 서버는 ns.sd1.dtcinfo.net이다.

ꠚ 상위의 도메인 네임 서버 (ns.dtcinfo.net)에서 해당 부 도메인을 아래와 같이 위임하였음

; /var/named/zone-dtcninfo.net 파일에서 위임한 부분을 보여줌

...

sda1 IN NS ns.sd1 ; delagation

sda2 IN NS ns.sd2 ; delagation

...

; /var/named/zone-dtcnet.org 파일에서 위임한 부분을 보여줌

...

sd1 IN NS ns.sd1.dtcinfo.net. ; delagation

sd2 IN NS ns.sd2.dtcinfo.net. ; delagation

...

ꋯ 이를 위해서 ns.sd1.dtcinfo.net의 /etc/named.conf 파일에 해당 도메인을 위한 zone 선언을 추가한다. 이때, forward zone 파일명을 모두 default-zone으로 선언한다.

ꋯ 앞의 표에 맞도록 공통의 영역 데이터베이스 파일 default-zone을 설정한다.

ꋯ 명령어를 이용하여 named.conf 파일과 영역 데이터베이스 파일의 설정 내용에 이상이 없는지 검사

ꋯ named 대몬을 종료시키고 (방법은 앞의 설명 및 실습 참조) 설정된 내용을 반영하여 다시 시동한다.

ꋯ nslookup 등의 명령어를 이용하여 팀의 상대방 시스템과 자신의 시스템에 대한 설정 결과를 확인한다. MX 레코드에 대한 설정 결과도 확인한다.

ꋯ 문제가 있는 것을 보고하고, 문제점을 수정하여 다시 확인한다.

ꋯ 로그파일 내용 중에서 실습과 관련이 있는 부분을 기록하고 분석한다.

3. 기타 설정

1) Dynamic update

(1) Dynamic update의 의미와 기능

ꋯ 어떤 도메인의 zone 레코드를 갱신할 때, zone 파일을 수정하여 네임서버를 재시동하는 절차를 거치지 않고 원격에서 동적으로 레코드를 갱신할 수 있게 하는 것.

ꋯ 도메인 관리를 자동화하거나 유동 IP에 대해 도메인 네임을 부여하는 동적 DNS 서비스 (dynamic DNS; DDNS)에 유용

ꋯ default로는 사용 불가로 설정되어 있으므로, /etc/named.conf에서 허용할 zone의 선언문에 다음의 옵션 추가

ꠚ

// generated by named-bootconf.pl

//생략 ...

zone "abc.com" IN {

type master;

file "zone-abc.com";

allow-update { 111.222.111.222; }; // UPDATE FROM where?

};

// 생략 ...

ꋯ update가 허용된 곳에서 nsupdate 명령어를 이용하여 update 가능

ꋯ update 내용은 즉시 적용되며, named가 종료될 때 zone database에 기록됨

(2) 예제

① 시나리오

네임서버	oslab.dtcinfo.net
동적 update를 할 영역	dynaip.dtcinfo.net
동적 update를 허용해 줄 원격 시스템	218.145.241.0 네트워크, 203.237.160.0 네트워크
동적 update를 할 호스트 명	www, ftp, … 등

ꋯ 여기서는 www.dynaip.dtcinfo.net의 A 레코드를 원격에서 동적으로 관리하는 예를 보인다.

ꠚ IP 주소를 203.237.160.7을 설정했다가 203.237.160.88로 변경

ꋯ 실제 상황에서는 보안상 확실한 시스템에서의 동적 갱신만을 허용하는 것이 좋다.

② 설정

ꋯ oslab의 named.conf 파일에는 해당 영역을 다음과 같이 정의해야 한다.

[root@oslab root]# cat /etc/named.confꎠ

// generated by named-bootconf.pl

//생략 ...

zone "dynaip.dtcinfo.net" IN {

type master;

file "zone-dynaip.dtcinfo.net";

allow-update { 203.237.160/24; 218.145.241/24; };

};

// 생략 ...

[root@oslab root]#

ꋯ oslab의 zone-dynaip.dtcinfo.net 영역 파일은 다음과 같이 호스트의 IP 주소 설정이 하나도 없도록 초기화하였다.

[root@oslab root]# cat /var/named/zone-dynaip.dtcnfo.netꎠ

$TTL 10 ; for cache-only server differentiated from Minimum

@ IN SOA oslab.dtcinfo.net. jslee ( ; SOA record

2005041706 ; Serial

3600 ;Refresh

1800 ;Retry

1209600 ;Expire

10) ;Minimum

@ IN NS oslab.dtcinfo.net. ; NS record

;Host addresses (현재 A 레코드는 정의된 것이 없음)

[root@oslab root]#

ꋯ named를 재시작한다.

③ 원격 시스템으로부터의 설정

ꋯ www.dynaip.dtcinfo.net을 원격으로 설정하기 전에 이것의 A 레코드가 없는 것을 확인

[root@ns ~]# nslookup www.dynaip.dtcinfo.netꎠ

Server: 203.237.160.8

Address: 203.237.160.8#53

** server can't find www.dynaip.dtcinfo.net: NXDOMAIN

[root@ns ~]#

ꋯ named.conf에서 동적 update를 허용해 둔 시스템으로부터 nsupdate 명령어를 이용하여 원격 update를 실행

[root@ns ~]# nsupdateꎠ

> update add www.dynaip.dtcinfo.net. 10 IN A 203.237.160.7ꎠ

> ꎠ

> ꍭꎀ

[root@ns ~]#

④ 설정 확인

ꋯ www.dynaip.dtcinfo.net의 IP 주소를 확인

[root@ns ~]# nslookup www.dynaip.dtcinfo.netꎠ

Server: 203.237.160.8

Address: 203.237.160.8#53

Name: www.dynaip.dtcinfo.net

Address: 203.237.160.7

[root@ns ~]#

⑤ oslab 네임서버의 zone 데이터베이스 파일 확인

ꋯ zone 데이터베이스 파일에는 아직 적용되지 않았다. 그러나 위에서 본 것과 같이 네임서버는 적용된 결과를 반영하여 응답한다.

ꋯ oslab 네임서버의 zone 파일이 저장되어 있는 /var/named 디렉토리 내용에 다음과 같은 journal 파일이 추가로 생성된다.

[root@oslab root]# ll /var/namedꎠ

합계 24

-rw-r--r-- 1 named named 195 1월 25 2003 localhost.zone

-rw-r--r-- 1 named named 2499 1월 25 2003 named.ca

-rw-r--r-- 1 named named 433 1월 25 2003 named.local

-rw------- 1 named named 370 3월 10 21:46 zone-dynaip.dtcinfo.net

-rw-r--r-- 1 named named 3284 3월 11 17:42 zone-dynaip.dtcinfo.net

.jnl

[root@oslab root]#

ꋯ 네임서버를 종료하고 다시 실행

ꋯ 변경 내용이 적용되었다 (어느 정도 시간이 지나야 함).

[root@oslab root]# cat /var/named/zone-dynaip.dtcnfo.netꎠ

$ORIGIN .

$TTL 10 ; 10 seconds

dynaip.dtcinfo.net IN SOA oslab.dtcinfo.net. jslee.dynaip.dtcinfo.net. (

2005041709 ; serial

3600 ; refresh (1 hour)

1800 ; retry (30 minutes)

1209600 ; expire (2 weeks)

10 ; minimum (10 seconds)

)

NS oslab.dtcinfo.net.

$ORIGIN dynaip.dtcinfo.net.

www A 203.237.160.7 ; 적용이 되었음

[root@oslab root]#

⑥ 동적 update

ꋯ www.dynaip.dtcinfo.net의 IP 주소가 변경되었다고 가정하고, 이것을 적용하기 위해 다시 한번 nsupdate를 실행

[root@ns ~]# nsupdateꎠ

> update delete www.dynaip.dtcinfo.net. IN A 203.237.160.7

>ꎠ

> update add www.dynaip.dtcinfo.net. 10 IN A 203.237.160.88

>ꎠ

> ꍭꎀ

[root@ns ~]#

⑦ 변경 결과 확인

ꋯ www.dynaip.dtcinfo.net의 IP 주소를 확인

[root@ns ~]# nslookup www.dynaip.dtcinfo.netꎠ

Server: 203.237.160.8

Address: 203.237.160.8#53

Name: www.dynaip.dtcinfo.net

Address: 203.237.160.88

[root@ns ~]#

(3) 실습

① 시나리오

ꋯ

네임서버	ns.sd1.dtcinfo.net
동적 update를 할 영역	dyn.sd1.dtcinfo.net
동적 update를 허용해 줄 원격 시스템	팀원의 IP 주소
동적 update를 할 호스트 명	myhome.dyn.sd1.dtcinfo.net
호스트의 IP 주소	임의로 설정

② 네임서버의 named.conf 파일에 영역 정의

ꋯ 팀원이 원격 update를 할 수 있도록 설정

③ 영역 데이터베이스파일 생성

ꋯ 팀원이 원격에서 설정을 할 것이므로 별도의 A 레코드는 만들지 않는다.

④ named 재시작

⑤ 시나리오에 맞게 팀원이 원격에서 nsupdate 명령을 이용하여 myhome.dyn.sd1.dtcinfo.net의 IP 주소를 원격 설정

⑥ nslookup 명령어를 이용하여 팀원 및 본인이 결과 확인

⑦ 팀원이 IP 주소를 원격에서 변경

ꋯ 임의의 IP 주소로 변경해 본다.

⑧ 팀원 및 본인이 변경사항을 확인

2) 다중 서버에 대한 단일 도메인 할당 (대표 도메인)

ꋯ 서로 다른 IP 주소를 가지는 여러 대의 시스템에 동일한 호스트명을 부여

ꋯ 서비스 부하가 큰 사이트에서 여러 대의 서버로 부하를 분산시켜서 운영을 하는 경우 유용

(1) shuffle address 기법

ꋯ

www.chosun.com 180 IN A 218.145.28.100

www.chosun.com 180 IN A 218.145.28.200

ꋯ

C:\>nslookup www.chosun.com

Server: swns.kornet.net

Address: 61.77.63.1

Non-authoritative answer:

Name: www.chosun.com

Addresses: 218.145.28.100, 218.145.28.200

C:\>nslookup www.chosun.com

Server: swns.kornet.net

Address: 61.77.63.1

Non-authoritative answer:

Name: www.chosun.com

Addresses: 218.145.28.200, 218.145.28.100

ꠚ local name server는 authority name server에서 round robin된 다수의 IP 주소를 넘겨받아 자체적으로 round robin하여 응답

(2) 실습

① 시나리오

ꋯ

네임서버	ns.sd1.dtcinfo.net
호스트명	blog.sd1.dtcinfo.net
할당 IP 주소	팀원의 IP 주소 2개

② 영역 데이터베이스 파일 설정

ꋯ 시나리오에 맞게 A 레코드 설정 후 네임서버 재시동

③ 결과 확인

ꋯ blog.sd1.dtcinfo.net에 5차례 ping을 한다. target IP 주소가 어떻게 변하는지 관찰한다.

ꠚ ping을 마칠 때는 ꍭꍿ를 누르거나, ping 명령에 -c n (n은 반복할 횟수) 옵션을 주어 실행한다.

ꋯ 결과를 설명해 보자.

3) Wildcard

ꋯ 영역파일의 레코드에서 네임 필드에 wildcard (*)를 사용하면, 정의된 이름을 제외한 모든 임의의 이름이 해당 레코드에서 정의된다.

ꋯ 예

ꠚ

www.dtcinfo.net. IN A 218.145.241.100

*.dtcinfo.net IN A 218.145.241.101

ꠚ www.dtcinfo.net를 제외한 ftp.dtcinfo.net, web.dtcinfo.net, file.dtcinfo.net, ... 등은 모두 218.145.241.101에 매칭됨

공유하기 링크

페이스북
카카오스토리
트위터

공지사항

최근에 올라온 글

최근에 달린 댓글

Total

Today

Yesterday

링크

프링글이 하는 이야기

티스토리 뷰

네임서버 설정 참고사항 / 다이나믹 DNS 참고 사항

티스토리툴바