DNS 메시지·위임·캐시와 BIND 존 구성

01질의하는 서버와 답을 소유한 서버

• Resolver와 권한 서버DNS는 계층적인 이름 공간에 여러 종류의 정보를 연결한다. 호스트는 보통 재귀 resolver에 질의하고, resolver는 캐시를 사용하거나 필요한 권한 서버들을 따라가 답을 구한다.

  • 권한 서버는 자신이 담당하는 zone의 데이터를 제공한다.
  • 한 서버가 여러 역할을 할 수 있어도 그 역할을 같은 개념으로 합치지 않는다.
• 위임과 데이터 소유도메인은 이름 공간의 범위이고 zone은 운영 책임과 위임에 따라 관리되는 단위다. 부모 zone의 위임과 자식 zone의 권한 정보가 맞아야 한다.

  • 서버에 zone 파일을 만들었다는 사실만으로 외부 resolver가 그 서버를 찾아오는 것은 아니다.
  • 위임 경로와 접근 가능한 응답 지점을 함께 확인해야 한다.

02이름 트리·FQDN·도메인·존

• 이름 표기DNS 이름은 루트부터 이어지는 레이블의 계층이다. www.lab.example.의 마지막 점은 루트까지 명시한 절대 이름을 뜻한다.

  • zone 파일에서 끝의 점이 없으면 현재 $ORIGIN에 상대적인 이름으로 해석될 수 있다.
  • ns.lab.example을 끝 점 없이 적으면 의도하지 않게 ns.lab.example.lab.example.이 될 수 있는 이유다.
• 도메인과 존도메인은 특정 이름 아래의 트리 범위이고 zone은 권한을 관리하는 단위다. 자식 도메인을 다른 서버에 위임하면 부모 zone에는 위임용 NS와 필요한 glue 정보가 남고 자식 데이터는 자식 zone이 담당한다.

  • 부모의 NS가 자식 서버를 가리킨다고 해당 서버가 자동으로 zone 파일을 얻거나 생성하는 것은 아니다.
  • 서버의 권한 데이터와 부모의 위임이 서로 맞아야 완성된다.

03메시지와 Resource Record

• 메시지 네 영역DNS 메시지는 거래 ID와 flags, 각 영역 개수를 가진 헤더 뒤에 Question·Answer·Authority·Additional을 둔다. 질문은 이름·Type·Class로 표현하고 RR은 이름·Type·Class·TTL·데이터를 갖는다.

  • A와 AAAA는 주소, CNAME은 별칭, MX는 메일 교환 대상, NS는 권한 서버 정보를 표현한다.
  • DNS 이름 하나가 항상 IP 하나에 대응하는 것은 아니다.
• RR 필드TTL은 캐시 가능한 시간의 기준이며 임의로 영구 보관하라는 뜻이 아니다. 응답의 AA는 권한 응답 여부, TC는 잘림, RD·RA는 재귀 요청과 제공 여부를 해석할 때 사용한다.

  • ID가 같다는 이유만으로 무조건 같은 거래라고 단정하지 말고 주소·포트·질문·시간도 함께 본다.
  • DNSSEC 검증과 전송 암호화는 별도 기능이다.
• 헤더 비트·개수DNS 기본 헤더는 12바이트다. ID16비트 뒤에 QR·Opcode·AA·TC·RD·RA 등 flags와 응답 코드가 있고, Question·Answer·Authority·Additional의 개수를 각 16비트로 기록한다.

  • 질문의 QNAME은 레이블로 표현하며 QTYPE과 QCLASS가 따른다.
  • RR은 NAME·TYPE·CLASS·TTL·RDLENGTH·RDATA로 구성한다.
  • 이름 압축 포인터 때문에 패킷의 문자열을 단순 고정길이 텍스트로 읽을 수 없는 경우도 있다.

06캐시가 없는 이름의 재귀 조회 순서

