반응형
안녕하세요! 오늘은 네트워크의 내비게이션 역할을 하는 DNS(Domain Name System) 구축에 대해 정리해 보겠습니다. 주신 실습 내용을 바탕으로 특정 환경에 국한되지 않고, 실무에서 바로 적용할 수 있도록 일반화하고 핵심만 간결하게 다듬었습니다.
1. 일반적인 DNS 구축 4단계 (BIND9 기준)
1단계: 패키지 설치
DNS 서버 데몬과 도구들을 설치합니다.
Bash
sudo apt update
sudo apt install bind9 bind9utils
2단계: 글로벌 옵션 설정 (/etc/bind/named.conf.options)
서버의 전반적인 동작(질의 허용 범위, 포워딩 등)을 정의합니다.
Plaintext
options {
directory "/var/cache/bind";
// 내부 네트워크의 질의만 허용
allow-query { 10.0.0.0/24; localhost; };
// 모르는 도메인은 외부 DNS(예: 8.8.8.8)로 전달 (캐시 서버 역할)
forwarders { 8.8.8.8; };
recursion yes;
};
3단계: 존(Zone) 선언 (/etc/bind/named.conf.local)
직접 관리할 도메인 이름과 장부(Zone file)의 위치를 등록합니다.
Plaintext
zone "example.com" {
type master; // 이 서버가 원본(Master)임을 선언
file "/etc/bind/db.example.com"; // 장부 파일 경로
};
4단계: 존 파일(장부) 작성 (/etc/bind/db.example.com)
서브 도메인과 IP 주소를 매핑하는 핵심 파일입니다.
Plaintext
$TTL 86400
@ IN SOA ns1.example.com. admin.example.com. (
1 ; Serial (수정 시마다 증가)
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
@ IN NS ns1.example.com.
ns1 IN A 10.0.0.10 ; 네임서버 본인 IP
; 서비스할 호스트 (A 레코드)
@ IN A 10.0.0.10
www IN A 10.0.0.10
db IN A 10.0.0.20
- 적용: sudo systemctl restart bind9
2. [심화] 역할에 따른 DNS 설정 (캐시 vs 공식)
DNS는 역할에 따라 재귀 쿼리(Recursion) 허용 여부가 달라야 합니다.
- 캐시 DNS 서버 (내부망용): 내부망 사용자를 위해 모르는 도메인을 외부 최상위 DNS에 대신 물어다 줍니다.
- recursion yes;
- forwarders { 상위_DNS_IP; };
- 공식(Authoritative) DNS 서버 (외부 서비스용): 자기가 관리하는 존(Zone) 데이터만 응답해야 하며, 디도스(DDoS) 공격의 타겟이 되지 않도록 남의 질의를 대신해주면 안 됩니다.
- recursion no;
3. [보안/가용성] 마스터-슬레이브 연동 및 TSIG 키 설정
단일 고장을 막기 위해 보조(Slave) 서버를 두고, 데이터를 안전하게 동기화(Zone Transfer)하는 설정입니다.
① 보안 키 생성 및 전송 (Master 서버에서)
영역 전송 시 사용할 TSIG 암호화 키를 만들고 Slave 서버로 보냅니다.
Bash
# 키 생성
sudo tsig-keygen -a HMAC-SHA256 example-key > /etc/bind/example.key
# Slave 서버(예: 10.0.0.20)로 키 파일 전송
scp /etc/bind/example.key /etc/bind/rndc.key root@10.0.0.20:/etc/bind/
② 권한 설정 (Master / Slave 모두 필수!)
BIND 데몬이 키 파일을 읽을 수 있도록 소유권과 권한을 맞춥니다. (Bad auth 에러 방지)
Bash
sudo chown bind:bind /etc/bind/example.key /etc/bind/rndc.key
sudo chmod 640 /etc/bind/example.key /etc/bind/rndc.key
③ Master 서버 설정 (named.conf.local)
Plaintext
include "/etc/bind/example.key";
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { key "example-key"; }; // TSIG 키를 가진 요청만 허용
also-notify { 10.0.0.20; }; // 업데이트 시 Slave에 통지
};
④ Slave 서버 설정 (named.conf.local)
Plaintext
include "/etc/bind/example.key";
server 10.0.0.10 {
keys { "example-key"; }; // Master 서버와 통신할 키 명시
};
zone "example.com" {
type slave;
file "/var/cache/bind/db.example.com"; // Slave는 cache 폴더에 저장
masters { 10.0.0.10; };
};
4. RNDC 원격 제어 및 서비스 검증
① RNDC 설정 (named.conf.options)
원격지에서 DNS 데몬을 제어할 수 있도록 포트를 엽니다.
Plaintext
controls {
inet 0.0.0.0 port 953 allow { 127.0.0.1; 10.0.0.10; } keys { "rndc-key"; };
};
② 검증 명령어 세트 (Troubleshooting)
설정 완료 후 아래 명령어들로 정상 작동 여부를 체크합니다.
Bash
# 1. 문법 오타 검사 (아무 출력 없으면 정상)
sudo named-checkconf
sudo named-checkzone "example.com" /etc/bind/db.example.com
# 2. 서비스 재시작
sudo systemctl restart bind9
# 3. RNDC 원격 연결 상태 확인 (Master에서 Slave 상태 묻기)
rndc -s 10.0.0.20 status
# 4. 실시간 로그 확인 (Zone Transfer 성공 여부 확인)
journalctl -u named -f반응형