리눅스 권한형·재귀 DNS 서버 BIND9

BIND9(Berkeley Internet Name Domain, 데몬 이름은 named)는 ISC에서 개발하는 DNS 서버입니다. 자기 도메인의 레코드를 직접 서비스하는 권한 서버(authoritative)와, 클라이언트를 대신해 이름을 찾아 주는 재귀 리졸버(recursive)를 한 데몬으로 모두 처리합니다. 인터넷 초창기부터 쓰여 온 사실상의 표준 구현이라, 도메인을 직접 운영하는 조직이라면 한 번쯤 마주치게 됩니다. 현재 운영 권장 버전은 ESV(장기 지원) 계열인 9.20.x이며, 9.18 계열은 2026년 6월에 지원이 종료되었습니다.

Ⅰ. BIND9 란?

 DNS 서버는 역할에 따라 두 가지로 나뉩니다. 하나는 example.com 같은 자기 영역(zone)의 레코드를 보유하고 그에 대한 질의에 응답하는 권한 서버이고, 다른 하나는 레코드를 갖고 있지 않은 클라이언트를 대신해 루트부터 답을 찾아 주는 재귀 리졸버입니다.

 앞서 다룬 Unbound는 후자(재귀 리졸버)에 특화된 도구이고, dnsmasq는 소규모 전달·DHCP용입니다. 이들만으로는 "내 도메인의 레코드를 인터넷에 직접 서비스한다"는 요구를 채우기 어렵습니다. 자기 도메인을 외부에 응답하려면 권한 서버가 필요합니다.

 BIND9는 이 권한 서버 역할을 표준적으로 수행하면서, 필요하면 재귀 리졸버로도 동작합니다. 영역 파일(zone file)에 레코드를 정의해 두면 그 도메인에 대한 질의에 응답하고, 2차 서버로 영역을 복제(zone transfer)하며, DNSSEC 서명까지 처리합니다. 쉽게 말해 "도메인 레코드를 직접 관리하고 서비스하는 DNS 서버의 원형" 역할을 합니다.

Ⅱ. BIND9 주요 특징

ⅰ. 권한·재귀 겸용: 하나의 named 데몬으로 권한 서버와 재귀 리졸버를 모두 처리합니다. 설정에 따라 권한 전용, 재귀 전용, 혼합으로 운영할 수 있습니다.

ⅱ. 영역 파일 기반 관리: 레코드를 텍스트 영역 파일에 정의합니다. SOA, NS, A, AAAA, MX, CNAME, TXT 등 표준 레코드 유형을 그대로 씁니다.

ⅲ. 1차·2차 복제(zone transfer): 1차(primary) 서버가 원본을 갖고, 2차(secondary) 서버가 AXFR/IXFR로 복제받아 이중화합니다. 변경 시 NOTIFY로 2차에 갱신을 알립니다.

ⅳ. DNSSEC 서명: 영역에 서명해 응답의 위·변조를 검증할 수 있게 합니다. 9.16 이후 dnssec-policy를 이용한 자동 키 관리·서명(inline-signing)을 지원해 과거보다 운영이 단순해졌습니다.

ⅴ. 뷰(view)로 분리 응답: 질의 출처에 따라 다른 응답을 주는 스플릿 호라이즌 DNS가 가능합니다. 내부망에는 사설 IP를, 외부에는 공인 IP를 응답하는 식입니다.

ⅵ. 세밀한 접근 제어: allow-query, allow-transfer, allow-recursion 등으로 질의·복제·재귀 허용 대상을 대역 단위로 제한합니다.

ⅶ. rndc 원격 제어: rndc 명령으로 실행 중인 named에 영역 재적재, 설정 반영, 캐시 비우기, 통계 조회 등을 지시합니다.

Ⅲ. BIND9 동작 방식

 1) 구성 요소

ⅰ. named: 실제 질의를 받아 응답하는 DNS 데몬입니다. 기본적으로 53 포트(UDP/TCP)에서 대기합니다.

ⅱ. named.conf: 서버 전역 설정과 각 영역 선언을 담는 주 설정 파일입니다. 리스닝 주소, 접근 제어, 영역 정의, 옵션이 여기 들어갑니다.

ⅲ. 영역 파일(zone file): 개별 도메인의 레코드를 담은 파일입니다. 파일 맨 위에 SOA와 NS를 두고 그 아래 A/MX/CNAME 등을 나열합니다.

ⅳ. rndc / rndc.key: named를 원격 제어하는 도구와 그 인증 키입니다. 953 포트로 데몬과 통신합니다.

