[KITRI] Day16. 네임 서버 구축

네임 서버의 개요

우리가 자주 사용하는 URL의 경우 http://www.naver.com -> 프로토콜://도메인네임 이와 같은 구조로 사용된다.

실제 원하는 서버에 접근하려면 이 URL을 해당 컴퓨터의 IP 주소로 변환시켜야 하는데, 바로 이 일을 네임 서버 또는 DNS(Domain Name Service) 서버라는 컴퓨터가 담당한다.

이때 www.naver.com 을 IP 주소 125.209.222.142 라는 IP주소로 변환하는 과정을 이름 해석(name resolution)이라고 한다.

 

리눅스에서 /etc/resolv.conf 라는 설정 파일에서 어떤 nameserver를 통해 질의할 것인지를 정의한다.

 

nslookup 명령어를 통해 도메인에 대한 ip를 물어볼 경우 기본적으로 resolv.conf에 설정한 네임서버에 질의를 하여 원하는 URL의 IP를 확인할 수 있다. nslookup URL 네임서버 와 같은 형식을 사용하면 지정한 네임서버 말고 다른 네임 서버에게 물어볼 수 있다.

 

web browser 또는 command에 도메인네임을 입력하면 일련의 과정을 통해 실제 통신가능한 ip주소를 가져온다.

1. 도메인 네임 입력

2. /etc/host.conf에 설정된 우선순위에 따라 hosts참조, DNS질의 를 순서대로 진행한다.

order hosts,bind 로 설정할경우 hosts 파일을 검사하고 DNS에 질의를 수행하게 된다.

2-1 hosts : /etc/hosts 파일을 우선 참조하여 해석

2-2 bind : /etc/resolv.conf 파일에 저장된 NS에게 질의

3. 응답이 돌아오면 원하는 ip주소로 접근이 가능하며 응답을 알 수 없는 경우 통신은 실패하고 통신을 진행하지 않는다.

 

도메인 이름 체계

모든 도메인의 최상위에서는 . (Root Domain)이 존재한다.

https://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/jsp/resources/dns/dnsInfo.jsp

TLD(Top Level Domain)

-com

-net

-org

-edu

 

-kr

-fr

sp

 

SLD(Second-Level Domain)

-nate

-naver

-co

-or

 

이런식으로 파생되어 트리구조로 이루어져 있다.

일반 도메인(gTLD) : com, net, org, edu, ..

일반 도메인의 경우 뒤에 바로 기관을 나타내는 도메인인 naver, google 등과 같은 도메인이 온다

국가 도메인(ccTLD) : kr, fr, sp, ..

국가 도메인의 경우 뒤에 기관의 성격을 나타내는 co, or 과 같은 도메인이 온다.

특수 도메인 : arpa

 

네임 서버에 도메인을 질의 할때 제일 먼저 로컬에 있는 네임서버 즉, DNS 캐시를 찾아본다. 캐시에 찾는 도메인이 있을경우 바로 알려주지만 없을 경우에 Root Name Server로 질의를 시작하는 것이다. 이때 질의 방법으로는 재귀적(recursive) 질의와 반복적(iterative) 질의 2가지가 존재한다.

http://blog.naver.com/cccgh5?Redirect=Log&logNo=60181596138

클라이언트로 부터 도메인 네임 질의 요청이 들어올 경우 네임서버가 직접 Name space를 탐색하여 결과값을 반환하는 과정 즉, 네임서버가 다른 네임서버와 질의과정을 연속으로 수행하는 것을 재귀적 질의라고 한다.

자신이 직접 관리하지 않는 질의 요청이 있을 경우 질의에 응답 가능한 NS목록을 응답하는 방식을 반복적 질의라고 한다.

 

캐싱 전용 네임 서버

캐싱 전용 네임 서버는 PC에서 URL로 IP주소를 얻고자 할때 해당하는 URL의 원래 IP주소를 알려주는 네임서버를 말한다. 로컬에 있는 네임서버가 캐싱 전용 네임서버의 역할을 수행한다.

 

네임 서버 구축

