지난 포스팅에서, DNS 서비스 제공에 필요한 패키지(프로그램) 설치와, 패키지 설정 파일의 설정 방법에 대해 알아보았다. 필자와 같이 내부 네트워크에서 작동하는 DNS 서버를 만들기 위해서는, 네트워크 내의 영역에 대한 "IP: 사이트 주소"가 매칭된 정보를 DNS 서버에 저장해놓아야 한다. 이 정보를 저장하는 파일을 Zone 파일이라고 하며, 이 zone은 이전 포스팅의 named.conf 파일에서 보았던 그 zone과 동일한 것을 의미한다.
1. Zone 파일이란?
필자가 현재 구축하려는 네트워크의 대략적인 구성도는 다음과 같다고 가정하자.
현재 웹서버는 52번 IP를 가지는 리눅스에서 서비스를 제공하고 있으며, 메일 서버는 IP는 할당되어 있지만 서비스는 제공되지 않고 있다(PC 자체가 없다...). 그리고 사용자 PC 또는 스마트폰 IP는 임의로 할당된 번호를 사용하고 있다.
공유기 내부에서 사용자 1명이 family.lee 영역의 웹서버를 이용하려 한다면, 공유기 내부 DNS 서버로부터 www.family.lee의 사이트 주소에 대한 IP를 알아내어야 한다. 우리가 구축하는 DNS서버는 공유기 내부의 family.lee 내에 존재하는 서버에 대해서 질의를 가능하도록 named.conf 파일을 아래와 같이 설정했었다.
즉, 이 DNS 서버는 family.lee 영역 내의 서버 사이트 주소를 IP로 직접 변환할 수 있는 권한 또는 능력이 있다고 보면 된다. 하지만, 사이트 주소와 IP에 대한 정보가 DNS 서버 내에 존재하지 않는다면, 아무리 www.family.lee에 대한 한 주소를 질의한다 하더라도 DNS 서버에서는 이 질의에 대한 답을 돌려주지 못한다.
Zone 파일은 DNS가 내부 네트워크의 사이트 주소에 대해 질의받은 내용에 대해 답변을 하기 위한 답변서라고 보면 된다. 114에 지역 상점 전화번호를 문의할 때, 상담원들이 답변을 위해 참조하는 전화번호부와 동일하다고 보면 된다.
2. Zone 파일의 작성
named.conf 파일에 추가한 zone 영역의 내용을 보면, zone 파일의 이름 및 경로가 표시된다. 경로는 option 영역의 Directory에 "/var/named/"가 기본값으로 되어 있고, 파일명은 "family.lee.zone"으로 되어 있다. 즉, 우리가 만들어야 하는 존 파일은 "/var/named/family.lee.zone"에 위치해 있어야 한다.
cd 명령어로 /var/named/로 이동한 뒤, touch 또는 vi 명령어를 사용해 family.lee.zone 파일을 생성한다.
# cd /var/named
# touch {zone 파일명}
# vi {zone 파일명}
vi 로 해당 파일을 열면, 아무것도 없는 빈 파일인데, 여기에 아래와 같이 내용을 작성하면 된다.
zone 파일의 내용 포맷은 아래와 같다.
==========================================================
$ORIGIN {영역명}.
$TTL {TTL 시간}
# 리소스 레코드 영역
{영역명}. IN SOA {DNS 서버 주소}. {DNS 관리자 메일주소}. (
{Zone 파일 개정번호 입력}
{보조 DNS 서버 사용 시, Refresh 타임 입력}
{보조 DNS 서버 사용 시, Retry 타임 입력}
{보조 DNS 서버 사용 시, Zone 파일 파기 유예기간 설정}
{네거티브 캐시 유효기간 설정} )
{영역명}. IN NS {DNS 서버 도메인 주소}
{영역명}. IN MX {우선 순위 번호 입력} {메일 서버 도메인 주소 입력}
{서버1 Host} IN A {서버1 IP 주소 입력}
{서버2 Host} IN A {서버2 IP 주소 입력}
# 리소스 레코드 영역 끝
==========================================================
Zone 파일의 작성 영역은 크게 네 부분으로 나뉜다.
(1)
먼저 빨간색으로 표시된 부분을 보자. zone 파일의 가장 앞부분은 이 zone 파일이 어떤 영역의 도메인에 사용할 DNS 답변서인지를 명시하고, 질의에 대한 내용을 얼마나 오랫동안 보관하고 있을지를 작성하는 부분이다.
$ORIGIN이 Zone 파일이 사용될 도메인을 명시하는 부분인데, 우리는 내부 네트워크 영역을 family.lee로 지정했으므로, family.lee를 {영역명} 내에 입력해주면 된다. 주의할 점은, family.lee 뒤에 온점(.)이 찍혀야한다는 것이다. 이 온점은 최상위 루트 도메인을 의미하는데, 사실 우리가 사이트를 들어갈 때도 www.daum.net. 으로 최상위 도메인에 대한 정보를 명시하고 들어가야 하지만 편의상 이를 생략하고 사용해도 무방하게 만들어 놓은 것이다. 이 온점이 찍힌 주소에 대해 해석하자면, 루트 도메인(.) 아래, .lee 영역 아래, family에 대한 영역에 대해 DNS zone 파일을 만들겠다고 선언하는 것이다. 당연히 이 .lee 영역은 루트 도메인에 등록된 정식 도메인이 아니기 때문에, 공인 DNS 서버로 문의하더라도 제대로 된 답변은 돌아오지 않지만 말이다.
$TTL은 다른 DNS 서버와 연동 시, 사용하는 개념이다. 지금의 구축 내용과는 조금 거리가 먼 이야기인데, 만약 필자가 구축한 DNS 서버를 daum.net DNS 서버 밑에 등록하여 사용한다고 가정해보자. 필자가 www.daum.net 이나, mail.daum.net 등에 접속하려면, 필자의 DNS 서버가 daum.net DNS 서버에게 해당 주소에 대한 IP를 질의하고 답변을 받아와야 한다. 그런데, 필자가 이 사이트를 접속했다가 브라우저를 끄고, 다시 접속하는 추악한(?) 행태를 반복적으로 벌인다면, daum.net의 DNS 서버는 필자의 DNS 서버가 질의하는 내용을 답변하기 위해 계속 zone 파일을 뒤적거려야한다. 이는 필자의 질의에 응답하는 과정에 불필요하게 시간을 소모하고, 다른 사람들의 질의에 대한 응답을 지연되게 하는 원인이 된다. 따라서, daum.net의 DNS 서버는, 필자의 DNS 서버가 첫 질문을 던진 시점에, 자신의 zone 데이터를 일정 기간동안 보존할 수 있도록 함으로써, 반복되는 질문이 들어오는 것을 차단한다. 즉, TTL은 타 서버에서 내 DNS 내에 존재하는 Zone 파일을 얼마동안 보관할 수 있을지 설정하는 것이라고 보면 된다. 값은 초(second) 단위로 입력하거나, 1H(1시간), 1D(1일) 등 변형된 포맷을 사용하여 입력할 수 있다.
(2)
주황색으로 표시된 부분은 SOA(Start of Authority) 레코드라고도 부르는데, 생성한 Zone에 대해 기본적인 정보를 입력하는 부분이다. 첫 줄은 영역명, DNS 서버의 주소, 그리고 관리자 메일 주소를 작성하면 된다. 관리자 메일 주소 작성 시, 주의해야 할 점이 있는데, zone 영역에서 @는 $ORIGIN의 값과 동일한 의미를 가진다. 즉, root@ns1.family.lee.라고 작성하면, named 패키지는 이 내용을 root.family.lee.ns1.family.lee로 인식하게 된다.
다음 아랫줄은 zone 파일의 개정 번호를 작성하는 부분이다. 개정 번호는, 해당 zone 파일이 수정되었을 때마다 1씩 올려 수정하게 되는데, 이는 DNS 서버를 이중화 할 경우, 보조 DNS 서버에서 주 DNS 서버의 zone 파일 내용이 변화되었는지 확인이 필요하기 때문이다. 조금 더 자세한 내용은 추후 서버 보안 시 언급하려하며, 우선 이 부분은 zone 파일의 수정이 발생할 시, 번호를 하나씩 올려준다는 것만 인지하고 있으면 된다. 필자의 경우, 날짜 + 번호 형식으로 개정 번호를 입력한다. 해당 zone 파일을 2020년 7월에 처음으로(001) 만들었음을 의미한다. 만약 이 파일에 대해 수정 작업을 진행한다면, 맨 뒤의 세 자리를 002로 변경하고 저장하면 된다.
Refresh, Retry 및 expire 역시 DNS 서버 이중화 구축 시, 사용되는 내용이다. Refresh는 보조 DNS 서버가 주 DNS 서버의 Zone 정보 변경 체크 시간 간격을, Retry는 보조 DNS 서버가 네트워크 상의 문제나 주 DNS 서버의 이상으로 주 DNS 서버로 접근할 수 없을 때, 얼마의 시간 뒤에 다시 접속을 시도할지, 그리고 expire는 보조 DNS 서버가 주 DNS 서버로 접근이 불가할 때, 이전에 받아놓은 주 DNS 서버의 Zone 정보를 얼마 뒤에 파기할 지 설정하는 부분이다.
마지막 값은 Negative TTL을 설정하는 부분이다. DNS 서버로는 DNS 서버가 응답할 수 있는 질문 외에, 응답이 불가능한 질의도(wwv.daum.net 이라던가) 들어올 수 있다. 만약 특정 사용자가 악의를 가지고 이 잘못된 질문을 반복적으로 던진다면, 당연히 DNS 서버가 이 질의를 처리하느라 다른 질의에 응답을 못해주는 현상이 발생한다. 즉, Negative TTL은 존재하지 않는 도메인에 대해, 해당 호스트가 존재하지 않는다는 답변을 캐시 형태로 얼마나 저장할 지 설정하는 부분이라고 생각하면 된다.
현재 포스팅에서는 DNS 이중화 구축을 진행하지 않기 때문에, 추후 기회가 된다면 SOA 레코드 부분에 대해 제대로 언급할 예정이다. 우선은 기본값으로 위의 사진에 나온 값을 입력하면 된다.
(3)
세 번째 부분은 DNS 서버 및 메일 서버에 대한 내용을 작성하는 부분이다. 특이하게도 zone 파일 작성 시, DNS 서버와 메일 서버는 지금과 같이 별도의 정보를 따로 작성해주어야 한다. 해당 부분은 DNS 서버와 메일 서버의 사이트 주소에 대해 명시하는 부분으로 보면 되는데, 이 때 사용하는 리소스 레코드는 NS(Name Server)와 MX(Mail Exchanger)이다.
---------------------------------------------------------------------------
family.lee. IN NS {DNS 서버 사이트 주소}
family.lee. IN MX {우선순위} {메일 서버 사이트 주소}
----------------------------------------------------------------------------
메일 서버에 대한 레코드 입력 시, 우선 순위가 반드시 들어가야 하는데, 이 우선 순위는 정수값을 입력하면 된다. 만약 메일 서버가 여러 개 존재하는 경우, 어떤 서버의 IP를 최우선으로 알려줄 것인지 우선 순위를 정한다고 보면 된다. 만약 1순위 서버가 부하가 있거나 작동 이상으로 접근이 불가능하다면, DNS 서버는 다음 순위의 메일 서버 IP 주소를 사용자에게 전달하게 된다. 마찬가지로, 현재의 포스팅에서는 메일 서버 구축을 진행하지 않기 때문에, 기본값인 10만 입력하고 넘어간다(참고로 MX 레코드는 우선 순위가 빠지면 Zone 파일 무결성 검사 시, 오류가 발생한다).
(4)
마지막 부분은, 각 서버에 대한 실제 IP 주소를 입력하는 부분이다. 리소스 레코드가 A로 되어 있는데, 이 의미는 사이트 주소를 뒤에 명시할 IPv4 주소로 매칭시키라는 의미다. 즉,
-------------------------------------------------------------------------------
www.family.lee. IN A 172.30.1.52
-------------------------------------------------------------------------------
는 www.family.lee 주소에 대한 IP 질의 시, 172.30.1.52를 응답값으로 돌리라는 이야기다.
참고로, AAAA 레코드는 IPv6에 대한 내용을 입력하라는 의미인데, 이전 포스팅에서도 언급했듯이 IPv6를 사용하는 곳이 많지 않아 잘 사용하지 않는다.
3. Zone 파일 내용 이상 검사 및 bind 서비스 시작
Zone 파일 작성이 완료되었다면, 파일을 저장하고 vi 편집기를 종료하자. named 패키지는 설정 파일과 zone 파일의 작성 오류 여부를 확인할 수 있는 명령어를 제공하며, 해당 명령어를 사용함으로써, 설정 파일과 Zone 파일의 어느 부분에 작성 에러가 존재하는지 확인할 수 있다.
# named-checkconf {named 설정파일 경로} : named 설정 파일 이상 유무 확인 명령어
# named-checkzone {Zone 영역} {Zone 파일} : 생성한 Zone 파일의 이상 유무 확인 명령어
작성한 Zone 파일에 이상이 없다면, 위와 같이 Zone 파일의 개정 번호와 함께 OK라는 문구가 출력된다. 하지만 내용 상에 문제가 있다면 아래와 같이 에러에 대한 상세 출력 내용이 나타나게 된다.
Zone 파일에 이상이 없음이 확인되었다면, systemctl 명령어를 이용하여 DNS 서버의 서비스를 시작하면 된다.
# systemctl (re)start named
특이하게도, DNS 서버 구동에 필요한 패키지 이름은 bind임에도, 실제 서비스 구동이나 설정 파일 등의 이름에는 bind가 아닌 named가 사용된다. bind 패키지를 보다보면 조금 헷갈릴 수 있는 부분이니 유의하자.
4. 네트워크 / 방화벽 설정 및 서비스 기동
(1) 네트워크 DNS 서버 IP 주소 지정
사용자 PC 에서 우리가 만든 DNS로 직접 질의를 하도록 만들려면, 개인 PC의 네트워크 DNS 서버 IP 주소를 변경해야 한다. 윈도우와 리눅스의 DNS 서버 IP 설정 방법이 조금씩 다르다.
<윈도우>
- 시작 -> "네트워크 연결 보기" 검색
- 현재 사용중인 네트워크(Wifi / LAN)의 속성 -> 인터넷 프로토콜 버전 4(TCP/IPv4) 클릭 및 속성 -> "다음 DNS 서버 주소 사용" 선택 후, 기본 설정 DNS 서버 IP를 구축한 DNS 서버 IP로 지정.
< 리눅스 >
# vi /etc/resolv.conf 명령어 수행 후, nameserver의 주소 변경.
** 참고로 resolv.conf 파일에서 수정 시, network 서버스를 systemctl 명령어로 재시작할 경우 파일이 원상복구된다. 영구적으로 DNS 서버를 지정하려 한다면 /etc/sysconfig/network-script/ifcfg-{인터페이스명} 파일에서 DNS 서버 IP를 수정하고 저장하면 된다.
(2) DNS 서버 리눅스 방화벽 개방
DNS 서버는 TCP/UDP 53번을 이용한다. 일반적인 질의의 경우 UDP 53번을, DNS 서버가 이중화로 구성되어 보조 DNS 서버에서 주 DNS 서버의 Zone 파일 등을 받을 경우는 TCP 53번을 이용한다.
따라서, DNS 서버의 정상적인 작동을 위해, 리눅스의 53번 포트 개방과, 외부에서 들어오는 패킷 출발지 포트에 대해, 통신이 가능하도록 리눅스 방화벽을 설정해야 한다. 리눅스는 기본적으로 53번으로 들어오는 패킷에 대해서는 허용해놓았으나, 이후 연관되어 있는 ICMP 통신에 대한 허용은 되어 있지 않다. 그렇기 때문에 DNS 서버 자신이 자신에게 질의하는 내용에 대한 답변은 잘 돌아오나, 윈도우 PC에서 던지는 질의에 대한 응답은 방화벽에 막혀 window로 전송되지 않는다.
따라서, 윈도우에서도 DNS 로 질의가 가능하도록 하기 위해서는, 방화벽 INPUT의 마지막 정책을 삭제하던가, 아니면, INPUT 정책 중 DNS 와 관련된 정책을 조금 수정해주면 된다. 리눅스 방화벽이 기본 설정 내용을 유지하고 있다면, 아래의 두 명령어 중 하나를 사용하자. 참고로, 리눅스 방화벽에 대한 내용은 머지않은 미래에 포스팅 할 예정이다.
# 첫 번째 방법
# iptables -D INPUT 10
# 두 번째 방법
# iptables -R INPUT 1 -p udp --dport 53 -m state --state NEW -j ACCEPT
# iptables -R INPUT 2 -p tcp --dport 53 -m state --state NEW -j ACCEPT
이제 윈도우에서 www.family.lee에 에 대한 IP 정보를 잘 가져오는지, 그리고 웹 접속이 잘 되는지 확인해보도록 하자.
5. DNS 구축 결과 확인
리눅스 및 윈도우에서 특정 사이트 주소에 대한 IP 주소를 DNS 서버에게 확인하는 명령어는 다음과 같다.
# nslookup {사이트 주소} : 윈도우 / 리눅스 공통
# dig {사이트 주소} : 리눅스 한정
참고로 dig 명령어는 질의를 진행할 DNS 서버를 지정할 수 있는데, dig @{특정 DNS 서버 IP} {사이트 주소} 형태로 명령어를 입력하면 된다.
윈도우에서 nslookup 명령어로 결과를 잘 받아왔다면, 웹 브라우저에서도 IP가 아닌 사이트 주소만으로 내부에 구축한 웹 페이지 접속이 가능해진다.
스마트폰에도 필자가 구축한 DNS 서버 IP를 기본 IP로 지정하면, PC와 동일하게 사이트 주소만으로도 웹 페이지 접속이 가능해진다.
지난 3개의 포스팅을 통해, DNS 서버가 무엇인지, 리눅스에서 DNS 서버에 필요한 패키지와 파일에 무엇이 있고 어떻게 설정하는지, 그리고 DNS 서버 구축을 어떻게 진행하는지에 대해 알아보았다. 필자도 사실 1년 전에 실습하면서 마지막으로 DNS를 구축해서 그런지, 다시 기억을 되돌리기까지 상당히 많은 시간을 소비했다. 그만큼, DNS 서버 구축이 쉽지만은 않은 내용이다.
원래 다음 포스팅의 내용으로는 메일 서버 구축에 대한 내용을 진행하려 했는데, 서버 구축 내용을 계속 작성하다보니, 방화벽과 패키지에 대한 내용을 먼저 작성하고 넘어가야 할 듯 하다. 다음 포스팅은 방화벽에 대해 먼저 포스팅하는 것으로!
FIN.
'IT Security > LINUX Basic' 카테고리의 다른 글
| 27. Linux - 리눅스 방화벽2, 방화벽 정책(chain) 관련 명령어 (0) | 2020.08.11 |
|---|---|
| 26. Linux - 리눅스 방화벽1, 방화벽 서비스 및 정책 확인 (0) | 2020.08.09 |
| 24. Linux - DNS 서버 구축 2, 패키지 및 DNS 설정 파일 (0) | 2020.07.27 |
| 23. Linux - DNS 서버 구축1, 개요 (0) | 2020.06.13 |
| 22. Linux - 리눅스에 나만의 홈페이지를 만들어보자 2 (0) | 2020.06.07 |
댓글