ⅴ. 점검 도구: named-checkconf(설정 문법 검사)와 named-checkzone(영역 파일 검사)으로 기동 전에 오류를 걸러 냅니다.

 2) 데이터 흐름: 권한 서버로 동작할 때는 자기 영역에 대한 질의를 받으면 영역 파일의 레코드로 바로 응답합니다. 재귀 리졸버로 동작할 때는 먼저 캐시를 확인하고, 없으면 루트부터 권한 서버까지 질의를 이어 가 답을 찾은 뒤 캐시에 담습니다. 2차 서버는 1차의 NOTIFY를 받거나 SOA의 refresh 주기에 따라 영역을 복제받아 최신 상태를 유지합니다.

Ⅳ. BIND9 구성 및 동작 흐름도

1) 클라이언트가 named(53)에 이름 질의         ⬇   2) 질의한 이름이 내가 가진 영역인가?         ⬇ (권한 영역이면)   3) 영역 파일 레코드로 즉시 응답 (authoritative answer)         ⬇ (내 영역이 아니고 재귀 허용이면)   4) 캐시 확인 → 없으면 루트 → TLD → 권한 서버로 재귀 질의         ⬇   5) 결과 캐시 저장 후 응답 / 1차 변경 시 2차로 NOTIFY·zone transfer

Ⅴ. BIND9 설치 방법

 대부분의 배포판 기본 저장소에 포함되어 있습니다. 데몬 패키지와 조회 유틸리티(dig 등) 패키지 이름이 배포판마다 다른 점만 주의하면 됩니다.

 ⅰ. Ubuntu / Debian 계열 (데몬은 bind9, dig는 bind9-dnsutils)

[root@feccle] # sudo apt update [root@feccle] # sudo apt install bind9 bind9-utils bind9-dnsutils [root@feccle] # sudo systemctl enable --now named

 ⅱ. RHEL / Rocky / AlmaLinux 계열 (데몬은 bind, dig는 bind-utils, EPEL 불필요)

[root@feccle] # sudo dnf install bind bind-utils [root@feccle] # sudo systemctl enable --now named

 ⅲ. 설치 후 버전과 설정 문법을 확인합니다. 설정 경로는 Debian 계열이 /etc/bind/, RHEL 계열이 /etc/named.conf 로 다릅니다.

[root@feccle] # named -v  # 설치된 버전 확인 (예: BIND 9.20.x) [root@feccle] # sudo named-checkconf  # 주 설정 문법 검사 [root@feccle] # systemctl status named  # 데몬 동작 확인

Ⅵ. BIND9 기본 설정 및 운영 시 주의점

 1) 권한 영역 설정 예시. named.conf 에 영역을 선언하고, 별도 영역 파일에 레코드를 둡니다.

// named.conf 일부 options {   directory "/var/named";   allow-query { any; };  // 권한 응답은 공개   recursion no;  // 권한 전용 서버는 재귀를 끈다 (오픈 리졸버 방지) }; zone "example.com" IN {   type primary;  // 구버전 표기는 master   file "example.com.zone";   allow-transfer { 192.0.2.2; };  // 2차 서버에만 복제 허용 };

 2) 영역 파일 예시(/var/named/example.com.zone). 맨 위 SOA의 serial은 레코드를 바꿀 때마다 반드시 올려야 2차 서버가 변경을 인식합니다.

$TTL 3600 @  IN SOA ns1.example.com. admin.example.com. (     2026091301  ; serial (변경 때마다 증가)     3600 900 1209600 3600 ) @  IN NS  ns1.example.com. @  IN A   203.0.113.10 ns1 IN A   203.0.113.10 www IN A   203.0.113.20 @  IN MX 10 mail.example.com.

 적용 전에는 named-checkzone example.com /var/named/example.com.zone 로 영역 파일을 검사하고, named-checkconf 로 설정을 검사한 뒤 rndc reload 로 반영합니다.

 3) 운영 시 자주 겪는 문제와 조치

ⅰ. 53 포트 충돌로 기동 실패: 최근 배포판은 systemd-resolved가 127.0.0.53:53 을 점유합니다. 서버를 실제 IP에 바인딩하면 대개 겹치지 않지만, 0.0.0.0 으로 열면 충돌합니다. resolved의 스텁 리스너를 끄거나(DNSStubListener=no) named의 listen-on 주소를 명확히 지정합니다. 로그의 "address already in use"가 이 경우입니다.

ⅱ. 영역을 고쳤는데 반영이 안 됨: 대부분 SOA serial을 올리지 않은 탓입니다. serial이 그대로면 named는 변경이 없다고 보고 2차도 복제하지 않습니다. 값을 올리고 rndc reload 합니다. 날짜형(YYYYMMDDnn) serial을 쓰면 실수를 줄일 수 있습니다.

