DNS Master Slave 구성
Root DNS와 TLD DNS는 각 상위기관이 네임서버를 관리합니다.
사용자가 사용하고 싶은 Domain Name이 있으면 그 이름을 등록대행사를 통해 등록하고,
권한 네임서버(Authoritative)에 자신의 Domain Name에 대한 DNS 서비스를 세팅한 후
권한 네임서버 정보를 상위기관에 제공함으로써 질의 과정이 이루어지게 됩니다.
요약하면, 권한 네임서버만 잘 관리한다면 DNS 질의는 정상적으로 이루어집니다.
권한 네임서버에서는 자신의 Domain Name에 대해 질의가 오면 그에 대한 응답을 해야 합니다. 응답을 해야 하는 정보는 일반적으로 네임서버에서 "Zone File"을 통해 관리를 하게 됩니다.
만일 관리자가 관리해야하는 권한 네임서버가 한대라면, Zone File 관리는 어렵지 않습니다.
해당 Zone File을 업데이트하면 자동으로 자신이 관리하는 Domain Name에 대한 정보가 업데이트 되는 셈이니까요.
하지만 권한 네임서버가 여러 대라면 이야기는 달라집니다.
여러 대의 네임서버에서 각각 Zone File을 관리한다고 가정하면,
만일 자신의 Domain Name에 대한 정보를 업데이트 해야하는 경우 모든 서버에 일일히 Zone File을 업데이트 해야 합니다.
이는 관리상의 불편이 발생하기도 하면서 동시에 모든 네임서버에서 동일한 정보를 제공한다는 보장을 할 수 없는 문제가 생깁니다.
관리자의 실수로 동일하지 않은 정보를 네임서버에 입력할 수도 있고,
실수를 하지 않더라도 모든 네임서버에 들어가 일일히 정보를 업데이트 하는 시간 동안에는 각 네임서버에서 답변하는 내용이 달라지기 때문입니다.
DNS Master-Slave는 이 문제점을 해결하고자 나온 구성입니다.
Master DNS 서버(이하 Master)는 Zone File을 관리합니다.
Slave DNS 서버(이하 Slave)는 Master로부터 최신 Zone File을 받아옵니다.
Master와 Slave는 모두 사용자의 질의을 받아 Zone File을 기반으로 하여 응답을 하게 됩니다. DNS 질의자 입장에서는 차이가 없습니다.
관리자는 만일 자신의 Domain Name에 대한 정보를 업데이트 해야 한다면,
Master에서만 Zone File을 업데이트 하면 됩니다.
Slave는 알아서 Master로부터 업데이트 된 Zone File을 받아옵니다.
이 과정을 통해 관리상의 부담을 덜 수 있습니다.
1. 일반적인 Master-Slave 구성
관리자는 Master, 위 사진에서는 #1번 서버에서 Zone File을 관리하면 됩니다.
관리자가 #1번 서버에서 Zone File을 업데이트 하면,
Slave인 #2번 서버와 #3번 서버는 AXFR/IXFR이라는 방식을 통해 새로운 Zone File을 Master인 #1로부터 받아갑니다.
AXFR과 IXFR 모두 TCP 53번 포트를 통해 이루어집니다.
AXFR은 모든 Zone File을 가져가는 방식입니다.
IXFR은 업데이트 된 부분만 가져가는 방식입니다. (증분에 대한 복사)
참고) 일반 DNS 질의는 UDP 53번 포트로 이루어집니다.
Slave 입장에서는 Master의 Zone File이 업데이트 되었다는 사실을
다음 방식에 의해 알게 됩니다.
(1) SOA 레코드에 기반
Zone File에는 SOA 레코드가 존재합니다. SOA 레코드를 통해 자신이 해당 Zone에 권한이 있다는 것을 알리기 때문입니다.
SOA 레코드 중에는 다음 값들이 존재합니다.
Serial : Zone File의 버전 (예시 : 2020032601)
Refresh : Zone File이 업데이트 되었는지 확인하는 주기 (예시 : 3600, 초)
Retry : Refresh 실패시 재시도하는 주기 (예시 : 1800, 초)
Expire : Retry 요청을 하게 될 경우 언제까지 할지 (예시 : 604800, 초)
Master에서는 Zone File 업데이트시 serial 값을 기존 값보다 큰 값으로 업데이트 해야합니다.
Slave에서는, Refresh 값에 정의되어 있는 시간만큼 주기적으로 Master에게 SOA 레코드를 조회합니다.
조회 결과 자신이 가지고 있는 Zone의 serial 값보다 Master의 serial 값이 더 크다면,
Zone File이 업데이트 되었다고 간주하고 AXFR/IXFR 요청을 해서 Master로부터 새 Zone File을 받아오게 됩니다.
그리고 만일 Master로부터 응답이 없다면, Retry의 시간만큼 주기적으로 Master에게 재요청을 하게 됩니다.
응답이 없는 시간이 Expire 시간을 초과하게 되면, Master에게 더 이상 요청을 하지 않게 되고 동시에 사용자들에게 해당 Zone에 대한 응답을 하지 않게 됩니다.
(2) NOTIFY 메시지
SOA 레코드에 기반하는 방식은 바로바로 업데이트가 안된다는 문제점이 있습니다.
Slave에서 한시간에 한번씩 Master에게 업데이트 확인를 한다고 치면, Master에서 업데이트 된 Zone File이 Slave에게 반영되려면 최대 한 시간이라는 시간이 필요하게 됩니다.
즉, Refresh 시간만큼 지연이 발생하게 됩니다.
이 문제를 해결하고자 NOTIFY 메시지를 사용하게 됩니다.
Master에서 Zone File을 업데이트 하면, 모든 Slave에게 NOTIFY 메시지를 발송하게 됩니다.
Slave에서는 Master에게 NOTIFY 메시지를 받으면, Zone File이 업데이트 되었다는 사실을 알게되고 Master에게 AXFR/IXFR 요청, 새 Zone File을 받아오게 됩니다.
NOTIFY 메시지를 사용하게 되면 Master-Slave 구성으로 인한 Zone File 동기화 문제를 쉽게 해결할 수 있습니다.
2. Hidden Master 구성
상황에 따라서 Master가 직접 클라이언트에게 서비스를 제공하기가 꺼려지는 경우가 발생할 수 있습니다.
이 경우 Master가 DNS 클라이언트들에게는 보여지지 않는,
Hidden Master 구성을 할 수도 있습니다.
Master는 Zone 관리만 잘 하면 되고,
실제 클라이언트들에게 응답은 Slave가 전담하게 되는 구성입니다.
작동원리는 똑같습니다.
Hidden Master는 Slave 들에게 NOTIFY 메시지를 보내고 AXFR/IXFR을 통해 최신 Zone File을 제공합니다.
Slave들은 Serial 값을 기반으로 Hidden Master로부터 Zone File을 갱신하면 됩니다.
Hidden Master는 외부에 노출되지 않게 됩니다.
WHOIS 조회, SOA 레코드 등에선 Primary Name Server가 #1번 서버인 것처럼 보여지지만 (Master가 #1번인 것처럼 보여지지만), 실제로는 #1번 서버는 Slave 였던 것이죠.
3. 기타
Master-Slave 구성시에는 SOA의 Primary Name Server 필드에 실제 Master 네임서버의 호트스명을 기재하면 됩니다.그런데 만일 Hidden Master 구성시에는, SOA의 Primary Name Server 필드에 Slave 네임서버를 기재해야 실제 Hidden Master의 호스트명이 겉으로 드러나지 않게 됩니다.
참고) BIND 9를 이용하여 네임서버 운영하기
https://dev.dwer.kr/2020/04/bind-9.html
댓글
댓글 쓰기