/엔지니어/네트워킹 / 서버/BIND9 DNS 서버 구축 — 권한 있는 네임서버
네트워킹 / 서버고급linuxbind9dnsnamed

BIND9 DNS 서버 구축 — 권한 있는 네임서버 운영 완전 가이드

BIND9로 권한 있는(authoritative) 네임서버를 구축합니다. named.conf 구조, 정·역방향 존 파일, SOA·NS·MX 레코드, 마스터/슬레이브 존 전송, DNSSEC 기초까지 다룹니다.

권한 있는(authoritative) DNS 서버 란?

DNS 서버는 크게 두 종류로 나뉩니다. 리커시브 리졸버(recursive resolver)는 클라이언트 대신 다른 서버에 질의해 답을 찾아주는 서버이고(예: 8.8.8.8), 권한 있는 네임서버(authoritative)는 특정 도메인(존, zone)의 실제 데이터를 보유하고 그 도메인에 대한 질의에 "공식 답변"을 내려주는 서버입니다.

직접 도메인을 보유하고 ns1.example.com처럼 자신의 네임서버로 운영하려면 권한 있는 서버가 필요합니다. BIND9(Berkeley Internet Name Domain)는 가장 널리 쓰이는 구현체입니다. 이 가이드는 BIND9로 권한 있는 마스터/슬레이브 네임서버를 구성하는 데 집중합니다. (클라이언트 측 조회 도구인 dig/nslookup 사용법은 별도 가이드 영역입니다.)

권한 있는 서버와 오픈 리졸버를 한 서버에서 동시에 운영하지 마세요. 오픈 리졸버는 DNS 증폭 공격에 악용됩니다. 권한 있는 서버에서는 반드시 recursion no; 로 재귀를 끕니다.

설치

Bash
# Debian/Ubuntu
sudo apt install -y bind9 bind9utils bind9-dnsutils

# RHEL/Rocky
sudo dnf install -y bind bind-utils

named -v          # 버전 확인

데몬 이름은 named이고 서비스명은 배포판에 따라 named 또는 bind9입니다.

named.conf 구조

설정은 보통 다음 파일들로 분리됩니다.

파일역할
/etc/bind/named.conf최상위, 아래 파일들을 include
named.conf.options전역 옵션(listen, recursion 등)
named.conf.local로컬 존 정의
/var/lib/bind/ 또는 /etc/bind/zones/존 파일 위치

전역 옵션 예시:

BIND
// /etc/bind/named.conf.options
options {
    directory "/var/cache/bind";

    listen-on { any; };
    listen-on-v6 { any; };

    // 권한 있는 서버이므로 재귀 비활성화
    recursion no;
    allow-query { any; };

    // 존 전송은 슬레이브에게만 허용
    allow-transfer { none; };

    dnssec-validation auto;
    version "not disclosed";       // 버전 노출 방지
};

정방향 존 파일

존을 named.conf.local에 등록합니다.

BIND
// /etc/bind/named.conf.local
zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
    allow-transfer { 192.0.2.53; };   // 슬레이브 IP
    also-notify { 192.0.2.53; };
};

존 파일 본문:

DNS
; /etc/bind/zones/db.example.com
$TTL    86400
@       IN      SOA     ns1.example.com. admin.example.com. (
                        2026061801      ; Serial (YYYYMMDDnn)
                        3600            ; Refresh
                        1800            ; Retry
                        1209600         ; Expire
                        86400 )         ; Negative Cache TTL

; 네임서버
@       IN      NS      ns1.example.com.
@       IN      NS      ns2.example.com.

; A 레코드
@       IN      A       192.0.2.10
ns1     IN      A       192.0.2.53
ns2     IN      A       192.0.2.54
www     IN      A       192.0.2.10

; 메일
@       IN      MX  10  mail.example.com.
mail    IN      A       192.0.2.20

; 기타
@       IN      TXT     "v=spf1 mx -all"
ftp     IN      CNAME   www

SOA 레코드의 의미

SOA(Start of Authority)는 존의 메타데이터입니다. 필드 의미는 다음과 같습니다.

필드의미
Serial존 버전. 변경할 때마다 증가시켜야 슬레이브가 갱신함
Refresh슬레이브가 마스터를 확인하는 주기
RetryRefresh 실패 시 재시도 간격
Expire마스터 연결 실패 시 슬레이브가 데이터를 폐기하는 시점
Negative TTL존재하지 않는 레코드(NXDOMAIN)의 캐시 시간

