패키지는 설치했는데 도메인이 조회되지 않거나, zone 파일을 작성했는데도 응답이 없는 상황에서 멈춰본 적 있다면 이 글이 필요한 단계입니다.
특히 FreeBSD에서 BIND를 설정할 때는 “설치만 하면 된다”는 오해 때문에 named.conf와 zone 구조에서 많이 헷갈립니다.
이 글은 설치 이후 실제로 동작하게 만드는 데 필요한 설정 흐름과 막히기 쉬운 지점을 중심으로 정리합니다.
1. DNS 서버 구조와 BIND 동작 흐름
DNS 서버를 처음 구성할 때 “설정 파일만 맞으면 된다”라고 생각하기 쉽지만, 실제로는 요청 흐름을 이해하지 못하면 어디서 막혔는지 판단하기 어렵습니다.
BIND(named)는 클라이언트 요청을 받아 zone 파일을 기준으로 응답하거나, 외부 DNS로 질의를 전달하는 구조로 동작합니다.
즉, named.conf는 “어떤 영역을 담당할지”, zone 파일은 “어떤 값을 반환할지”를 나눠 담당합니다.
실제 설정 단계에서는 named.conf만 수정하고 zone 파일을 비워둔 상태에서 테스트를 시도하는 경우가 많습니다. 이 경우 서비스는 실행되지만 응답은 나오지 않습니다.
이 구조를 이해하면 문제를 파일 단위로 나눠 확인할 수 있습니다.
헷갈리기 쉬운 부분: 설정 파일과 zone 파일의 역할을 혼동하면, 오류가 나지 않는데도 동작하지 않는 상황이 발생합니다.
2. BIND 설치 후 바로 해야 할 초기 설정
설치 직후 바로 named를 실행하는 경우가 많은데, 기본 설정 상태에서는 외부 요청을 받지 못하는 경우가 있습니다.
FreeBSD에서는 pkg로 BIND를 설치한 후 rc.conf에 named_enable 설정을 추가하고, 기본 디렉터리 구조를 확인해야 합니다.
또한 chroot 환경 여부나 실행 경로에 따라 설정 파일 위치가 달라질 수 있습니다.
실무에서는 설치는 정상적으로 끝났는데 서비스가 시작되지 않는 경우가 자주 발생합니다. 대부분은 권한 문제나 설정 파일 경로 오류입니다.
특히 로그를 확인하지 않고 재시작만 반복하는 경우 해결이 늦어집니다.
놓치기 쉬운 포인트: 서비스 실행 전 설정 파일 위치와 권한을 먼저 확인해야 불필요한 재시작을 줄일 수 있습니다.
3. named.conf에서 가장 많이 틀리는 부분
named.conf는 BIND의 핵심 설정 파일이지만, 옵션 하나만 잘못 설정해도 전체 서비스가 동작하지 않을 수 있습니다.
대표적으로 listen-on, allow-query, recursion 설정이 잘못되면 외부에서 접근이 되지 않거나 내부에서도 조회가 실패할 수 있습니다.
zone 선언 역시 파일 경로와 타입(master/slave)을 정확히 맞춰야 합니다.
설정은 맞는 것처럼 보이는데 조회가 안 되는 경우, 실제로는 listen-on을 localhost로만 제한해 둔 경우가 많습니다.
이 부분은 설정 자체보다 “어디서 접근할 것인지”를 먼저 정리해야 실수가 줄어듭니다.
여기서 갈리는 핵심: named.conf는 문법보다 접근 범위 설정에서 더 자주 문제가 발생합니다.
4. Zone 파일 작성 시 헷갈리는 포인트
Zone 파일을 작성할 때는 형식 오류로 인해 named가 실행되지 않거나, 실행되더라도 일부 레코드가 무시되는 경우가 있습니다.
SOA, NS, A 레코드 순서를 지키고, 마지막에 점(.)을 붙이는지 여부도 중요합니다.
특히 도메인 끝에 점을 붙이지 않으면 자동으로 현재 도메인이 붙어 잘못된 값이 생성됩니다.
실제로 zone 파일을 작성한 후에도 nslookup이나 dig에서 결과가 다르게 나오는 경우가 있습니다. 대부분은 캐시나 잘못된 FQDN 때문입니다.
처음 설정할 때는 레코드 하나만 추가해서 테스트하는 방식이 더 안정적입니다.
헷갈리기 쉬운 부분: 점 하나 차이로 완전히 다른 도메인이 만들어질 수 있다는 점을 놓치기 쉽습니다.
5. 포트와 방화벽 설정에서 놓치는 부분
DNS는 기본적으로 53번 포트를 사용하지만, TCP와 UDP 모두 열려 있어야 정상적으로 동작합니다.
방화벽에서 UDP만 열어두거나, 내부 네트워크만 허용된 상태에서는 외부에서 조회가 되지 않습니다.
FreeBSD에서는 pf나 ipfw 설정에 따라 접근이 제한될 수 있습니다.
설정이 모두 끝났는데도 외부에서 조회가 안 되는 경우, 대부분 이 단계에서 막힙니다.
특히 클라우드 환경에서는 보안 그룹 설정까지 별도로 확인해야 합니다.
놓치기 쉬운 포인트: DNS는 단순히 포트 하나만 여는 것이 아니라, 프로토콜과 접근 범위를 함께 확인해야 합니다.
6. 서비스 실행 후 테스트와 확인 방법
설정이 끝났다면 named를 실행하고 바로 테스트를 진행해야 합니다.
dig, nslookup 같은 도구를 사용해 로컬과 외부에서 각각 조회를 시도해 보는 것이 기본입니다.
또한 /var/log/messages 또는 named 로그를 확인하면 오류 원인을 빠르게 찾을 수 있습니다.
많은 경우 테스트를 한 번만 하고 넘어가는데, 실제로는 캐시 때문에 결과가 달라질 수 있습니다.
따라서 레코드를 수정한 뒤에는 재시작과 함께 캐시 초기화까지 고려해야 합니다.
여기서 갈리는 핵심: 테스트는 한 번이 아니라, 환경별로 나눠 확인해야 문제 위치를 정확히 찾을 수 있습니다.
자주 묻는 질문 (FAQ)
Q1. named는 실행되는데 도메인이 조회되지 않습니다.
zone 파일 경로나 named.conf의 zone 선언이 맞는지 먼저 확인하는 것이 좋습니다. 실행과 응답은 별개로 동작합니다.
Q2. 내부에서는 되는데 외부에서 안 됩니다.
listen-on 설정과 방화벽 정책을 함께 확인해야 합니다. 특히 외부 IP 바인딩 여부가 중요합니다.
Q3. zone 파일 수정 후 바로 적용되나요?
기본적으로는 재시작 또는 reload가 필요합니다. 캐시 때문에 즉시 반영되지 않을 수도 있습니다.
Q4. reverse zone은 꼭 설정해야 하나요?
필수는 아니지만, 메일 서버 등 일부 서비스에서는 reverse lookup이 요구될 수 있습니다.
Q5. 설정 오류는 어디서 확인하나요?
named-checkconf, named-checkzone 명령어를 사용하면 실행 전에 오류를 확인할 수 있습니다.
마무리
FreeBSD에서 DNS 서버를 구축할 때는 단순히 설정 파일을 채우는 것보다, 요청 흐름과 각 파일의 역할을 구분하는 것이 더 중요합니다.
특히 named.conf와 zone 파일, 그리고 네트워크 설정을 각각 분리해서 확인하면 문제 해결 속도가 훨씬 빨라집니다.
처음에는 복잡해 보이지만, 한 번 구조를 이해하면 이후 설정은 훨씬 단순해집니다.
지금 단계에서 해볼 것:
named.conf에서 listen-on과 zone 선언 확인
zone 파일 문법 검사 (named-checkzone)
로컬 → 외부 순서로 조회 테스트 진행
※ 이 글은 일반적인 FreeBSD + BIND 환경을 기준으로 정리된 내용이며, 시스템 환경, 버전, 네트워크 구성에 따라 일부 설정 방식은 달라질 수 있습니다.