개념 사전/네트워크 / 이름 해석
개념 사전 · 프로그램

BIND 9

BIND · Berkeley Internet Name Domain · ISC BIND · named

는 질의를 받아 권한 있는 영역 데이터나 재귀 조회 결과를 제공하는 서버 프로그램이다. 가 통신 규칙과 이름 체계라면 는 그 규칙을 구현한 소프트웨어이며, 서버 와 설정·검사·조회 도구를 함께 사용한다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

로고: Internet Systems Consortium 공식 자료. 제품 식별을 위해 표시하며 각 상표의 권리는 권리자에게 있습니다.

01무엇이고, 어떤 일을 하나

  • 조직이 관리하는 도메인의 SOA·NS·A·AAAA·MX 등의 레코드를 권한 서버로 제공한다.
  • 허용된 클라이언트를 대신해 재귀 조회를 수행하고 답을 캐시하거나 지정된 해석기로 전달한다.
  • 영역 전송··접근 정책과 로그를 이용하여 데이터의 배포와 검증 상태를 관리한다.

02어떤 순서로 동작하나

  1. 서버 역할과 범위 설정

    권한 서버, 재귀 리졸버, 포워더 중 맡을 역할과 질의를 허용할 클라이언트를 정한다. 의 options·zone· 등은 기능별 범위를 가지며 listen-on과 allow-query, 재귀 허용은 서로 다른 조건이다.

  2. 영역과 레코드 적재

    권한 서버는 zone 설정이 가리키는 영역 파일을 읽어 SOA·NS와 서비스 레코드를 적재한다. primary와 secondary의 자료 취득 방식이 다르며, secondary 동기화에는 SOA serial과 전송 정책이 관여한다.

  3. 질의 분류와 답 생성

    수신 질의가 자신이 책임지는 영역이면 해당 자료로 응답한다. 허용된 재귀 질의는 유효 캐시를 먼저 활용하거나 위임·포워딩 정책을 따라 답을 구하며, 검증 여부도 응답 결과에 영향을 준다.

  4. 변경 검증과 관찰

    설정 구문은 , 영역 자료는 등으로 확인한 뒤 적용한다. 서비스가 실행 중이라는 사실과 올바른 서버가 원하는 레코드·플래그·TTL로 답한다는 사실을 조회 결과와 로그로 따로 확인한다.

03먼저 알아둘 용어와 구성요소

에서 질의를 처리하는 서버 프로세스다. 배포판의 서비스 이름도 일 수 있다.
서버 옵션, 영역, 접근 목록, 로깅 등을 선언하는 설정 파일이다. 실제 위치와 포함 파일은 배포판 구성에 따라 다르다.
한 영역의 SOA·NS와 여러 자원 레코드를 텍스트 등 지원 형식으로 저장하는 자료다.
설정 파일과 포함 파일의 구문을 검사하는 도구다. 기본 구문 검사만으로 실행 환경과 모든 의미적 오류까지 보장하지 않는다.
영역 이름과 파일을 받아 해당 영역 자료의 구문과 무결성을 점검하는 도구다.
인증된 제어 채널로 의 상태 조회와 재적재 등 관리 작업을 요청하는 도구다.
서버에 이름·레코드 유형 등을 지정해 질의하고 응답 플래그·TTL·레코드를 보여 주는 조회 도구다.
리졸버가 스스로 위임을 추적하는 대신 필요한 재귀 질의를 전달하는 상위 해석기다.
서버가 로컬 원본 자료 등을 바탕으로 제공하는 영역이다. 오래된 설정과 문서에서는 master라는 표현도 보인다.
허용된 원본 서버에서 영역 전송으로 자료를 받아 제공하는 영역이다. 오래된 표현은 slave이며 권한 응답 능력이 열등하다는 뜻은 아니다.
LEARN THROUGH PRACTICE

실습: BIND 존 파일에서 응답과 웹 이름까지 검증

권한 데이터· 질의 결과·HTTP 가상 호스트를 차례로 분리해 검증한다.

실습 구성과 전제

  • 서버와 클라이언트가 있는 연습망이다. 사진의 존 파일과 nslookup 출력은 서로 다른 구성 예다.
  • 재구성은 example.test와 192.0.2.53을 사용한다. 실제 서버의 주소·허용 질의 범위와 listen 설정을 먼저 맞춘다.

  1. 존 파일의 데이터 역할 읽기

    • SOA는 존의 관리 정보, NS는 권한 서버 이름, A는 이름에 대응하는 다. ns·ww1·ww2가 같은 IP를 사용해도 형식 오류가 아니다.
    • 그림의 AAAA ::1은 조회한 클라이언트 자신을 뜻하는 루프백이다. 원격 서비스용 주소로 복사하지 않는다. allow-update는 동적 갱신 제어이며 존 전송 허용과 별개다.
    text
    $ORIGIN example.test.
$TTL 300
@ IN SOA ns.example.test. hostmaster.example.test. (
  2026101201 3600 900 604800 300 )