ⅲ. RHEL에서 영역 파일을 못 읽거나 못 씀: SELinux 컨텍스트 문제입니다. 영역 파일은 named_zone_t 컨텍스트여야 하고, named가 파일을 갱신해야 하면(동적 업데이트·DNSSEC 서명) setsebool -P named_write_master_zones on 이 필요합니다. 권한(named 사용자 소유)과 함께 restorecon 으로 컨텍스트를 맞춥니다.

ⅳ. rndc: connection refused / 인증 실패: named.conf 와 rndc.key 의 키가 어긋난 경우입니다. rndc-confgen -a 로 키를 다시 만들고 named를 재시작합니다. 953 포트가 방화벽에 막혀 있지 않은지도 확인합니다.

ⅴ. 2차 서버로 복제가 안 됨(zone transfer 실패): 1차의 allow-transfer 에 2차 IP가 없거나, 2차에서 1차로 가는 53/tcp 가 막힌 경우가 많습니다. AXFR는 TCP를 쓰므로 UDP만 열어 둔 방화벽에서 실패합니다. dig @1차IP example.com AXFR 로 복제 가능 여부를 직접 확인합니다.

ⅵ. 재귀를 인터넷에 열어 둠(오픈 리졸버): recursion yes 인 서버에 allow-recursion 제한이 없으면 외부에서 DNS 증폭 공격에 악용될 수 있습니다. 권한 전용이면 recursion no, 내부 리졸버면 allow-recursion 을 내부 대역으로 제한합니다.

Ⅶ. BIND9 자주 쓰는 명령어

명령어	설명
named-checkconf	주 설정 파일 문법 검사 (기동 전 필수)
named-checkzone [영역] [파일]	영역 파일 문법·레코드 검사
rndc reload	영역 파일을 다시 읽어 적용
rndc reconfig	설정을 다시 읽고 새 영역만 적재 (전체 재적재 없이)
rndc flush	재귀 캐시 전체 비우기
rndc status	데몬 상태·영역 수·질의 통계 확인
rndc-confgen -a	rndc 제어용 키 생성
dig @127.0.0.1 example.com	특정 서버에 질의해 응답 확인
dig @1차IP example.com AXFR	영역 복제(zone transfer) 가능 여부 확인

Ⅷ. BIND9 활용 방안

 1) 주요 활용

 ⅰ. 자기 도메인의 권한 서버. 회사·기관이 소유한 도메인의 레코드를 직접 관리하고 인터넷에 서비스합니다.

 ⅱ. 1차·2차 이중화. 1차에서 관리하고 2차로 복제해, 한 서버가 죽어도 이름 해석이 이어지도록 합니다.

 ⅲ. 내부 DNS(스플릿 호라이즌). 뷰로 내부망과 외부에 다른 응답을 주어, 내부 서비스는 사설 IP로 해석하게 합니다.

 ⅳ. DNSSEC 서명 서버. 영역에 서명해 응답 변조를 막고, 검증형 리졸버가 신뢰할 수 있게 합니다.

 2) 대안 기술과의 비교

ⅰ. Unbound: 재귀·캐시에 특화된 리졸버입니다. 권한 서버 기능은 없으므로, 순수 내부 리졸버만 필요하면 Unbound가 더 단순합니다. 자기 영역을 서비스해야 하면 BIND9가 맞습니다.

ⅱ. NSD / PowerDNS: NSD는 권한 전용으로 가볍고 빠릅니다. PowerDNS는 레코드를 데이터베이스에 두어 프로그래밍적 관리에 유리합니다. 영역 수가 적고 텍스트 파일 관리가 편하면 BIND9, 대량 영역을 DB로 다루려면 PowerDNS가 낫습니다.

ⅲ. CoreDNS: 쿠버네티스의 서비스 디스커버리에 특화되어 있습니다. 일반 도메인 권한 서비스에는 BIND9가, 클러스터 내부 DNS에는 CoreDNS가 자연스럽습니다.

 3) 언제 쓰지 않는 것이 좋은가

 ⅰ. 재귀·캐시만 필요한 내부 리졸버라면 BIND9는 기능이 과합니다. 설정이 더 단순한 Unbound나 dnsmasq가 낫습니다.

 ⅱ. 수백 개 이상의 영역을 애플리케이션과 연동해 자동으로 다뤄야 한다면, 파일 기반 관리보다 DB 기반의 PowerDNS가 유지보수에 유리합니다.

 정리하면 BIND9는 자기 도메인의 레코드를 직접 관리하고 인터넷에 서비스하는 권한 서버가 필요한 경우에 적합합니다. 오래된 만큼 설정 문법과 참고 자료가 방대해 진입에는 시간이 들지만, 권한·재귀·복제·DNSSEC를 한 번에 감당하는 폭넓은 기능이 장점입니다. 반대로 단순 리졸버 용도만이면 더 가벼운 대안을 고려하는 편이 낫습니다.