• 캐시의 시작점유효한 답이나 위임이 캐시에 있으면 그 정보를 사용한다. 매 질의를 반드시 루트부터 시작하는 것은 아니다.
• 전송의 분기UDP 응답의 TC가 설정되면 TCP 재시도 등이 필요하다. 응답 크기·EDNS에 따라 교환이 달라지므로 UDP만 허용하는 정책으로 충분하지 않다.

1. Stub의 요청단말 stub resolver가 재귀 Resolver에 이름과 질의 종류를 보낸다. Resolver가 먼저 유효한 캐시를 확인한다.
2. 위임 단서 수집답이 없으면 루트·상위 도메인 서버에서 해당 이름을 책임지는 권한 서버의 단서를 얻는다.
3. 권한 서버 질의위임을 따라 최종 권한 서버에 필요한 레코드를 묻는다. 중간 위임 응답과 최종 데이터 응답을 구별한다.
4. 별칭 해결CNAME이면 목표 이름에 필요한 추가 조회를 수행할 수 있다. 단말에 반환할 결과를 조합한다.
5. 응답·캐시Resolver가 결과를 단말에 돌려주고 TTL 조건에 맞게 보관한다. 이후 같은 질의는 남은 캐시 수명을 활용할 수 있다.

07레코드 종류마다 데이터 형식이 다르다

• 주소·별칭·메일A는 IPv4, AAAA는 IPv6 주소다. CNAME은 다른 이름의 별칭이므로 목표 이름에 대한 추가 조회가 필요할 수 있다.

  • 일반적인 CNAME 소유 이름에는 다른 일반 데이터 RR을 함께 두지 않는다.
  • MX는 선호도 숫자와 메일 교환 서버 이름을 담고 NS는 권한 서버의 이름을 담는다.
  • 숫자 주소를 NS나 MX의 이름 자리에 그대로 넣는 설정과 구별한다.
• SOA·PTR·TXTSOA에는 primary 서버 이름, 담당자 mailbox 표현, serial, refresh, retry, expire, negative cache 관련 최소값이 들어간다. serial은 zone 버전 비교에 쓰므로 변경하면서 증가시켜야 secondary가 갱신을 판단할 수 있다.

  • YYYYMMDDnn은 사람이 읽기 쉬운 관례이지 프로토콜이 날짜를 강제하는 것은 아니다.
  • PTR은 역방향 이름에 연결되며 IPv4는 in-addr.arpa, IPv6는 ip6.arpa 트리를 사용한다.

08TTL·부정 캐시·응답 코드

• TTL·캐시권한 서버에서 A를 바꿔도 재귀 서버와 단말이 유효한 캐시를 갖고 있으면 이전 값을 계속 사용할 수 있다. 응답에서 보이는 TTL은 캐시가 남긴 잔여 시간일 수 있다.

  • 따라서 변경을 확인할 때 권한 서버의 현재 값과 재귀 서버의 캐시 값을 분리한다.
  • 캐시 삭제는 선택한 단말이나 서버의 캐시를 바꾸는 작업이지 인터넷 전체에 새 값을 강제하는 기능이 아니다.
• NXDOMAIN·NODATA·SERVFAILNXDOMAIN은 질문한 이름이 존재하지 않는다는 응답이다. 이름은 있지만 질문한 유형의 RR이 없으면 보통 NOERROR와 빈 Answer로 나타나는 NODATA다.

  • CNAME을 따라간 끝의 이름 부재도 구별해야 한다.
  • SERVFAIL은 처리 실패로 DNSSEC 검증 실패·권한 서버 접근 실패 등 여러 원인이 가능하고, timeout은 응답 자체를 받지 못한 관찰이다.
  • 부정 응답도 SOA 관련 조건에 따라 캐시되므로 레코드를 새로 만든 직후에도 부정 캐시가 영향을 줄 수 있다.

09UDP·TCP·EDNS가 필요한 이유