@   IN NS ns.example.test.
ns  IN A 192.0.2.53
ww1 IN A 192.0.2.53
ww2 IN A 192.0.2.53

    원점과 끝 점을 명시한 별도 재구성 존 파일

    DNS와 웹 서비스 · /var/named/x.com.zone (6)원본 크기로 보기 ↗
    • SOA 뒤 serial·refresh·retry·expire 등의 값이 있다.
    • ns·ww1·ww2의 A가 같은 주소이며 별도로 AAAA ::1이 보인다.
    확인 기준

    FQDN 끝의 점과 존 원점을 확인한다. 정방향 조회는 이름→주소다.

  2. 로드 전에 문법과 존 범위 검사

    • 는 설정 문법, 은 지정한 존 데이터의 문법·관계를 검사한다. 파일 검사 성공이 곧 실제 서비스 응답 성공은 아니다.
    • 파일의 zone 선언 이름·경로·서비스의 읽기 권한이 맞아야 로딩된다. 검사를 통과한 뒤 해당 존을 다시 읽고 오류 로그를 확인한다.
    text
    named-checkconf
named-checkzone example.test /var/named/example.test.zone
rndc reload example.test

    / 계열 경로를 사용한 재구성 검증 예시

    확인 기준

    검사 오류가 있으면 reload로 해결하려 하지 말고 지목한 줄부터 수정한다.

  3. 서버 지정 질의와 최종 응답 구분

    • nslookup의 Server/Address는 질의한 서버다. 아래 Name/Address가 질의 이름의 응답이므로 같은 숫자가 두 번 보여도 역할은 다르다.
    • 직접 서버를 지정하면 클라이언트의 기본 설정 문제와 권한 서버 문제를 분리할 수 있다.
    text
    dig @192.0.2.53 ww1.example.test A +norecurse
nslookup ww1.example.test 192.0.2.53

    명령의 이름·주소는 재구성 존 기준

    5/21 - DNS · 실습·개념 참고 화면 51원본 크기로 보기 ↗
    • 명령 끝에 질의할 DNS 서버 주소가 명시되어 있다.
    • Server·Address와 아래 Name·Address가 구분되어 출력된다.
    확인 기준

    의도한 서버가 의도한 A 레코드로 응답하는지 확인한다.

  4. 같은 IP의 서로 다른 웹 이름 검증

    • 는 서버 주소를 알려 주고 HTTP Host는 가상 호스트를 선택하게 한다. 성공만으로 올바른 웹 파일이 선택되었다고 판단하지 않는다.
    • 두 이름을 같은 IP로 조회한 뒤 각각의 Host로 요청하여 화면을 비교한다. 실패 시 와 웹 서버 설정을 분리해 조사한다.
    text
    curl --resolve ww1.example.test:80:192.0.2.53 http://ww1.example.test/
curl --resolve ww2.example.test:80:192.0.2.53 http://ww2.example.test/

    를 우회하여 HTTP 가상 호스트만 따로 검증하는 재구성 예시

    확인 기준

    A 응답은 같아도 웹 구성에 따라 서로 다른 페이지가 반환될 수 있다.

실습에서 확인한 동작 원리

  • 파일 문법·존 로딩· 응답·웹 선택은 별도 검증 단계다.
  • NS 레코드와 ns 이름의 A 레코드는 서로 다른 역할이며 둘 다 필요한 조건을 살핀다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • 가상 example.com 영역에 www IN A 192.0.2.10을 두면 www.example.com의 A 조회에 그 주소를 제공한다. 영역 파일의 상대 이름과 끝에 점이 있는 절대 이름을 구별해야 의도하지 않은 이름 결합을 피할 수 있다.
  • 설정 변경 후 가 성공해도 zone 파일 권한, 잘못된 영역 이름, 수신 주소, 방화벽 조건 때문에 서비스는 실패할 수 있다. example.com <영역파일>로 자료를 검사하고 해당 서버를 지정한 응답의 AA·RCODE·ANSWER를 대조한다.
  • 권한 서버의 A 레코드를 바꾸었는데 클라이언트가 옛 주소를 받으면 어느 리졸버가 응답했는지와 남은 TTL을 본다. secondary의 SOA serial 불일치와 재귀 캐시의 유효 시간은 다른 갱신 단계이므로 한 번의 재시작으로 같은 문제라고 처리하지 않는다.

05혼동하기 쉬운 점과 확인 기준

  • listen-on을 넓히거나 allow-query를 any로 바꾸는 일은 학습망의 접근 설정 예일 뿐 모든 운영 서버의 정답이 아니다. 공개 권한 응답과 재귀·캐시 사용, 영역 전송 허용 범위는 각각 목적에 맞게 구분한다.
  • 패키지 설치와 위임 완료는 다르다. 실제 사용자가 해당 서버를 찾으려면 리졸버 설정 또는 상위 영역의 NS·필요한 glue 등 이름 해석 경로도 성립해야 한다.
  • 구형 원문의 master·slave, 배포판별 경로와 현대 의 primary·secondary 표현을 버전 문맥에서 읽는다. 구성 파일이 /etc에 있다는 이유만으로 소프트웨어가 폐기된 기술이라고 판단하지 않는다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

DNS 메시지·위임·캐시와 BIND 존 구성DNS 재귀 조회와 권한 응답, 레코드와 메시지 구조를 연결한다. 원문의 BIND 설정을 일관된 example 존으로 재구성하고 정방향·역방향·존 전송·DNSSEC의 역할을 구분한다.상세 노트 읽기 →
READ · OBSERVE · CONNECT

함께 보는 학습 자료

아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.

실습 가이드

ISC BIND 9 §3.2: Primary·Secondary와 영역 전송

구성 예와 그림으로 SOA serial·NOTIFY·AXFR/IXFR을 연결하고 캐시 만료와 secondary 동기화를 구분한다.

읽으면서 확인할 것
  • Authoritative Primary and Secondary 도해
  • SOA 비교·NOTIFY 이후 전송 순서
  • recursion·query-cache·transfer 허용 범위

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.