[Linux] DNS part 2

1. 네임 서버 이중화/다중화와 영역 전송(Zone Transfer)

<구글의 네임 서버>

 

 cmd(명령 프롬프트) 창을 열어 다음과 같이 구글 도메인(google.com)의 권한 있는 네임서버(Authoritative NS)를 검색해 보면 이러한 결과가 나온다. 왜 네임 서버를 여러 개 두는 걸까? 반대로 만약 네임 서버가 한 대만 있다고 가정해 보자. 그런 상황에서 해당 서버에 오류가 발생하여 다운된다면 무슨 일이 일어날까? 도메인 네임을 이용하여 구글 사이트에 접속하는 것이 불가능할 것이다. URL에 구글 웹 서비스 서버의 IP 주소를 입력하여 직접 들어가는 것은 가능하겠지만, 이러한 방법을 모르는 대부분의 사용자들에게는 인터넷 서비스가 마비된 것처럼 보일 것이다. 이러한 상황을 방지하여 고가용성(High Availability)**을 유지할 수 있게 하는 방법이 네임 서버를 이중화/다중화하는 것이다(이중화/다중화한 후 로드밸런싱(부하 분산)을 통해 고가용성을 유지할 수 있다). 

**[Network] 고가용성, 이중화, 로드 밸런싱 (tistory.com)을 참고하자

 

 각 네임 서버는 서버의 기능, 목적에 따라 이중화/다중화의 방법이 상이하다. 다음 설명들을 보면서 차이점과 이유에 대해 알아보자.

 

 

1) 권위 있는 네임 서버 이중화(master/slave 구조, 영역 전송)

  권위 있는 네임 서버 이중화/다중화는 master/slave 방식으로 구성한다.  master/slave 구조는 한 네임 서버를 master 네임 서버(=주, primary, 1차 네임서버) 로, 다른 네임 서버들은 slave 네임 서버(=보조, Secondary, 2차 네임 서버)로 구성하는 것을 의미한다. master 네임 서버는 원본 DNS 존 파일을 관리하는데, 이는 DNS 존 파일의 DNS 레코드의 변경 및 관리를 수행하는 것을 의미한다. slave 네임 서버는 주기적으로 master 네임 서버의 DNS 존 파일의 정보를 받아와 백업 서버의 역할을 하거나, 로드 밸런싱에 사용되는데, 여기서 master 네임 서버의 존 파일을 복제하는 과정을 영역 전송(zone transfer)이라고 한다. 영역 전송은 중요한 개념이기 때문에 조금 더 알아보자. 

 

*영역 전송(zone transfer)

 영역 전송(zone transfer)는 master 네임 서버의 존 파일을 slave 네임 서버에서 복제해 오는 과정을 의미한다. UDP 방식으로 통신이 이뤄지는 DNS Query와 달리 영역 전송은 TCP를 통해 신뢰할 수 있는 방식으로 통신된다(TCP 53번). 영역 전송에서 신뢰성은 매우 중요하다. master 네임 서버로부터 받아오는 존 파일의 내용이 손상됐을 경우 slave 네임 서버가 정상적으로 백업 서버의 역할을 할 수 없기 때문이다(잘못된 정보를 반환하게 될 수도 있다). 

 

 영역 전송에는 AXFR(Full Zone Transfer, 전체 존 전송)과 IXFR(Incremental Zone Transfer, 증분 존 전송) 두 가지가 있다. 자세한 내용은 다음과 같다. 

 

AXFR

• Full Zone Transfer, 전체 존 전송
• 존 파일 내용 전부를 송/수신 하는 방식
• 일반적으로 슬레이브 서버가 처음 설정되었을 때 사용
• 단점) 대규모 존 파일을 전송하는데 시간이 소요되며, 네트워크 트래픽이 증가할 수 있음

IXFR

• Incremental Zone Transfer, 증분 존 전송
• 존 파일 내용 중 변경된 부분만 전송하는 방식
• refresh 주기가 되거나, systemctl restart bind, rndc reload를 통해 존 파일을 받아오는 경우(필요시 AXFR 방식으로 받아오기도 한다)
• 장점) 변경된 레코드만 전송하기 때문에, 시간이 적게 걸리고, 네트워크 트래픽이 최소화됨

 

영역 전송의 통신 과정

1. 다음의 상황이 생기면 영역 전송 과정이 진행된다

• 1) master 네임 서버의 존 파일에 변경 사항이 생기면(시리얼 넘버가 바뀌면) slave 네임 서버에 Notify 메세지를 보낸다
  • Notify 메세지는 master 네임 서버에 변경사항이 있다는 역할이며, 이런 과정을 Zone Change Notification이라고 한다(UDP 53번)
• 2) 존 파일 갱신 주기가 되면 자동으로 갱신 요청을 하게 된다
• 3) systemctl restart bind, rndc reload 명령어를 통해 존 파일 갱신 요청을 할 수 있다
  • rndc reload: DNS 레코드 또는 구성 파일을 다시 로드하는 명령어