• UDP와 TCP전통적인 DNS는 UDP를 주로 사용하지만 TCP도 정상 전송 방식이다. UDP 응답에 TC가 설정되면 더 완전한 답을 얻기 위해 TCP 재시도가 필요할 수 있다.

  • 존 전송도 TCP를 사용한다.
  • UDP53만 허용하면 짧은 질문은 성공해도 큰 응답·전송에서는 실패하는 부분 장애가 생긴다.
• EDNSEDNS의 OPT 의사 RR은 UDP 수신 크기와 확장 정보를 표현한다. UDP 수신 크기를 크게 광고한다고 경로 MTU 문제가 없어지는 것은 아니다.

  • 조각화·중간 장비·방화벽 때문에 큰 UDP 응답이 사라질 수 있으며 TCP fallback의 존재가 중요하다.
  • DNS over TLS/HTTPS는 질의 전송의 기밀성과 채널 보호를 다루고 DNSSEC는 데이터 출처 인증·무결성을 다루므로 서로 대체 관계가 아니다.

10BIND 권한 서버의 역할과 접근 범위 설정

• 수신·질의 범위BIND는 named.conf의 listen-on·allow-query와 zone 선언으로 수신 주소·질의 범위·제공할 존을 설정한다. listen-on은 어느 로컬 주소에서 서비스를 받을지, allow-query는 누가 질의할 수 있는지를 뜻한다.

  • 둘 다 any로 열었다고 권한 서버·재귀 서버 역할이 안전하게 구분되는 것은 아니다.
  • 아래는 격리된 문서용 서버 192.0.2.53이 lab.example의 권한 응답만 제공하는 예다.
• 재귀·업데이트·전송recursion no는 이 예 서버가 임의 외부 이름에 대한 재귀 서비스를 제공하지 않게 한다. directory와 zone의 file 경로는 결합되어 실제 파일을 찾는다.

  • allow-update는 동적 업데이트 허용을 정하는 항목이며 secondary가 zone을 가져가도 되는지 정하는 allow-transfer와 다르다.

options {
    directory "/var/named";
    listen-on port 53 { 127.0.0.1; 192.0.2.53; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 192.0.2.0/24; };
    recursion no;
};
zone "lab.example" IN {
    type primary;
    file "lab.example.zone";
    allow-update { none; };
    allow-transfer { none; };
};

설명용 최소 권한 서버 구성. 기존 배포판 설정 전체를 덮어쓰는 명령이 아니며 type master는 구형 명칭이다.

11정방향 zone 파일의 한 줄씩 읽기

• Origin·SOA·NS아래에서 @는 현재 origin인 lab.example.을 뜻한다. SOA의 ns.lab.example.은 이 zone의 primary 이름이며 hostmaster.lab.example.은 mailbox의 @를 점으로 표현한 값이다.

  • NS와 A는 별개의 레코드다.
  • 이름이 ns인 A를 하나 만들었다고 그 레코드 자체가 NS가 되는 것은 아니다.
• CNAME·웹사이트 선택www의 CNAME은 app.lab.example.을 가리키며 app의 A가 최종 주소를 제공한다. 두 이름이 같은 웹 서버 주소로 해결되어도 실제 웹사이트 선택은 HTTP Host 또는 TLS SNI와 가상 호스트 설정에 달려 있다.

  • DNS가 응용의 DocumentRoot까지 지정하지는 않는다.
  • 예제의 ::1 AAAA를 일반 원격 서비스 이름에 그대로 남기면 클라이언트 자신의 루프백으로 연결하게 되므로 실제 의도와 맞는 주소만 등록해야 한다.

$ORIGIN lab.example.
$TTL 3600
@ IN SOA ns.lab.example. hostmaster.lab.example. (
    2026101201 ; serial
    3600       ; refresh
    900        ; retry
    604800     ; expire
    300        ; negative cache parameter
)
@    IN NS    ns.lab.example.
ns   IN A     192.0.2.53
app  IN A     192.0.2.80
www  IN CNAME app.lab.example.
mail IN A     192.0.2.25
@    IN MX 10 mail.lab.example.

공개 실서비스가 없는 예약 도메인·문서용 주소의 zone 예. 원문 오탈자와 서로 다른 origin 혼용을 바로잡았다.