네임 서버 운영에 필요한 패키지들은 bind, bind-chroot, bind-libs, bind-utils 들이 있다.

rpm -qa | grep bind 를 통해 확인하면 대부분 이미 설치가 되어있는것을 확인할 수 있다.

네임 서버 운영에 필요한 조회같은 유틸리티들이 bind-utils에 들어가 있고 bind-libs에는 bind 데몬에서 사용하는 함수들이 들어가 있다. bind-chroot 는 있으면 좋고 없어도 구동하는데 문제없는 패키지이다. chroot는 보안상의 이유로 root 디렉토리의 위치를 가짜 root의 위치를 만들어 진짜 / 디렉토리로 네임서버를 통해 이동할 수 없도록 해주는 패키지이다.

우선은 디렉토리의 원래 모양 대로 확인하기 위해 bind-chroot를 지우고 진행하자 

 

용어

패키지 - bind

데몬 - named

계정 - named ( grep named /etc/passwd 확인 가능), 홈디렉토리 - /var/named

 

네임서버 운영에 필요한 파일들

/etc/named.conf : 서버의 전역 설정내용이 저장된 파일

/etc/rndc.conf : rndc(remote name domain controller), 원격으로 NS 서버를 관리하는 설정파일

/etc/rndc.key : 원격 NS서버에 접속시 사용되는 키(대칭키)