2. 위의 상황이 선행되면 slave 네임 서버는 master 서버에 SOA 레코드를 요청하여 master 네임 서버 존 파일의 시리얼 넘버와 자신의 시리얼 넘버를 비교해서 다를 경우, IXFR 또는 AXFR 방식으로 영역 전송을 요청한다

 

3. master 네임 서버에서 요청한 방식으로 존 파일을 전송해 준다

 

**가장 중요한 점은 존 파일에 변경 사항이 생겼을 때, 꼭 시리얼 넘버를 변경해줘야 한다는 것이다(일반적으로는 증가시킨다). Slave 네임 서버가 변경사항이 있는지 여부를 "Serial Number"의 변경여부로 판단하기 때문에, 시리얼 넘버에 변화가 없을 경우 명령어를 사용해 강제로 SOA 레코드를 요청해도 시리얼 넘버가 같기 때문에 변경 사항이 없는 것으로 인지하고 영역 전송을 요청하지 않는다!

 

**왜 Zone Change Notification이 있는데 refresh 주기가 존재하는걸까?

 Zone Change Notification은 UDP 방식이기 때문에 신뢰성이 없다. 따라서 온전히 수행되지 않는 경우가 생길 수 있으며, 이외에도 다른 이유로  Zone Change Notification이 수행되지 않는 경우가 있을 수 있기 때문에 refresh 주기를 설정하는 것이다. 

 

Wireshark를 이용해 AXFR과 IXFR 방식으로 영역 전송이 된 것을 확인해 보자(아래의 패킷 캡처 참고).

<AXFR 영역 전송>

<IXFR 영역 전송>

 

 

master/slave 구조로 권한 있는 네임 서버를 설정하는 방법

Master 네임 서버 설정

• daum.net Master의 존파일에 Slave 서버 등록( /var/named/daum.net.zone)
  

$TTL 1D 

@       IN      SOA     ns1.daum.net.         admin.daum.net.  ( 

                        2021121602 
                        1D 
                        1H 
                        1W 
                        3H 

) 

@               IN      NS      ns1.daum.net. 
@               IN      NS      ns2.daum.net.  //slave 서버 등록
ns1             IN      A       113.61.107.5 
ns2             IN      A       113.61.107.15  //slave 서버 등록

 

Slave 네임 서버 설정

• Slave 서버 데몬 설정파일에 slave 네임서버 설정( /etc/named.rfc1912.zones)

zone "daum.net" IN { 

        type slave; 

        file "slaves/net.zone.slave"; // master에서 다운받은 존파일의 내용을 저장할 파일이름 

        masters {113.61.107.5;};  // Slave 입장에서 master의 주소를 적어준다. 

};

 

해당 과정까지 설정을 완료한 후, systemctl restart named (rndc reload)를 통해 적용해 주면 Slave 네임 서버에 따로 존 파일을 만들지 않아도 다음과 같이 존 파일이 만들어진다. 

<Slave 네임 서버의 존 파일이 만들어졌다>

 

마지막으로 TLD 네임 서버(net.) 다음과 같이 Slave 네임 서버를 등록해 주면, Slave 네임 서버를 활용 가능하다

( /var/named/net.zone).

$TTL 1D     

@ IN SOA ns1.net. admin.net. (    

	2023020701 
	1D 
	1H 
	1W 
	3H 

) 

@            IN NS ns1.net.           
ns1 IN A 192.5.6.30   
daum              IN      NS      ns1.daum.net. 
daum              IN      NS      ns2.daum.net.  // Slave 네임 서버를 등록
ns1.daum         IN      A         113.61.107.5 
ns2.daum         IN      A         113.61.107.15  // Slave 네임 서버를 등록

 

 

2) Cache 네임 서버 이중화 

 Cache 네임 서버도 권한 있는 네임 서버와 동일하게 master/slave 구조로 구성해줘야 할까? 운 좋게도 그렇지 않다. 그 이유는 Cache 네임 서버가 권한 있는 네임 서버와 달리 데이터 일관성을 유지할 필요가 없기 때문이다. 앞서 언급했던 것처럼 권한 있는 네임 서버는 특정 도메인에 대한 원본 데이터를 저장하고 관리하고, Cache 네임 서버로부터 질의가 들어올 경우 해당 데이터(레코드)를 제공해야 한다. 이것은 동일한 도메인에 대한 권한 있는 네임 서버들에게도 해당된다(네임 서버마다 상이한 데이터를 제공할 경우 Cache 네임 서버에서 클라이언트에게 정확한 응답을 할 수 없다). 따라서 이러한 목적을 위해 권한 있는 네임 서버들을 master/slave 구조로 구성하는 것이다. 반면 Cache 네임 서버는 특정 도메인의 원본 데이터가 아닌 DNS Query를 통해 얻은 데이터를 캐싱하는 것이기 때문에 '데이터 일관성을 유지할 필요'가 없다(보조 Cache 네임 서버에 해당 데이터가 없을 경우 그냥 다시 DNS Query 과정을 통해 받아오면 된다). 그러므로 Cache 네임 서버를 여러 대 배치할 때, master/slave 구조를 사용하지 않는 것이다. 

 

 Cache 네임 서버를 이중화 하는 방법은 간단하다. 앞서 DNS Part 1 포스팅에서 언급한 Cache 네임 서버 설정 방법을 동일하게 수행한 후, 네트워크 설정에서 보조 DNS 서버로 등록해주기만 하면 된다. 