12Primary·Secondary·전송·위임의 관계

• Primary·SecondarySecondary는 primary 등 허용된 서버에서 AXFR 전체 전송 또는 IXFR 증분 전송으로 zone 데이터를 얻어 권한 응답한다. 단순 캐시 서버나 ‘권한이 약한 서버’가 아니다.

  • SOA serial 변화, refresh와 retry, expire, NOTIFY 같은 기능이 데이터 갱신과 유효성에 연결된다.
  • 전송 권한을 제한하는 allow-transfer와 업데이트 권한을 정하는 allow-update를 분리해야 한다.
• 선호·대체 DNS클라이언트 설정의 선호 DNS·대체 DNS는 resolver 선택 정책이다. DNS zone의 primary·secondary 역할과 같지 않다.

  • 클라이언트 OS가 어느 순서로 질의하고 장애 판단 후 어떻게 바꾸는지는 구현에 따라 달라진다.
  • 선호 서버가 정상적인 NXDOMAIN을 주었는데 다른 서버가 다른 답을 줄 것이라고 기대하는 구성은 일관성을 해친다.
  • 같은 zone의 권한 서버들은 계획된 갱신 과정 외에는 같은 데이터로 응답해야 한다.

13DNSSEC의 서명과 검증

• DNSSEC의 보호DNSSEC는 RRset에 대한 RRSIG와 DNSKEY, 부모가 자식 키를 연결하는 DS 등을 통해 데이터 출처와 무결성을 검증한다. 서명된 부정 응답에는 NSEC·NSEC3 등이 관련된다.

  • DNS 응답 내용을 암호문으로 만드는 기술이 아니므로 패킷에서 이름과 레코드가 평문으로 보인다는 이유만으로 DNSSEC가 동작하지 않는다고 판단할 수 없다.
• 검증과 전송 암호화검증 resolver 또는 검증 기능을 가진 종단은 신뢰 앵커에서 위임 관계를 따라 검증한다. 검증 기능을 갖춘 resolver와 종단은 모두 검증 주체가 될 수 있다.

  • 서명 만료·잘못된 DS·시간 문제는 데이터가 존재해도 검증 SERVFAIL을 만들 수 있다.
  • 전송을 암호화하는 DoT·DoH와 함께 사용할 수 있으나 서명 검증과 전송 암호화의 역할은 서로 다르다.

14구문 검사와 응답 판독을 분리하기

• 구문 검사named-checkconf는 설정 문법을, named-checkzone은 특정 zone 파일의 구조를 검사한다. 검사를 통과했다고 네트워크 접근·위임·재귀 정책·서비스 리스닝까지 모두 검증된 것은 아니다.

  • 질의 도구에서 서버를 명시해 권한 응답을 먼저 보고 클라이언트의 일반 resolver를 통한 응답과 비교한다.
• 응답 판독dig 출력에서 status, flags의 aa, Answer 수, 실제 RR과 TTL을 함께 읽는다. +norecurse를 사용한 권한 서버 직접 질의는 재귀 결과와 섞이지 않게 해 준다.

  • +tcp 성공과 UDP 실패의 차이는 응답 전송 경로의 단서다.
  • DNS가 성공한 뒤 HTTP Host를 맞춘 요청까지 확인해야 예제의 다중 가상 호스트 실습을 끝까지 재현할 수 있다.

named-checkconf /etc/named.conf
named-checkzone lab.example /var/named/lab.example.zone
dig @192.0.2.53 www.lab.example A +norecurse
dig @192.0.2.53 lab.example SOA +norecurse
dig @192.0.2.53 www.lab.example A +tcp

설명용 응답 일부:
status: NOERROR, flags: qr aa
www.lab.example. 3600 IN CNAME app.lab.example.
app.lab.example. 3600 IN A 192.0.2.80

검사·조회 명령과 합성 응답. 실제 서비스 설치나 재시작을 실행한 기록이 아니다.