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

DNS

Domain Name System · 도메인 이름 시스템

는 계층적인 이름 공간의 정보를 분산된 서버에서 조회하는 시스템이다. 이름과 IP만 연결하는 단일 표가 아니라 여러 레코드·위임·캐시·권한 서버와 재귀 해석기의 협업으로 동작한다.

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

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

  • 사용자가 쓰는 이름을 A·AAAA 등 통신에 필요한 자료로 해석한다.
  • NS 위임과 존 경계로 관리 권한을 나눠 전체 이름 공간을 확장한다.
  • 과 양성·음성 캐시를 사용해 반복 질의의 지연과 권한 서버 부하를 줄인다.

02어떤 순서로 동작하나

  1. Stub의 요청

    단말 stub resolver가 재귀 Resolver에 이름과 질의 종류를 보낸다. Resolver가 먼저 유효한 캐시를 확인한다.

  2. 위임 단서 수집

    답이 없으면 루트·상위 도메인 서버에서 해당 이름을 책임지는 권한 서버의 단서를 얻는다.

  3. 권한 서버 질의

    위임을 따라 최종 권한 서버에 필요한 레코드를 묻는다. 중간 위임 응답과 최종 데이터 응답을 구별한다.

  4. 별칭 해결

    이면 목표 이름에 필요한 추가 조회를 수행할 수 있다. 단말에 반환할 결과를 조합한다.

  5. 응답·캐시

    Resolver가 결과를 단말에 돌려주고 조건에 맞게 보관한다. 이후 같은 질의는 남은 캐시 수명을 활용할 수 있다.

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

한 권한 서버가 책임지는 이름 공간 부분으로 도메인 전체와 항상 같지 않다.
클라이언트를 대신해 위임을 따라 답을 찾고 캐시하는 서버다.
Resource Record다. 이름·타입·클래스··타입별 데이터로 구성되는 자원 레코드다.
자료를 캐시에 유지할 수 있는 시간이다. 권한 서버의 변경이 모든 리졸버에 즉시 반영되지 않는 이유와 연결된다.
도메인 이름에 주소를 연결하는 자원 레코드다.
도메인 이름에 주소를 연결하는 자원 레코드다.
해당 영역을 담당하는 권한 서버의 이름을 나타내는 레코드다.
도메인의 메일을 받을 서버와 선호도를 나타내는 레코드다.
한 이름을 다른 정규 이름의 별칭으로 지정하는 레코드다.
Start of Authority 레코드다. 영역의 관리 정보와 serial, 동기화 관련 타이머 등을 담는다.
보통 역방향 조회에서 IP 주소에 연결할 이름을 나타내는 레코드다.
문자열 데이터를 저장하는 레코드다. 여러 응용의 정책·검증 정보에도 사용한다.
질의한 도메인 이름 자체가 존재하지 않음을 나타내는 응답 코드다.
이름은 존재하지만 요청한 유형의 레코드가 없다는 응답 상황이다. 별도의 응답 코드와 다르다.
서버가 질의를 정상 처리하지 못했음을 나타내는 응답 코드다.
Recursion Desired 플래그다. 질의자가 재귀 처리를 요청했음을 나타낸다.
Recursion Available 플래그다. 응답 서버가 재귀 기능을 제공할 수 있음을 나타낸다.
Authoritative Answer 플래그다. 질의 이름에 대해 권한 있는 응답임을 표시한다.
Authenticated Data 플래그다. 검증 리졸버가 으로 응답 데이터를 검증했음을 나타내는 조건부 신호다.
Extension Mechanisms for 다. OPT 의사 레코드로 수신 크기 등의 확장 정보를 전달한다.
Fully Qualified Domain Name이다. 이름 공간의 루트까지 포함한 완전한 도메인 이름이다.
영역 데이터를 전체 전송하는 방식이다.
이전 serial과의 차이를 이용해 영역 변경분을 전송하는 방식이다.
위임받은 서버의 이름을 다시 풀기 위해 필요한 주소 정보를 상위 영역이 보조적으로 제공하는 레코드다.
LEARN THROUGH PRACTICE

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

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

실습 구성과 전제

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

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

    • 는 존의 관리 정보, 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이 보인다.
    확인 기준

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

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

    • -checkconf는 설정 문법, -checkzone은 지정한 존 데이터의 문법·관계를 검사한다. 파일 검사 성공이 곧 실제 서비스 응답 성공은 아니다.
    • 파일의 선언 이름·경로·서비스의 읽기 권한이 맞아야 로딩된다. 검사를 통과한 뒤 해당 존을 다시 읽고 오류 로그를 확인한다.
    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가 구분되어 출력된다.
    확인 기준

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

  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 이름의 는 서로 다른 역할이며 둘 다 필요한 조건을 살핀다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • www.example.com의 이름 바이트는 03 www 07 example 03 com 00이다. 길이 바이트 3개와 루트 1바이트까지 합치면 QNAME은 17바이트다. 기본 헤더 12바이트에 QNAME 17, QTYPE 2, QCLASS 2를 더해 33바이트다. 이 계산은 추가 레코드나 옵션이 없는 단일 A 질의를 전제로 한다.
  • 응답에 질문을 같은 위치로 복사하고 Answer NAME을 c0 0c로 넣으면 2바이트로 오프셋 12의 www.example.com을 가리킨다. 이름을 다시 17바이트 쓰는 것보다 15바이트를 줄인다. 이 압축 NAME 2바이트와 TYPE 2, CLASS 2, 4, RDLENGTH 2, 주소 4를 더하면 Answer 한 개는 16바이트다. 기본 조건의 응답 전체는 12+21+16=49바이트다.
  • 여기서 33·49는 메시지 자체의 크기다. 에 실으면 각각 8바이트를 추가하고, IP와 길이는 해당 캡슐화 조건으로 별도 계산한다.

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

  • 은 이름이 없다는 결과이므로 QNAME·QCLASS 문맥으로 캐시된다. 특정 타입 자료만 없는 는 QNAME·QTYPE·QCLASS 조합으로 다루므로 A 부재를 AAAA 부재로 곧바로 확대하지 않는다.
  • 가상 =900초, MINIMUM=300초이면 기본 음성 은 min(900,300)=300초다. 60초 뒤 같은 캐시 응답은 남은 약 240초를 기준으로 하며 새 응답처럼 300초를 다시 부여하지 않는다.
  • 권한 서버에 새 이름을 추가했는데 일부 재귀 서버가 여전히 이면 이전 음성 캐시가 남은 상황일 수 있다. 권한 응답과 재귀 응답의 ·을 구분해 비교한다.

06상세 노트 · 실습 자료

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

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

함께 보는 학습 자료

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

패킷 예제

RFC 1035 §4.1: 메시지 형식과 이름 압축

질문과 응답을 바이트 단위로 읽고 압축 포인터가 크기를 줄이는 방식을 계산한다.

읽으면서 확인할 것
  • §4.1.1 헤더 플래그와 Count
  • §4.1.3의 ·RDLENGTH·RDATA
  • §4.1.4 압축 오프셋의 기준점

공식 문서 · 표준

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