<Windows에서 보조 DNS 설정하는 방법>

 

 

2. IP 주소는 아는데 도메인 네임을 몰라? 역방향 질의(Reverse DNS Lookup)

 우리가 일반적으로 하는 DNS Query(정방향 쿼리)는 FQDN(Full Qualified Domain Name, 완전한 도메인 네임)을 아는 상황에서 FQDN에 해당하는 IP 주소를 알기 위해 사용한다. 역방향 질의(Reverse DNS Lookup)는 반대로 IP 주소를 아는 상황에서 IP 주소에 해당하는 FQDN을 찾기 위해 사용한다. 역방향 질의는 왜 하는 것일까? 다양한 사례가 있지만 일반적으로 2가지 경우에 많이 사용한다.

 

첫 번째는 웹 서버 관리자가 보안의 목적으로 접속 로그를 분석할 때 사용된다. 네트워크 로그에는 일반적으로 IP 주소만 기록돼 있는데, 역방향 질의를 통해 해당 IP 주소의 도메인 네임을 알 수 있다면 트래픽 분석 및 의심스러운 활동을 추적하는데 도움이 된다. 두 번째는 메일 서버에서 스팸 방지 목적으로 역방향 질의를 하는 경우이다. 많은 메일 서버들이 메일을 보낸 서버의 IP 주소에 대해 역방향 질의를 하여, 역방향 조회가 실패하거나, PTR 레코드가 설정돼있지 않거나, 메일 내용에 적혀 있는 발신지 서버의 도메인 네임과 조회 결과가 다르다면 스팸으로 처리한다. 

 

 역방향 질의를 위해서는 PTR(Pointer) 레코드가 사용된다. PTR 레코드는 특정 IP 주소에 대해 해당 IP가 어떤 도메인 이름에 연결되는지를 나타낸다. 

*레코드(record): 도메인 네임과 관련된 정보를 저장하는 데이터 항목

<PTR 레코드를 사용한 역방향 질의>

 

역방향 질의를 이해하기 위해서는 리버스 도메인(reverse domain)에 대해 알아야 한다. 리버스 도메인(reverse domain)이란 역방향 질의를 위해 네임 서버에 설정하는 특수 도메인이다. 네임 서버에 리버스 도메인을 설정하면 IP 주소에 대응하는 도메인 네임을 조회할 수 있다. IP 주소를 리버스 도메인으로 변환하려면 IP 주소를 역으로 나열하고 뒤에 in-addr.arpa를 붙이면 된다. 여기서 arpa(Address and Routing Parameter Area)는 DNS에서 사용되는 특수한 최상위 도메인이다. 리버스 도메인을 구조화시키면 다음과 같다. 

 

예시) 113.61.107.80의 리버스 도메인은 80.107.61.113.in-addr.arpa이다 

<KISA 자료>

 

역방향 질의를 위한 리버스 도메인 설정 방법 

 

가정) daum.net. 도메인의 권한 있는 네임 서버에 리버스 도메인을 설정(113.61.107.5)

 

1. 권한 있는 서버의 데몬 설정 파일(/etc/named.rfc1912.zones)에 리버스 도메인 설정

zone "107.61.113.in-addr.arpa" {
	type master;
    file "113.61.107.rev";  // 해당 존 파일에 리버스 도메인 관련 레코드를 기록하겠다
};

 

2. 존 파일(/var/named/113.61.107.rev)에 역방향 질의를 하고자 하는 ip 주소의 PTR 레코드를 기록

$TTL 1D
@	IN	SOA	ns.daum.net. admin.daum.net. (
	2024092501
    1D
    1W
    3H
)
@	IN	NS	ns1.daum.net.
@	IN	NS	ns2.daum.net.
5	IN	PTR	ns1.daum.net.
15	IN	PTR	ns2,daum.net.
20	IN	PTR	file.daum.net.
80	IN	PTR	web.daum.net.

 

< /var/named/113.61.107.rev>

3. 데몬 재시작(systemctl restart bind / rndc reload) 후 검증해 보면 다음과 같이 나온다

<리버스 도메인을 이용해 검색이 가능하다>

<wireshark를 이용해 패킷도 확인해보자>

 

 

 

힘들지만 오늘도 해낸 나를 위한 한 마디,

"마음을 위대한 일로 이끄는 것은 오로지 열정, 위대한 열정뿐이다", Denis Diderot

 

"열정은 자주 사그라들곤 한다. 하지만 열정이 사그라들려고 할 때, 매번 그 이상의 동기부여를 해주는 것, 그뿐이다"