존 파일을 수정한 뒤 Serial을 올리지 않으면 슬레이브와 캐시가 변경 사항을 절대 가져가지 않습니다. 가장 흔한 실수입니다. 날짜 기반(YYYYMMDDnn) 규칙을 쓰면 관리가 쉽습니다.

역방향 존 (PTR)

IP→이름 조회(역방향)는 in-addr.arpa 존으로 구성합니다. 192.0.2.0/24 대역이라면:

BIND
// named.conf.local
zone "2.0.192.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.192.0.2";
};
DNS
; /etc/bind/zones/db.192.0.2
$TTL    86400
@       IN      SOA     ns1.example.com. admin.example.com. (
                        2026061801 3600 1800 1209600 86400 )
@       IN      NS      ns1.example.com.

10      IN      PTR     example.com.
20      IN      PTR     mail.example.com.

PTR의 왼쪽 숫자는 IP의 마지막 옥텟입니다. 메일 서버 운영 시 역방향 레코드가 없으면 수신 거부되는 경우가 많습니다.

설정 검증과 적용

Bash
# 전역 설정 문법 검사
sudo named-checkconf

# 존 파일 검사 (존 이름, 파일경로)
sudo named-checkzone example.com /etc/bind/zones/db.example.com
sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

# 무중단 리로드
sudo rndc reload
# 특정 존만
sudo rndc reload example.com

named-checkzone은 Serial과 레코드 문법을 검증해주므로 반영 전 반드시 실행합니다.

마스터/슬레이브 존 전송

슬레이브 서버 named.conf.local:

BIND
zone "example.com" {
    type slave;
    masters { 192.0.2.53; };          // 마스터 IP
    file "/var/cache/bind/db.example.com";
};

마스터에서 also-notify로 NOTIFY를 보내면 슬레이브가 즉시 AXFR/IXFR로 존을 가져옵니다. 보안을 위해 TSIG 키로 전송을 인증하는 것이 권장됩니다.

Bash
# TSIG 키 생성
tsig-keygen -a hmac-sha256 transfer-key

생성된 키를 양쪽 named.conf에 넣고 allow-transfer { key transfer-key; }; 로 제한합니다.

동작 확인

Bash
# 자기 서버에 직접 질의 (권한 응답인지 aa 플래그 확인)
dig @192.0.2.53 example.com SOA +norecurse
dig @192.0.2.53 www.example.com A
dig @192.0.2.53 -x 192.0.2.10           # 역방향 PTR

# 존 전송 테스트 (allow-transfer 허용된 곳에서)
dig @192.0.2.53 example.com AXFR

응답 헤더에 flags: ... aa(authoritative answer)가 보이면 권한 있는 응답이 정상 동작하는 것입니다.

DNSSEC 기초

DNSSEC은 응답에 디지털 서명을 붙여 위변조를 방지합니다. BIND9는 인라인 서명을 지원합니다.

BIND
zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
    dnssec-policy default;            // 자동 키 관리·서명
    inline-signing yes;
};

서명 후 생성되는 DS 레코드를 상위 도메인 등록기관(레지스트라)에 등록해야 검증 체인이 완성됩니다.

트러블슈팅

증상원인
SERVFAIL존 파일 문법 오류 — named-checkzone 확인
슬레이브 미갱신Serial 미증가, allow-transfer 누락
권한 응답 안 옴(aa 없음)존 미로드, rndc reload 누락
named 기동 실패journalctl -u named, named-checkconf 확인

정리

항목핵심
권한 vs 재귀authoritative는 recursion no; 필수
존 파일SOA + NS + A/MX/CNAME/PTR
Serial수정 시마다 증가, 안 올리면 전파 안 됨
검증named-checkconf, named-checkzonerndc reload
마스터/슬레이브type slave + masters, TSIG로 전송 인증
DNSSECdnssec-policy + 상위에 DS 등록

BIND9 권한 서버 운영의 핵심은 "Serial 관리와 존 검증"입니다. 변경-검증-리로드 사이클을 습관화하면 대부분의 장애를 예방할 수 있습니다.

#bind9#dns#named#zone#authoritative
편집 안내 · Editorial Note

이 가이드는 AI 도구를 활용해 초안을 구성하고 사람이 명령어·문맥을 검토해 발행했습니다. 운영체제와 도구 버전에 따라 결과가 달라질 수 있으므로 적용 전 공식 문서를 함께 확인하세요. 오류를 발견하시면 이메일로 제보해 주세요.

질문 & 답변 (Q&A)

이 가이드에 대해 궁금한 점을 질문해보세요. 확인 후 답변드립니다.