/var/named/*.zone : 특정 도메인 관리를 위한 파일

 

필요한 파일들은 yum install -yq caching-nameserver로 직접 다운로드를 진행하면 저절로 생성되는것을 확인할 수 있다. 하지만 이번에는 caching-nameserver 설치를 통해 생성하지 않고 직접 생성해보자.

 

rpm -ql bind에서 확인가능한 bind 패키지를 설치하면 같이 설치되는 목록중 /usr/share/doc/bind-9.3.6/sample/etc/named.conf 에 위치한 named.conf 샘플 파일을 복사해서 /etc 밑에 붙여넣어 해당 파일을 사용해 naemd.conf 파일을 설정하자.

 

named.conf 수정

샘플파일 이기 때문에 불필요한 주석들과 아직 설정할 필요없는 내용들이 있는 24행부터 맨 마지막 까지 전부 지운다.

그리고 네임서버의 전역설정을 위해 options안에 새롭게 내용을 추가하면 된다.

 

listen-on port 53 { 127.0.0.1; 192.168.252.15; }; 라는 내용을 추가하면 네임서버가 53번 포트를 사용해 해당 ip로 질의하는 것을 허용하게 하는 설정이다.

저장한뒤 service named restart를 통해 설정내용을 재적용한 후 nslookup 을 통해 루프백과 자신의 서버 아이피를 통해 도메인에 대한 질의를 수행하면 정상적으로 결과를 얻어낼 수 있게 된다.

listen-on port 안의 ip에 any 또는 0.0.0.0/0을 사용하면 여러 랜카드가 달려있어 ip가 여러개인 경우 모든 ip에게 도메인에 대해 질의하여도 전부 대답해준다.

listen-on-v6 port 53 { ::1; }; ipv6 를 사용할 경우 로컬호스트에 대해서도 허용하는 설정이다.

allow-query { 127.0.0.1; 192.168.252.15; }; 는 어떤 출발지 ip를 허용할지 설정할 수 있다. 이안에 들어가는 ip가 질의하는 것에만 대답해 준다. 해당 설정은 나 자신이 따로 설정한 도메인이 존재한다면 나 자신인 NS서버가 직접 질의에 대한 대답을 돌려주게 하는 설정이다. 192.168.252.0/24 처럼 프리픽스를 사용하여 네트워크 대역대를 설정해도 된다.

allow-query-cache { 127.0.0.1; 192.168.0.109; }; 재귀적 질의 과정을 통해 얻어낸 정보를 캐시에 저장하는데 이 캐시에 저장된 도메인네임의 내용을 돌려주고 싶다면 이곳에 설정한다.

 

이와같은 방법으로 패키지를 설치하지 않고 네임서버를 운영할 수 있다. 또한 정상 동작하는지 확인하기 위해 아래 명령어를 통해 ip를 찾는지 확인할 수 있다.

 

dns 조회 유틸리티

dig, host, nslookup 3가지가 존재한다.

 

nslookup 사용법

nslookup [-type=레코드] 도메인네임 [DNS IP]

DNS IP : 특정 DNS 서버로 질의하고 싶을때 사용한다. 지정하지 않을경우 resolv.conf에 지정되어있는 DNS에 질의하게된다.

-type=레코드 : 질의 도메인네임 유형을 지정한다. 생략할 경우 기본값 -type=a 이다.

 

DNS 레코드

a : IPv4 address

aaaa : IPv6 address

mx : Mail eXchanger, 메일 교환기(서버)

soa : Start Of Authority, 권한의 시작(Master NS)

ptr : Pointer, 역방향 조회

txt : text, 서버에 대한 설명, 사용을 안하면서 역할이 바뀐 상태 SPF(Sender Policy Framework)

 

nslookup을 통해 네이버의 마스터 네임서버의 SOA를 질의한 경우 정상적으로 응답이 돌아온다.

 

dig 사용법

dig [-x] [@DNS IP] 도메인네임 [레코드] [+옵션]

-x : 역방향 조회시 사용, 생략할경우 정방향 조회

@DNS Ip : 특정 DNS 서버로 질의하고 싶을때 사용 생략할 경우 시스템에 등록된 기본 DNS로 질의한다.

레코드 : 질의 도메인네임 유형을 지정한다. nslookup과 같다.

+옵션 : +short 응답중 answer 섹션의 내용만 출력

 

dig 명령어를 사용할 경우 nslookup보다 좀더 상세하게 내용을 출력해준다.

 

그럼 이번에는 직접 구축한 DNS서버의 종류를 설정 하기 위해 /etc/named.conf 에 ZONE에 관련된 내용을 추가해야한다. DNS 서버의 종류는 master, slave, hint 3가지가 존재한다.

master name server : 1차 네임서버를 정의할때 사용한다. 도메인 네임 서버 사용시에 꼭 구축해야 하며 Primary Name server라고도 한다.

slave name server : master의 내용의 백업을 담당하고 질의를 받을때 그대로 전달만 하는 네임 서버 이며 2차 네임 서버를 정의할때 사용한다. Secondary Name Server라고도 한다.

hint : 직접 구축한 도메인 이외의 별도의 도메인 체계에 대한 질의가 들어올 경우 처리 할 수 없는 대답을 위해 참조할 수 있는 서버

 

named.conf에 작성해야 하는 형식은 아래와 같다.

ZONE "도메인" IN {

type master/slave/hint

file "영역명.zone"

};

 

직접 구축하지 않은 도메인에 대한 질의가 들어올경우 최상위 루트 도메인에게 재귀적 질의를 실시하기 위해 루트 도메인을 hint 서버로 설정하였고 그에 대한 설정이 담겨 있는 zone 파일의 이름을 root.zone으로 설정했다. 존파일은 options에 directory 설정에 적용되어 있는 /var/named 디렉토리에서 찾게되므로 해당 위치에 생성해 주어야 한다.

 

그리고 /var/named 에 rpm -ql bind를 통해 확인할 수 있는 named.root라는 이름의 파일을 root.zone 이라는 이름으로 옮기고 해당 파일을 최신화 해주면 된다.

해당 파일을 확인하면 dig명령어를 통해 작성된 파일임을 알 수 있다. 따라서 최신화를 위해 직접 dig명령어를 사용해 갱신해주면 된다.

최상위 루트도메인의 네임서버에 대한 정보가 필요하므로 dig @168.126.63.1 . ns + tcp 라는 명령어와 리다이렉션을 통해 갱신을 수행한다. 이때 +tcp를 같이 사용한 이유는 DNS통신은 UDP로 수행되기 때문에 512바이트 크기보다 큰 메세지는 잘리게 된다. 따라서 모든 내용을 갱신하기 위해 통신 옵션에 tcp를 주어 수행하면 된다.

파일의 갱신이 완료되면 설정의 재적용을 위해 service named restart를 수행하면 된다.

 

이제 kmy.co.ki라는 나만의 도메인을 생성하기 위해 마스터 네임서버의 설정을 해당 서버에 수행하면 된다.

해당 서버가 kmy.co.ki 라는 도메인을 가지는 서버이므로 NS의 타입은 master로 설정하며 해당 도메인의 설정을 적용하기 위한 파일을 kmy.co.ki.zone 이라는 이름으로 적용하겠다는 설정이다. 따라서 질의가 들어오면 zone파일의 내용을 기초로 응답을 하게 된다.

여기서 지정한 kmy.com.zone은 기본값으로 설정되어 있는 /var/named 에 있어야 한다.

 

이런식으로 nslookup을 soa 레코드에 대해 질의 했을때 볼수 있는 origin, mail addr, serial 등을 kmy.co.ki.zone 파일에서 설정한다.

 

kmy.co.ki.zone 파일을 touch 명령어로 생성하고 내용을 작성하자

파일 안의 내용을 정리하면

 

$TTL : Time To Live 라는 이름의 값으로 해당 도메인에 대한 정보를 다른 네임서버에서 가져간 다음 가져간 네임서버에 얼마나 보관할 것인가를 지정한것이다. 여기서 1D로 설정했는데 이 정보를 가져간 네임서버에서는 가져간 후로 하루동안 다시 질의하지 않고 캐시에 저장된 그값으로 계속 서비스를 한다는 뜻이다.

$ORIGIN : origin 도메인을 저의하는 것으로 named.conf 파일에 설정 되어 있는 도메인명과 같은 도메인이다.

SOA, NS, A : nslookup, dig 명령어를 사용할때 쓰던 레코드와 같은 값으로 해당 질의에 대한 응답으로 돌아갈 설정을 적는 것이다.

 

kmy.co.ki. <- 어떤 도메인에 대한 설정을 할것인지 맨처음 작성한다.

IN SOA <- SOA에 대한 설정을 작성하겠다는 뜻이다.

ns1.kmy.co.ki. <- 설정을 적용할 네임서버가 누구인지 알려준다.

root.kmy.co.ki. <- webmaster가 누구인지 알려주는 부분으로  webmaster가 없다면 root가 수행한다. root@kmy.com 과 같은 뜻 (

2020051500 ; <- Serial number 년월일갱신번호 처음이니까 00

3H ; <-Refresh

10M ; <- Retry

1W ; <- Expire

1D ) ; <- Minimum TTL

Serial number 부터 Minimum TTL은 Primary네임서버와 Secondary 네임서버의 연동을 어떻게 설정 할 것인지에 대한 세부 설정 부분이다.

 

kmy.co.ki. IN NS ns1.kmy.com.

kmy.co.ki. IN NS ns2.kmy.com.

kmy.co.ki 도메인의 NS 레코드에 대한 질의가 들어올 경우 ns1.kmy.co.ki 와 ns2.kmy.co.ki 가 존재한다고 대답하도록 설정한다.

 

ns1.kmy.co.ki. IN A 192.168.0.109

ns2.kmy.co.ki. IN A 192.168.0.159 

각 네임서버에 대한 ip를 설정하여 A레코드를 통한 질의가 들어올 경우 설정한 ip로 대답을 한다.

 

www.kmy.co.ki IN A 111.111.111.111

ftp.kmy.co.ki IN A 222.222.222.222

abcd.kmy.co.ki IN A 123.123.123.123

자신의 네임 서버가 가지고있는 도메인들의 IP를 설정하는 부분이다. www, ftp, abcd 라는 서버를 가지고 서비스를 운영하여 클라이언트가 해당 도메인을 질의한다면 설정한 IP를 대답해준다.

해당 설정을 마친뒤 서비스 재시작을 수행한후 nslookup www.kmy.co 127.0.0.1 등을 수행하면 내가 어떤 도메인들을 가지고있다고 설정한 IP를 대답으로 돌려주는 것을 확인할 수 있다.