DNS Master/Slave 서버 구성 개념

DNS Master/Slave 서버 구성 개념: Primary/Secondary와 Zone Transfer

DNS Master/Slave는 전통적인 표현이고, 현재 문서에서는 보통 Primary/Secondary라는 표현을 함께 쓴다. 의미는 같다. Primary 서버가 zone record을 관리하고, Secondary 서버는 zone transfer를 통해 복제본을 받아 권한 응답을 제공한다.

개념글이므로 전체 구축 스크립트보다, Primary/Secondary가 왜 필요한지와 zone transfer가 어떤 조건에서 동작하는지를 중심으로 정리한다.

구성 목적

• Primary DNS 장애 시에도 Secondary가 권한 응답을 계속 제공한다.
• DNS 질의 부하를 여러 서버로 나눈다.
• zone 파일 수정 권한을 Primary에 집중하고 Secondary는 복제만 받게 한다.
• 지리적으로 떨어진 위치에 DNS 서버를 배치할 수 있다.

예시 토폴로지

Primary zone 설정 예시

Primary 서버의 /etc/named.conf에는 zone 기존 파일과 transfer 허용 대상을 지정한다.

acl secondary_dns {
 192.168.10.194;
};

zone "lab.local" IN {
 type master;
 file "lab.local.zone";
 allow-transfer { secondary_dns; };
 also-notify { 192.168.10.194; };
};

zone 파일에는 NS record가 두 개 들어가야 한다.

$TTL 300
@ IN SOA ns1.lab.local. admin.lab.local. (2026062301
 3600
 900
 604800
 300)
 IN NS ns1.lab.local.
 IN NS ns2.lab.local.

ns1 IN A 192.168.10.192
ns2 IN A 192.168.10.194
web01 IN A 192.168.10.193

Secondary zone 설정 예시

Secondary 서버는 zone 파일을 직접 편집하지 않는다. Primary에서 받아온 파일을 저장한다.

zone "lab.local" IN {
 type slave;
 masters { 192.168.10.192; };
 file "slaves/lab.local.zone";
};

배포판에 따라 zone 저장 경로가 다르다. RHEL 계열 BIND에서는 보통 /var/named/slaves 또는 /var/named/dynamic처럼 named가 쓸 수 있는 경로를 사용한다.

문법 검사와 적용

sudo named-checkconf /etc/named.conf
sudo named-checkzone lab.local /var/named/lab.local.zone

sudo systemctl reload named
sudo journalctl -u named -n 80 --no-pager

zone transfer 확인

Secondary에서 Primary로 AXFR이 가능한지 확인한다. 허용된 Secondary에서만 성공해야 한다.

dig @192.168.10.192 lab.local AXFR
dig @192.168.10.194 web01.lab.local A +short
dig @192.168.10.194 lab.local SOA +short

SOA serial이 중요한 이유

Secondary는 Primary의 SOA serial을 보고 zone이 바뀌었는지 판단한다. Primary zone을 수정하고 serial을 올리지 않으면 Secondary가 변경을 받아가지 않을 수 있다.

2026062301 첫 수정
2026062302 두 번째 수정
2026062303 세 번째 수정

TSIG로 transfer 보호

IP 기반 허용만으로도 lab에서는 충분할 수 있지만, 운영 구조에서는 TSIG key를 사용해 zone transfer를 인증하는 편이 낫다. key 자체는 비밀값이므로 문서나 화면에 그대로 남기지 않는다.

tsig-keygen -a hmac-sha256 lab-transfer-key

설정 예시는 다음처럼 구조만 이해한다. 실제 secret은 명령 출력에서 생성된 값을 안전하게 배포해야 한다.

key "lab-transfer-key" {
 algorithm hmac-sha256;
 secret "";
};

server 192.168.10.194 {
 keys { "lab-transfer-key"; };
};

방화벽

DNS는 UDP 53만 쓰는 것이 아니다. zone transfer와 큰 응답에는 TCP 53도 필요하다.

sudo firewall-cmd --add-service=dns --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

장애를 볼 때

마무리

Primary/Secondary DNS 구성은 단순 백업이 아니라 권한 DNS의 가용성과 운영 분리를 위한 기본 구조다. Primary에서 zone을 수정하고 serial을 올리며, Secondary는 허용된 transfer를 통해 복제한다. 검증은 dig AXFR, dig SOA, journalctl -u named 순서로 보면 된다.

문서 링크

• BIND 9 Administrator Reference Manual
• ISC BIND 9