DNS Lab.

BIND의 DNS질의(query) 로그, 어떻게 구성되어 있나?

승홍 — Fri, 24 Sep 2021 08:10:11 +0900

BIND DNS 네임서버는 수신된 DNS 질의내역을 로그 파일로 기록할 수 있습니다.

이 포스팅은 현 시점의 BIND 버전(9.16)을 기준으로, 질의 로그에 실려있는 정보 항목을 될 수 있는 한 상세하게 보여주고자 합니다. 향후 BIDN 버전이 상향되고 또 DNS 관련 질의속성 관련 표준기능이 추가되면 변동될 수도 있습니다.

이번 포스팅의 성격 상, 질의 로그의 각 항목에 대한 개괄적 설명에만 초점을 둡니다. 각 개별 항목과 관련된 DNS 기능 및 동작에 대한 세부 사항은 시간이 될 때 각 사항에 중점을 둔 포스팅에서 다루고자 합니다.

named.conf의 질의로그 기록 설정

다음은 질의(query) 로그 기록 설정의 한 예시입니다. named.conf 파일에 설정합니다.

logging {

  channel query_log    {
    file "var/log/queries.log" versions 10 size 20m;
    severity        dynamic;
    print-severity  yes;
    print-time      yes;
    print-category  yes;
  };

  category queries    { query_log;    };

};

이 설정은 카테고리 queries에 속하는 로그 메시지를 query_log 채널(channel)로 보내 처리하는 설정입니다.
카테고리 queries는 BIND에서 정한 DNS질의 로그의 카테고리 이름입니다.
이에 반해 채널(channel) 설정은 이 로그를 어떻게 처리할 것인지를 사용자가 직접 지정하는 설정입니다. 이 사례에서는 채널명을 query_log로 정하고, 이 채널로 처리되는 로그 메시지는 로그 파일 var/log/queries.log로 저장하도록 설정합니다.
로그 처리와 관련된 세부 설정 사항은 BIND 매뉴얼의 4.2.9. logging Statement Grammar 장을 참고하실 수 있습니다.

BIND의 DNS 질의로그 형태

단순한 질의형태로 tistory.com의 A 레코드 질의를 했습니다. 이 경우 BIND의 로그 메시지는 어떤 형태로 기록되는지 확인해 보기로 하겠습니다. (여기의 사례는 로컬 시스템에 캐시DNS 서버를 구동하고 로컬 시스템에서 127.0.0.1 주소로 DNS 질의하는 방식을 사용했습니다. 로그가 어떻게 기록되는지 살펴보는 것만 필요하기 때문입니다.)

$ dig @127.0.0.1 tistory.com

; <<>> DiG 9.16.21 <<>> @127.0.0.1 tistory.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63861
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0e507df1a023097a01000000614afce02f7eb10a2ef04514 (good)
;; QUESTION SECTION:
;tistory.com.                   IN      A

;; ANSWER SECTION:
tistory.com.            600     IN      A       121.53.105.234

;; Query time: 2137 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 22 18:52:32 KST 2021
;; MSG SIZE  rcvd: 84

$

이 경우에 대한 DNS 질의로그는 다음과 같은 형태로 기록됩니다.

22-Sep-2021 18:52:30.530 queries: info: client @0x7f976003c418 127.0.0.1#41052 (tistory.com): query: tistory.com IN A +E(0)K (127.0.0.1)

앞부분의 2개 필드 22-Sep-2021 18:52:30.530 는 질의시각입니다.

BIND는 로그 카테고리별 특유한 헤더 정보와 각 항목의 상세부분으로 구분되어 있습니다. 질의로그도 헤더부분과 질의내용 부분으로 구분하여 볼 수 있습니다.

`queries` 로그 헤더부분

다음은 로그 카테고리 queries 경우에 기록하는 헤더 부분입니다.

queries: info: client @0x7f976003c418 127.0.0.1#41052 (tistory.com):

queries는 로그 카테고리 이름입니다. info는 severity 값입니다.
client @0x7f976003c418는 질의가 유입될 때 BIND 내부에서 이 질의를 처리하는 데 사용된 client 구조체의 메모리 주소값(pointer 값) 입니다. client 구조체는 질의마다 새로 생성/소멸되지는 않고 질의가 응답처리 완료되면 초기화 하여 보존하며 BIND는 이전에 사용했던 clinet 구조체를 임의로 선택하여 재사용 합니다.
127.0.0.1#41052는 이 질의를 한 호스트의 소스 IP주소와 소스 port 번호입니다. 이 경우는 127.0.0.1 주소에서 41052 포트번호를 사용해서 질의한 경우에 해당합니다.
(tistory.com)는 질의이름(query name)입니다.

여기까지가 카테고리 queries에서 기록하는 로그 메시지의 헤더에 해당합니다.

`queries` 로그의 DNS 질의내용 부분

질의의 각 질의내용은 그 다음 부분에 아래와 같은 형태로 기록됩니다.

query: tistory.com IN A +E(0)K (127.0.0.1)

질의도메인, 질의클래스, 질의타입 내용은 tistory.com IN A 입니다.
+E(0)K은 질의속성을 축약하여 출력한 필드입니다.
이 경우는 리커시브(recursive) 질의 +이며, EDNS Version 0 옵션(OPT) 레코드를 사용한 질의 E(0) 이고, DNS Cookie 값 중 Client Cookie를 설정한 질의 K 입니다.
여기에 기록된 질의속성은 dig 유틸리티가 질의시 별다른 옵션 설정이 없으면 default로 설정하는 질의속성입니다.
마지막으로 (127.0.0.1)는 질의패킷의 착신주소 즉, 질의대상 네임서버 주소 입니다.

`queries` 로그의 DNS 질의속성 축약표시, 상세사항

질의속성 필드 +E(0)K 부분은 질의방식에 따라 상당히 다양한 형태로 표시될 수 있습니다.
다음은 질의속성 필드에 설정될 수 있는 모든 정보 항목을 표시되는 순서에 따라 정리한 것입니다.

표시항목	표시값	개요
질의유형	+/-	+ : recursive 질의 경우(RD 플래그 세팅 질의 경우), - : iterative 질의 경우 (RD 플래그 클리어 질의 경우)
TSIG 서명 여부	S/	S : TSIG 서명된 질의 경우, 그렇지 않은 경우 표시 생략
EDNS 사용 여부	E(0)/	E(0) : OPT 레코드, EDNS version 0 사용 질의 경우, 그렇지 않은 경우 표시 생략
TCP/UDP 질의	T/	T : TCP 사용 질의 경우, UDP 질의 경우는 표시 생략
DNSSEC 질의 여부	D/	D : DNSSEC 질의 DO(DNSSEC OK) 플래그 세팅 질의 경우, 그렇지 않은 경우 표시 생략
DNSSEC CD 플래그 여부	C/	C : DNSSEC CD(Check Disable) 플래그 세팅 질의 경우, 그렇지 않은 경우 표시 생략
DNS Cookie	K/V/	K : Client Cookie만 설정한 질의 경우, V : Client Cookie와 Server Cookie 모두 설정한 질의 경우, 그렇지 않고 DNS Cookie 설정이 없는 질의 경우 표시 생략

이에 추가하여 질의속성 필드는 아니지만 부가되어 표시될 수 있는 정보가 하나 더 있습니다. 이 정보는 로그 라인의 맨 끝 필드로 표시될 수 있습니다.

표시항목	표시값	개요
EDNS Client Subnet 설정 여부	[ECS subnet]/	[ECS subnet] : EDNS Client Subnet 정보 설정 질의 경우, 그렇지 않을 경우 표시 생략

표시가능한 모든 정보가 반영된 질의로그 경우

BIND 질의로그에 표시 가능한 정보 모두를 표시하도록 하려면 아래와 같은 DNS 질의를 사용할 수 있습니다.

$ dig -y qtest.:ugGBYPwm4MwukpuOBx8FLQ== @127.0.0.1 dnssec.tistory.com A +rec +tcp +dnssec +cd +cookie +subnet=127.0.0.0/8

-y qtest.:ugGBYPwm4MwukpuOBx8FLQ== 옵션은 DNS 질의에 TSIG 인증을 적용하는 옵션입니다. TSIG 사용 서명된 DNS 질의를 하고 네임서버는 이 DNS 질의를 보안인증하고 응답 처리합니다. TSIG 서명 여부에 관련된 표시 S를 로그에 나타나도록 하기 위함 입니다. (TSIG 키 이름은 qtest. 이고, TSIG 알고리듬은 default 값인 HMAC-MD5, TSIG 비밀키의 base64 인코딩 표현은 'ugGBYPwm4MwukpuOBx8FLQ==' 입니다.)
+rec 옵션은 recursive 질의를 위한 옵션입니다. 로그에는 + 표시로 반영될 것입니다.
+tcp는 DNS 질의에 UDP 대신 TCP를 사용하도록 하는 옵션입니다. 로그에는 T로 표시됩니다.
+dnssec은 DNSSEC 질의응답 옵션입니다. DO(DNSSEC OK) 플래그를 세팅하여 질의하도록 합니다. 로그에는 D로 표시됩니다.
+cd는 DNSSEC CD(Check Disable) 플래그를 세팅하여 질의하도록 합니다. 로그에는 C로 표시됩니다.
+cookie는 DNS Cookie 메커니즘을 사용하여 질의하도록 합니다. 이때 dig은 자신의 Client Cookie 값을 산출 설정한 DNS 질의를 하게 됩니다. 로그에는 K 표시로 반영됩니다.
+subnet=127.0.0.0/8은 DNS Client Subnet 정보를 설정하는 옵션입니다. 로그에는 EDNS Client Subnet 정보가 반영되어 ECS 127.0.0.0/8/8의 정보가 표시됩니다.

아래는 dig을 사용한 질의와 그 결과입니다.

$ dig -y qtest.:ugGBYPwm4MwukpuOBx8FLQ== @127.0.0.1 dnssec.tistory.com A +rec +tcp +dnssec +cd +cookie +subnet=127.0.0.0/8

; <<>> DiG 9.16.21 <<>> -y qtest. @127.0.0.1 dnssec.tistory.com A +rec +tcp +dnssec +cd +cookie +subnet=127.0.0.0/8
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3760
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: a7822d2c60db23df01000000614afd15afb40ee79d948012 (good)
; CLIENT-SUBNET: 127.0.0.0/8/0
;; QUESTION SECTION:
;dnssec.tistory.com.            IN      A

;; ANSWER SECTION:
dnssec.tistory.com.     3600    IN      CNAME   wildcard-tistory-fz0x1pwf.kgslb.com.
wildcard-tistory-fz0x1pwf.kgslb.com. 30 IN A    211.231.99.250

;; TSIG PSEUDOSECTION:
qtest.                  0       ANY     TSIG    hmac-md5.sig-alg.reg.int. 1632304405 300 16 H6naUgh/rF8So3DgaaOIOQ== 3760 NOERROR 0

;; Query time: 253 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 22 18:53:25 KST 2021
;; MSG SIZE  rcvd: 224

$

질의 로그 파일에는 아래와 같은 내용으로 기록이 남게 됩니다.

22-Sep-2021 18:53:25.564 queries: info: client @0x7f9768a5f218 127.0.0.1#52047/key qtest (dnssec.tistory.com): query: dnssec.tistory.com IN A +SE(0)TDCK (127.0.0.1) [ECS 127.0.0.0/8/0]

이 로그 메시지를 구성요소에 따라 3개 라인으로 분리하면 다음과 같습니다.

22-Sep-2021 18:53:25.564 
queries: info: client @0x7f9768a5f218 127.0.0.1#52047/key qtest (dnssec.tistory.com): 
query: dnssec.tistory.com IN A +SE(0)TDCK (127.0.0.1) [ECS 127.0.0.0/8/0]

첫번째 라인은 로그 시각에 해당하는 첫 2개 필드입니다. 이 로그시각은 모든 로그에서 동일한 형태를 갖습니다.

2번째 라인은 queries 로그의 헤더부분입니다.
이번 경우에는 기본 질의 경우와 달라진 부분이 하나 있습니다. 127.0.0.1#52047/key qtest 에서 /key qtest 부분입니다. 이것은 질의에 TSIG 서명이 사용될 때만 표시되는 정보입니다. key는 TSIG으로 서명됨을 의미하고, qtest는 TSIG 서명키의 이름을 표시합니다. TSIG 서명키로 서명된 질의에 대해 서명을 검사한 후 인증에 문제가 없는 경우에 이렇게 표시됩니다.
나머지 부분은 이전 기본질의 경우와 동일합니다.

3번째 라인은 질의내용 부분입니다.
여기서 질의속성은 +SE(0)TDCK 으로 표시되었습니다. 질의한 의도에 맞게, 그리고 질의옵션에 맞게 각각 표시되어 있는 것을 알 수 있습니다.
3번째 라인 맨 끝 항목으로 [ECS 127.0.0.0/8/0]가 표시되어 있습니다. EDNS Client Subnet 옵션 정보가 로그에 기록된 사항입니다.

질의속성 +SE(0)TDCK은 모든 경우를 표시한 사례는 아닙니다. +SE(0)TDCV인 경우도 있을 수 있습니다. 즉, K 대신 V가 표시된 경우가 있을 수 있습니다.

V가 표시되는 경우는 질의에 DNS Cookie 정보로 Clinet Cookie 정보와 Server Cookie 정보를 모두 설정하는 경우입니다.

DNS Cookie는 처음에 질의하는 호스트가 자신의 Clinet Cookie 데이터 8바이트를 설정하여 질의하면, 네임서버는 DNS응답에 Clinet Cookie 8바이트 데이터에 추가하여 네임서버가 생성한 Server Cookie 16바이트 데이터로 응답합니다. 그래서 dig을 먼저 질의한 후 네임서버가 응답한 Cookie 데이터를 사용하여 다시 질의하면 Client Cookie + Server Cookie 모두를 사용한 질의를 할 수 있습니다.

(참고) DNS Cookies는 소스 IP주소와 소스 port 번호를 spoofing한 공격자의 DNS 질의/응답 패킷을 검출할 수 있는 수단으로 DNS Client Cookie와 DNS Server Cookie 정보를 상호교환 할 수 있도록 하는 메커니즘입니다. 비록 완벽한 수준의 보안인증 수단은 아니지만, 실용적인 측면에서는 DNS응답 spoofing 공격 시도를 어느 정도 감지할 수 있게 하여 공격시도를 방어할 수 있는 수단을 캐시DNS 서버와 권한DNS 서버에 제공합니다. DDoS 공격 시도와 DNS 캐시 포이즈닝 공격 시도에 자동으로 대응할 수 있게 합니다.

$ dig -y qtest.:ugGBYPwm4MwukpuOBx8FLQ== @127.0.0.1 dnssec.tistory.com A +rec +tcp +dnssec +cd +cookie=a7822d2c60db23df01000000614afd15afb40ee79d948012 +subnet=127.0.0.0/8

; <<>> DiG 9.16.21 <<>> -y qtest. @127.0.0.1 dnssec.tistory.com A +rec +tcp +dnssec +cd +cookie=a7822d2c60db23df01000000614afd15afb40ee79d948012 +subnet=127.0.0.0/8
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14517
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: a7822d2c60db23df01000000614afd5919e6e051f6a5b280 (good)
; CLIENT-SUBNET: 127.0.0.0/8/0
;; QUESTION SECTION:
;dnssec.tistory.com.            IN      A

;; ANSWER SECTION:
dnssec.tistory.com.     3532    IN      CNAME   wildcard-tistory-fz0x1pwf.kgslb.com.
wildcard-tistory-fz0x1pwf.kgslb.com. 30 IN A    211.249.222.33

;; TSIG PSEUDOSECTION:
qtest.                  0       ANY     TSIG    hmac-md5.sig-alg.reg.int. 1632304473 300 16 9cBHGzJItagXFvfcudq8xg== 14517 NOERROR 0

;; Query time: 145 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 22 18:54:33 KST 2021
;; MSG SIZE  rcvd: 224

$

여기에서 +cookie 옵션에 설정된 값은 이전 질의에 대한 응답 중 ; COOKIE: a7822d2c60db23df01000000614afd15afb40ee79d948012 (good)에서 얻은 Client Cookie + Server Cookie 값을 사용하였습니다.

이 질의에 대한 로그는 다음과 같습니다.

22-Sep-2021 18:54:33.271 queries: info: client @0x7f9768a5e4d8 127.0.0.1#52919/key qtest (dnssec.tistory.com): query: dnssec.tistory.com IN A +SE(0)TDCV (127.0.0.1) [ECS 127.0.0.0/8/0]

로그에 보이는 바와 같이, 질의속성 필드 표시가 +SE(0)TDCV로 변경되었습니다.

DNS 질의로그 정보의 활용

DNS 질의로그는 다양한 목적으로 활용할 수 있습니다.
특히 보안침해 시도를 검출하는 데에 질의로그 집계자료를 활용할 수 있습니다.

BIND 질의로그는 유용하지만, 한계점도 있습니다. DNS응답 정보는 질의로그에 기록되지 않습니다. 그래서 어떤 질의가 어떻게 응답 처리되었는지는 사실상 확인할 수 없습니다.

BIND 로그 카테고리 중에는 query-errors 가 있습니다. 이 카테고리는 DNS 응답 중 에러응답 경우에 대한 로그기능을 제공합니다. query-errors 로그 카테고리를 추가로 사용하여 에러응답 경우에 대한 로그를 기록한다면 네임서버 질의응답 상황 관리에 도움이 될 수 있습니다.

참고 할 수 있는 자료

Wikipedia TSIG
Wikipedia EDNS
Wikipedia DNSSEC
RFC DNS Cookies, RFC7873, Interoperable DNS Server Cookies, RFC9018
Wikipedia EDNS Client Subnet
GitHub bind9 query.c 소스 중 질의로그 기록 log_query() 함수 부분 (이 URL은 향후 버전이 달라지면 위치가 달라질 수 있음)

참고 : EDNS Client Subnet

EDNS Client Subnet 기능은 질의하는 호스트의 IP주소(Prefix) 정보를 DNS질의에 설정하여 권한DNS로 질의합니다. 이때 권한DNS는 호스트가 네트워크의 어느 위치에 있는지 파악, 가장 근접한 서버의 접속정보를 응답해 주는 것이 가능하게 됩니다. 즉 권한DNS 서버가 질의한 사용자 호스트의 네트워크 위치를 손쉽게 파악하고, 사용자 호스트에 근접한 클라우드 서버 또는 CDN 서버의 IP주소를 선택하여 DNS응답 레코드로 응답해 줄 수 있게 합니다. 클라우드/CDN 서비스 경우에 상당히 유용할 수 있는 기능입니다.

하지만, EDNS Client Subnet은 질의호스트의 IP주소 정보(정확히는 Prefix 정보)를 권한DNS 서버에 알려주는 메커니즘으로써, 이는 사생활 보호(privacy 보호)라는 측면에서 보안 이슈가 있습니다. 이에 따라 인터넷표준화기구 IETF는 EDNS Client Subnet 기능을 모든 네임서버가 구현해야 하는 필수사항이 아닌 참고사항(Informational)으로 처리하였습니다.
하지만 이 기능을 절실히 필요로 하는 Google Public DNS와 같은 Public DNS 서비스 업체는 이 기능을 구현, 서비스에 적용하여 현재 사용하고 있습니다. 그래서 Google Public DNS를 사용하는 사용자 호스트 경우, 사용자 호스트가 위치한 IP주소 정보(prefix 정보)가 질의하는 도메인이 있는 권한DNS 서버로 전달되고 있습니다. 이 경우 사용자 PC가 그렇게 질의하는 것이 아니라 Google DNS 서버가 사용자의 DNS질의 메시지 패킷의 소스 IP주소 정보를 EDNS Client Subnet에 설정하여 권한DNS 서버에게 질의하는 방식입니다.
권한DNS 서버 관리자 입장에서는, BIND 로그(queries)에서 EDNS Client Subnet 정보가 포함된 질의로그를 발견할 수도 있습니다. 이러한 질의들은 Google Public DNS와 같은 Public DNS 서비스의 캐시DNS 서버가 질의하는 경우일 가능성이 높습니다.

인터넷표준화기구 IETF는 향후 EDNS Client Subnet 기능에 대해 사생활(privacy) 보호를 고려하여 보다 안전한 대체기능의 표준화를 모색하고 있다고 합니다.

BIND DNS 네임서버 경우, EDNS Client Subnet 정보를 기반으로 소재지 기반 DNS 응답처리를 지원하는 geoip-use-ecs 옵션을 제공하였으나, 지금은 이 옵션을 지원하지 않는 상태입니다. BIND는 MaxMind GeoIP2를 지원하는 기능을 구현하고 있습니다. 이를 활용하여 DNS Client Subnet 설정한 질의에 대해서는 MaxMind GeoIP2 DB를 사용, 사용자 호스트 소재 기반으로 DNS응답을 처리 가능하도록 하려 했으나 현재는 인터넷표준화기구 IETF의 결정에 따라 이를 지원하지 않고 유보한 상태인 것으로 보입니다. (이는 BIND 9.16 버전을 기준했을 때 그렇습니다.) 다만 MaxMind GeoIP2 지원 기능 자체는 현 시점에도 지원하고 있는 기능으로 질의 호스트 소재지 정보 기반으로 ACL 적용, DNS질의 호스트/서버 소재지에 따라 DNS 질의의 분류/처리 동작이 가능합니다.

DNS 메시지 압축 (Message Compression)

승홍 — Sun, 12 Jan 2020 17:05:45 +0900

'80년대 초 DNS를 개발하던 당시, 인터넷 백본망 용량은 1 Mbps에 미치지 못했습니다. 지금 한국의 경우, 집에서 사용하고 있는 인터넷 회선용량도 아마 대부분 10 Mbps 이상일 것입니다. 이에 비하면, '80년대 인터넷 백본망 용량은 상당히 열악한 수준이었다고 할 수 있습니다. 하지만 당시 인터넷은 비디오나 사진 이미지를 쓰지 않고 주로 텍스트 기반의 서비스, 즉 E-mail이나 뉴스그룹 등이 대부분이어서 인터넷 백본용량은 별 문제가 되지 않았을 것입니다. 월드 와이드 웹(WWW)이 '90년대에 등장하면서 이미지 데이터와 비디오 데이터에 대한 수요가 급증하기 시작합니다.

'80년 초반 당시 인터넷은 X.25라는 56 Kbps 데이터 전용회선 다수를 묶어 인터넷 백본망을 구성하고 있었습니다. 10 Kbps ~ 100 Kbps 사이의 백본망 용량을 가지고 있었습니다.

아래 그래프는 인터넷 백본용량의 변천사를 보여줍니다.

그래프) 인터넷 백본망 용량 변천사

< 그래프 이미지 원본 URL = http://www.singularity.com/images/charts/InetrnetBackboneBandwidth.jpg >

'80년대 당시, 인터넷 백본망에 흐르는 트래픽 중에서 DNS 트래픽이 약 25%를 차지하고 있었다고 합니다. DNS의 인터넷 트래픽 점유율이 엄청납니다. 이유는 DNS 질의응답 메시지 사이즈가 커서 그런 것이 아니라, 당시 인터넷 백본 회선 용량이 상대적으로 너무 작아서 그렇습니다. 지금은 인터넷 백본회선에서 DNS 트래픽이 차지하는 비중이 아마 거의 무시할 수준일 것입니다.

DNS 표준 설계 당시, '80년대 초의 인터넷 백본망 회선 용량을 고려하면서 DNS 메시지 사이즈를 최소화 하기 위한 고민을 합니다. 그 결과 나온 것이 DNS 메시지 압축(DNS Message Compression) 입니다.

지금도 DNS 표준을 구현한 DNS 네임서버는 DNS 메시지 압축(DNS Message Compression)을 준수하고 있습니다. 한국과 같이 초고속 인터넷 환경이 잘 구성된 국가의 경우에는 굳이 이러한 방식을 사용하지 않아도 문제는 없을 것입니다. 하지만 개발도상국이나 심지어 미국의 일부 시골 지역에서는 아직도 28.8 Kbps, 33.6 Kbps 등의 회선속도를 갖는 아날로그 전화선 모뎀 회선으로 인터넷에 접속하는 경우가 있습니다. 미국 온라인서비스 사업자 AOL은 '12년 연간보고서에서 약 300만 미국 이용자로부터 아날로그 전화선 모뎀 회선 사용료로 약 7억 달러의 수입을 거두었다고 합니다. DNS는 어떤 환경에서도 누구나 보편적으로 이용될 수 있어야 합니다. 그래서 DNS 메시지 압축(DNS Message Compression) 방식은 저속 인터넷 회선 사용자에게는 아직도 유용한 역할을 하고 있다고 볼 수 있습니다.

DNS 응답 메시지의 DNS 메시지 압축(DNS Message Compression) 구체적 모습

dnssec.tistory.com의 A 질의에 대한 응답 DNS 메시지에서 DNS 메시지 압축(DNS Message Compression)가 사용된 모습을 보고자 합니다.

DNS 질의응답 패킷을 tshark으로 캡처하면서, dnssec.tistory.com의 A 질의를 실행하였습니다.

$ dig dnssec.tistory.com A

그 결과 아래와 같은 DNS 응답 메시지를 얻었습니다.

$ dig dnssec.tistory.com a

; <<>> DiG 9.11.13 <<>> dnssec.tistory.com a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40436
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;dnssec.tistory.com.            IN      A

;; ANSWER SECTION:
dnssec.tistory.com.     3600    IN      A       211.231.99.250

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Jan 12 04:23:32 UTC 2020
;; MSG SIZE  rcvd: 63

$

위와 같이 Answer 섹션에 질의한 IP 주소가 응답되었음을 확인했습니다.

캡쳐한 DNS 응답 패킷 중에서 DNS 응답 메시지 부분입니다.

Domain Name System (response)
    Transaction ID: 0xc624
    Flags: 0x8180 Standard query response, No error
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .0.. .... .... = Authoritative: Server is not an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... 1... .... = Recursion available: Server can do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... ...0 .... = Non-authenticated data: Unacceptable
        .... .... .... 0000 = Reply code: No error (0)
    Questions: 1
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 0
    Queries
        dnssec.tistory.com: type A, class IN
            Name: dnssec.tistory.com
            [Name Length: 18]
            [Label Count: 3]
            Type: A (Host Address) (1)
            Class: IN (0x0001)
    Answers
        dnssec.tistory.com: type A, class IN, addr 211.231.99.250
            Name: dnssec.tistory.com
            Type: A (Host Address) (1)
            Class: IN (0x0001)
            Time to live: 3600
            Data length: 4
            Address: 211.231.99.250
    [Request In: 2]
    [Time: 0.011265127 seconds]

0000                                                    
0010                                                    
0020                                      c6 24 81 80               .$..
0030  00 01 00 01 00 00 00 00 06 64 6e 73 73 65 63 07   .........dnssec.
0040  74 69 73 74 6f 72 79 03 63 6f 6d 00 00 01 00 01   tistory.com.....
0050  c0 0c 00 01 00 01 00 00 0e 10 00 04 d3 e7 63 fa   ..............c.

DNS 응답 메시지 부분만 살펴 보면 되기에, 바이너리 데이터 부분에서 DNS 응답 메시지 부분만 재정렬하여 다시 편집했습니다.

Domain Name System (response)
    Transaction ID: 0xc624
    Flags: 0x8180 Standard query response, No error
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .0.. .... .... = Authoritative: Server is not an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... 1... .... = Recursion available: Server can do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... ...0 .... = Non-authenticated data: Unacceptable
        .... .... .... 0000 = Reply code: No error (0)
    Questions: 1
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 0
    Queries
        dnssec.tistory.com: type A, class IN
            Name: dnssec.tistory.com
            [Name Length: 18]
            [Label Count: 3]
            Type: A (Host Address) (1)
            Class: IN (0x0001)
    Answers
        dnssec.tistory.com: type A, class IN, addr 211.231.99.250
            Name: dnssec.tistory.com
            Type: A (Host Address) (1)
            Class: IN (0x0001)
            Time to live: 3600
            Data length: 4
            Address: 211.231.99.250
    [Request In: 2]
    [Time: 0.011265127 seconds]

[DNS Message]                                          
0000  c6 24 81 80 00 01 00 01 00 00 00 00 06 64 6e 73   .$...........dns
0010  73 65 63 07 74 69 73 74 6f 72 79 03 63 6f 6d 00   sec.tistory.com.
0020  00 01 00 01 c0 0c 00 01 00 01 00 00 0e 10 00 04   ................
0030  d3 e7 63 fa                                       ..c.

여기서 바이너리 데이터 부분에서 dnssec.tistory.com이 하나만 보입니다. 왜 그럴까요? 질의이름 dnssec.tistory.com은 Question 섹션에 하나, 그리고 Answer 섹션에 하나 있어야 하는데, 오직 하나만 보입니다. 이는 DNS 메시지 압축(DNS Message Compression)이 적용된 DNS 응답이기 때문입니다.

만일, DNS 메시지 압축(DNS Message Compression)이 적용되지 않았다면, DNS 응답 메시지의 바이너리 데이터는 아래와 같은 모습이 되어야 합니다. 아래와 같이 Question 섹션과 Answer Section에 각각 하나씩, 2개의 dnssec.tistory.com 이름이 보여야 할 것입니다.

[DNS Message]                                          
0000  c6 24 81 80 00 01 00 01 00 00 00 00 06 64 6e 73   .$...........dns
0010  73 65 63 07 74 69 73 74 6f 72 79 03 63 6f 6d 00   sec.tistory.com.
0020  00 01 00 01 06 64 6e 73 73 65 63 07 74 69 73 74   .....dnssec.tist
0030  6f 72 79 03 63 6f 6d 00 00 01 00 01 00 00 0e 10   ory.com.........
0040  00 04 d3 e7 63 fa                                 ....c.

DNS 메시지 압축(DNS Message Compression) 이라는 용어는 DNS 메시지를 압축한다는 의미를 담고 있습니다. 하지만 실질적으로 압축할 대상은 도메인 이름입니다. DNS 레코드 구성요소를 볼 때 Name|Type|Class|TTL|RDataLength|RData 중에서 데이터 길이가 긴 요소는 Name 입니다. 길이가 가변적이며 문자열로 인해 다른 요소에 비해 길이가 깁니다. RData 요소에 도메인 이름이 쓰이는 경우도 있습니다. DNS 레코드 타입 중 NS 타입, MX 타입, CNAME 타입 등 도메인 이름을 그 데이터로 갖는 RData가 있습니다. 만일 도메인 이름을 효과적으로 축약, 압축하여 그 길이를 줄일 수 있다면 DNS 메시지를 줄이는데 상당한 효과를 볼 수 있을 것입니다.

DNS 메시지 압축(DNS Message Compression)은 도메인 이름의 레이블에서 레이블 종류(Label Type) 값이 0x11인 경우 DNS 메시지 어디엔가 있는 중복된 도메인 이름 부분 위치를 표시하는 Offset 값을 사용하여 중복된 도메인 이름으로 대체함으로써 DNS 메시지 사이즈를 압축하는 방법을 사용합니다. "레이블 종류(Label Type)"에 대한 이야기는 "도메인 이름 데이터 포맷, 레이블, 그리고 FQDN" 포스팅을 참고하시기 바랍니다.

그림) Label Type = 0b11(0xC) 경우, 레이블 Offset 포맷 개념도

이것이 사용된 구체적 모습을 살펴 보겠습니다.

위 DNS 응답 메시지 중에서 DNS 부분만 보겠습니다.

[DNS Message]                                          
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
      -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000  c6 24 81 80 00 01 00 01 00 00 00 00 06 64 6e 73   .$...........dns
0010  73 65 63 07 74 69 73 74 6f 72 79 03 63 6f 6d 00   sec.tistory.com.
0020  00 01 00 01 c0 0c 00 01 00 01 00 00 0e 10 00 04   ................
0030  d3 e7 63 fa                                       ..c.

DNS 메시지의 첫 바이트를 DNS[0x00]이라 한다면, Question 섹션의 질의대상 도메인 이름은 DNS[0x0C] 부터 입니다.

DNS[0x0C:0x1F] 영역의 데이터는 도메인 이름을 설정한 부분으로써 0x06|dnssec|0x07|tistory|0x03|com|0x00 입니다.
Question 섹션의 질의타입 필드는 DNS[0x20:0x21] 이고, 그 값은 0x0001 로써 A 타입(1) 입니다.
Question 섹션의 질의 클래스 필드는 DNS[0x22:0x23] 이고, 그 값은 0x0001 로써 IN 클래스(1) 입니다.
Question 섹션 바로 다음부터 Answer 섹션이 시작됩니다. Answer 섹션은 이 DNS 응답 메시지 경우, DNS[0x24] 지점부터 시작합니다.

Answer 섹션의 도메인 이름의 첫 번째 레이블의 Lable Type|Label String Length 필드 값은 0xc0 입니다. Label Type 2 bit 필드의 값이 0b11 입니다. 이 경우는 압축된 도메인 이름을 사용하는 특수한 경우에 해당합니다. 이 경우, 레이블은 2 바이트의 고정된 길이를 가지는데, 이에 해당하는 데이터는 DNS[0x24:0x25] 이며, 0xc00c 값을 가집니다. 이때 14 비트의 Offset 필드 값은 0x00c입니다. 이 값은 10 진수 단위로는 12 입니다. Offset 값은 DNS 메시지의 첫 바이트를 기준으로 삼습니다. DNS 메시지의 첫 바이트로부터 12 바이트 떨어진 지점의 데이터는 DNS[0x0C:...] 입니다.

그림) 메시지 압축, 레이블 Offset 개념도

DNS[0x0C:...]는 Question 섹션의 질의도메인 이름이 시작하는 지점입니다.
DNS[0x0C:...]의 값은 0x06|dnssec|0x07|tistory|0x03|com|0x00 입니다.
결국, Answer 섹션에 0x06|dnssec|0x07|tistory|0x03|com|0x00 데이터를 설정하는 대신에, 이미 Question 섹션에 있는 0x06|dnssec|0x07|tistory|0x03|com|0x00 데이터를 가리키는 Offset 값의 2 바이트 필드로 대체함으로써 메시지 사이즈를 줄이는 압축효과를 얻는 방식을 적용하고 있습니다. Offset은 대체하고자 하는 레이블의 첫번째 데이터 위치 값을 가집니다. 그 지점으로부터 루트 레이블(0x00)까지 이르는 모든 레이블을 대체할 도메인 이름으로 간주합니다.

레이블 압축 정보 DNS[0x24:0x25] 이후의 레코드 타입은 DNS[0x26:0x27]로써 그 값은 0x0001 A 레코드 타입(1)이며, 클래스는 DNS[0x28:0x29]로써 그 값은 0x0001 IN 클래스(1) 입니다. DNS[0x2A:0x2D]는 TTL 필드로써 그 값은 0x00000e10 = 3600 입니다. DNS[0x2E:0x2F]는 RDataLength 필드이고 이 경우 그 값은 0x0004로써 IPv4 주소 데이터 길이인 4 바이트 입니다. DNS[0x30:0x33]은 IPv4 주소 값입니다.

DNS 메시지 압축(DNS Message Compression) 효과

그러면, 압축하지 않았을 경우와 압축한 경우에 DNS 메시지 사이즈가 얼마나 절감되는지 체크해 봅니다.

압축하지 않는 경우는 다음과 같습니다.

[DNS Message]                                          
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
      -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000  c6 24 81 80 00 01 00 01 00 00 00 00 06 64 6e 73   .$...........dns
0010  73 65 63 07 74 69 73 74 6f 72 79 03 63 6f 6d 00   sec.tistory.com.
0020  00 01 00 01 06 64 6e 73 73 65 63 07 74 69 73 74   .....dnssec.tist
0030  6f 72 79 03 63 6f 6d 00 00 01 00 01 00 00 0e 10   ory.com.........
0040  00 04 d3 e7 63 fa                                 ....c.

이 경우, DNS 메시지 사이즈는 0x45 + 1 = 0x46, 곧 70 바이트 입니다.

이에 비해, 동일한 DNS 응답메시지가 압축된 DNS 메시지인 경우입니다.

[DNS Message]                                          
      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
      -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0000  c6 24 81 80 00 01 00 01 00 00 00 00 06 64 6e 73   .$...........dns
0010  73 65 63 07 74 69 73 74 6f 72 79 03 63 6f 6d 00   sec.tistory.com.
0020  00 01 00 01 c0 0c 00 01 00 01 00 00 0e 10 00 04   ................
0030  d3 e7 63 fa                                       ..c.

이 경우, DNS 메시지 사이즈는 0x33 + 1 = 0x34, 곧 52 바이트 입니다.

52 / 70 = 0.74 이므로, 약 30%의 DNS 메시지 사이즈 절감이 있음을 알 수 있습니다.

이 수치는 '80년대 인터넷 환경에서는 작다고 할 수는 없는 DNS 트래픽에 의한 백본망 트래픽 점유량의 절감을 의미했을 것입니다. 중복된 도메인 이름 부분(대체하는 도메인 이름 부분)이 길수록 압축효과는 커집니다.

DNS 메시지 압축(DNS Message Compression) 규정에 의해 인터넷 백본망 트래픽 점유 절감을 이루었지만, 그 대신 DNS 응답 메시지를 수신하여 해석하는 작업이 다소 복잡해지게 됩니다. '80년대 상황에서 본다면 트래픽량의 절감을 선호하는 것이 더 이익이었을 것입니다.

여기서 보인 사례는 사실 아주 단순한 경우에 해당합니다. 실제로는 DNS 메시지 압축(DNS Message Compression)이 적용된 DNS 응답메시지의 해석이 복잡한 처리를 필요로 하는 경우가 많습니다.

도메인 이름 데이터 포맷, 레이블, 그리고 FQDN

승홍 — Sun, 12 Jan 2020 11:50:16 +0900

DNS 질의응답 패킷에서 쓰이는 도메인 이름 데이터는 우리가 아는 도메인 이름과는 다소 다른 모습을 가집니다.

도메인 이름을 표기한 'dnssec.tistory.com'은 사람이 사용하기 쉬운 형태인 텍스트(text) 문자열 형태로 표현한 것입니다. 네임서버가 다루는 DNS 도메인 이름 데이터, 그리고 DNS 질의응답 패킷에서 사용하는 도메인 이름 데이터는 '단순한 텍스트 문자열'이 아닙니다.

다음 그림은 도메인 이름 'dnssec.tistory.com'을 예로 들어, 도메인 이름의 구조를 보이는 개념도입니다. 도메인 이름 데이터의 모습이 그리 간단하지는 않아 보입니다.

그림) 도메인 이름 데이터 포맷 구조 개념도

레이블 (label), 도메인 이름의 구성 요소

레이블(label)의 데이터 유형은 문자열입니다. 문자열 데이터는 다수의 문자(character)로 조합된 데이터 입니다.

네트워크 프로토콜에서 문자열은 흔히 Length|String의 형태로 표현합니다. 즉, 문자열 데이터를 설정할 때 그 앞에 '문자열의 길이(length) 정보'를 두고 이후에 '문자열 데이터'를 설정합니다. 레이블도 이와 동일하게 Len|Label String의 형태를 갖는 문자열 입니다.

주의할 것은 '레이블 문자열(Label String)' 만 레이블인 것이 아니라는 점입니다. '레이블 길이'와 '레이블 문자열'을 모두 포괄한 것을 레이블이라 합니다. 레이블은 문자열 데이터이므로, 문자열 길이 정보까지 포함해야 합니다. 문자열 길이가 표시되지 않으면, 길게 이어지는 데이터 스트림 중에서 어디까지가 지정된 문자열에 해당하는지 파악할 수 없어 문자열 정보를 해석해 낼 수 없습니다.

DNS에서 원칙적으로는 레이블 문자열에 사용할 수 있는 문자에 제한은 없습니다. 다만, 레이블로 구성된 도메인 이름이 '호스트 이름(hostname)'으로 사용되는 경우에는 오직 영문자, 숫자(0 ~ 9), 하이픈('-') 만 사용하여 레이블 문자열을 구성해야 합니다. (참고 포스팅 : "호스트 이름, 도메인 이름")

도메인 이름은 반드시 하나 이상의 레이블로 구성됩니다. 레이블 하나만으로 구성된 도메인 이름도 있습니다. ""이라는 비어있는 하나의 레이블 문자열만 갖는 경우 입니다. 이것은 특수한 도메인 이름인 루트(root) 도메인 이름입니다.

DNS 패킷에서는 하나 이상의 레이블을 연이어 나열하여 도메인 이름을 설정합니다. 하지만 이것을 그대로 텍스트로 표현할 수 없으므로, 텍스트로 표현할 때 도메인 이름은 각 레이블 사이에 구분자로 점(dot, ".")을 두어 표기합니다.

구체적인 사례로써 텍스트로 표현되는 도메인 이름 dnssec.tistory.com. 경우, 각 레이블은 구분자 점(.)으로 구분되어 표기되어 있습니다. 이 도메인 이름의 데이터는 패킷에서 다음과 같은 형태를 가집니다.

0x06|dnssec|0x07|tistory|0x03|com|0x00

여기서 보는 것과 같이 Len|Labe String의 각 레이블이 그대로 연이서 나열되는 형태를 가집니다. 점(.)에 해당하는 부분은 없습니다. 점(.)은 도메인 이름을 텍스트 형태로 표기할 때 만 사용합니다.

위 데이터 중 마지막의 0x00 부분은 루트 레이블(root label) 입니다. 특수한 형태의 레이블 입니다. 0x00 레이블은 텍스트 표현으로는 '.'으로 표현합니다. 레이블 구분자 점(.) 이후에 레이블 문자열이 없다는 의미로 이렇게 표기합니다. 루트 레이블(root label)에 대한 자세한 사항은 아래에서 따로 다룹니다.

Q. 도메인 이름의 각 레이블은 최대 길이가 63 바이트라고 하는데 왜 그런가요?

각 레이블은 63 바이트 이내의 문자열이어야 합니다.

왜 63 바이트 길이 제한을 두었을까요?

레이블은 Len|Label String으로 구성되는데, Len은 1바이트 필드이므로 2⁸ = 256 이어서, 최대 표현할 수 있는 레이블 길이는 255 바이트 일 것 같은데, 그렇지 않고 이보다 훨씬 작은 길이인 63 바이트로 레이블 문자열 최대 길이가 제한되어 있습니다.

레이블 최대 길이 63 바이트에 대한 제한은 DNS 표준에서 일방적으로 정한 것은 아닙니다. 반대로 당시 인터넷 및 호스트 환경을 고려하여 설계하다 보니 레이블 최대 길이가 대략 63 바이트로 정해진 것이라 할 수 있습니다. 즉, 당시의 인터넷 및 호스트 규정에 대한 대대적인 수정 없이 DNS 체계를 인터넷에 도입 적용할 수 있도록 DNS 표준 규정을 정하였다고 볼 수 있습니다. 이 가운데 레이블 문자열의 최대 길이는 63 바이트로 정해졌습니다.

DNS 표준에 의한 도메인 이름 체계가 개발되기 전에 이미 당시 인터넷에서는 "호스트 이름"이 사용되고 있었습니다. 호스트(host) 시스템에서 사용하는 호스트 이름(hostname)은 최대 255 바이트로 제한되어 있습니다. 데이터 길이를 1 바이트 필드로 표기한다면 2⁸ = 256 이므로 표현 가능한 데이터 길이는 0 ~ 255 바이트입니다. DNS 표준 설계시 이 사항이 고려되었을 것입니다.

'80년 초기 그 당시 DNS를 설계하던 입장에서 생각해 보기로 합니다. DNS 표준으로 도입하려는 도메인 이름 체계는 영역(domain) 구분을 두어 조성하는 이름 체계 입니다. dnssec.tistory.com. 경우, 루트(.) 도메인 영역의 하위 서브 도메인 영역 com., 그 아래 tistory.com 서브 도메인 영역에 속하는 이름 dnssec 임을 표현합니다. 이때 dnssec.tistory.com.이 호스트 이름으로 사용된다면 전체 이름인 dnssec.tistory.com.의 길이가 255 바이트를 초과하지 않아야 합니다. 이를 볼 때, 만약 각 레이블 길이의 최대 길이를 255 바이트로 규정한다면 뭔가 문제가 있을 것 같아 보입니다. 전체 도메인 이름 길이가 호스트 이름 최대 길이인 255 바이트 이내 이어야 한다면, 도메인 이름을 구성하는 레이블 문자열의 최대 길이는 좀 더 짧아야 할 것입니다. 그래야 다수 레이블로 구성된 도메인 이름 전체 길이가 255 바이트를 초과하지 않게 될 수 있으니까요.

DNS 표준은 초기에 레이블 형식을 정의하면서 레이블의 길이를 표기하는 1 바이트 필드를 2비트의 Label Type과 6 비트의 Label String Length 서브 필드로 구분하여 나누었습니다. 이렇게 정의하면 Label String의 길이를 표시하는 Label String Length가 6 비트 필드가 표현할 수 있는 레이블 문자열 최대 길이는 63 바이트가 됩니다 (2⁶ - 1 = 63). 이것이 레이블 문자열 최대 길이가 63 바이트로 한정된 이유입니다.

Q. 그러면, 도메인 이름에 설정할 수 있는 레이블 최대 개수는 몇 개인가요?

도메인 이름을 구성하는 데 사용할 수 있는 레이블의 최대 개수에 대해서는 제한 규정은 없습니다.

다만, 도메인 이름 최대 길이 255 바이트 제한에 의해, 도메인 이름에 사용할 수 있는 레이블 개수가 제한 됩니다.

예시로써 레이블 문자열 길이가 모두 63 바이트인 레이블 문자열로만 도메인 이름을 구성한다고 가정 합니다. 이 경우, 도메인 이름 길이 255 바이트 한계 내에서 사용할 수 있는 레이블 개수는 3개 입니다. 4개의 63 바이트 레이블 문자열로 구성하는 도메인 이름은 257 바이트가 되므로, 3개의 63 바이트 레이블까지 사용하여 도메인 이름을 만들 수 있습니다. 구체적으로 계산해 보면 다음과 같습니다.

$ echo "$(( (1 + 63) * 3 + 1 ))"
192
$ echo "$(( (1 + 63) * 4 + 1 ))"
257
$

위 길이계산 식의 마지막에 +1이 더 있습니다. 이것은 패킷 내의 도메인 이름 데이터 포맷과 도메인 이름의 텍스트 표현 형식이 서로 상이하기 때문입니다. 구체적으로 dnssec.tistory.com. 이라는 도메인 이름 경우를 살펴보면 그 이유를 알 수 있습니다.

0x06|dnssec|0x07|tistory|0x03|com|0x00

길이계산 : (1 + 6) + (1 + 7) + (1 + 3) + (1 + 0) = 20

여기서 보듯이, 각 레이블의 길이는 '레이블 길이 표현 1 바이트' + '레이블 문자열 길이'로 계산됩니다. 문제는 마지막 루트 레이블(root label) 경우 입니다. 도메인 이름의 마지막 레이블은 항상 루트 레이블 입니다. 루트 레이블은 Len|Label String 중에서 1 바이트인 Len 필드로만 구성되므로 그 길이는 항상 1 바이트이며 그 값은 0x00 입니다.

텍스트 형태로 표현된 도메인 이름 dnssec.tistory.com.의 길이는 19 바이트 입니다. 하지만 도메인 이름 포맷으로 설정되는 도메인 이름은 0x06|dnssec|0x07|tistory|0x03|com|0x00이며 그 길이는 20 바이트 입니다. 여기서 알 수 있는 것은 도메인 이름의 최대 길이 255 바이트 초과여부를 판단하는 기준은 텍스트로 표현된 도메인 이름이 아니라 패킷에 설정되는 도메인 이름 데이터라는 점 입니다.

그러면 텍스트 표현 도메인 이름으로 기준할 때 도메인 이름의 최대 길이는 어떻게 될까요? FQDN 이름을 기준할 때는 254 바이트 입니다. 하지만 마지막 루트 레이블('.')을 생략한 표현의 경우라면 253 바이트 입니다. 254 바이트의 FQDN 도메인 이름은 255 바이트의 도메인 이름 데이터 길이에 해당합니다.

Q. 레이블의 레이블 종류(Label Type)라는 필드는 어떤 역할을 하나요?

각 레이블은 Len | Label 형태를 갖습니다. 위 그림에서 보듯이 Len 필드는 2개 부분으로 나뉘어 있습니다.

Len 필드의 첫 2 bit는 레이블 종류(label type)를 표시합니다. 0b00인 경우 Label은 일반 레이블입니다. 0b11인 경우, Label은 압축된 도메인 이름(compressed domain name) 경우에 사용되는 레이블에 대한 Offset 값을 의미합니다.

다음 표는 레이블 종류(Label Type) 필드의 값을 정리하여 보여 줍니다.

label type (2비트)	개요
`0b00......`	일반 레이블 (초기 표준, RFC1035)
`0b01......`	미정의
`0b10......`	미정의
`0b11......`	압축된 도메인 이름(compressed domain)의 offset (초기 표준, RFC1035)

지금까지의 레이블 문자열 길이에 대한 설명은 레이블 종류(label type) 중 0x00 유형인 경우에 국한되어 있었습니다. 레이블 문자열을 직접 사용하는 일반적인 경우입니다.

반면, 레이블 종류(label type) 값이 0b11인 경우, 이 레이블은 특별한 역할을 합니다. 이것은 DNS 메시지 압축(DNS Message Compression) 방식에 사용되는 레이블 입니다.

레이블 종류(label type) 값이 0b11이면, 이 레이블은 항상 2 바이트 길이를 가집니다.

초기 DNS 표준 문서 RFC1035, 4.1.4. Message compression 장에는 다음과 같이 레이블 종류(label type) 값이 0x11인 경우에 특수한 레이블 포맷을 정의하고 있습니다.

 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1  1|                OFFSET                   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

레이블 종류(label type) 값이 0x11인 경우, 레이블은 16 비트 곧 2 바이트의 고정된 길이를 갖습니다. Offset 값은 14 비트 길이를 가지는 필드이며 표현할 수 있는 최대 값은 2¹⁴ - 1 = 16,383입니다. 이 Offset 필드 값은 문자열 데이터가 아닙니다. DNS 메시지 중 어딘가에 있는 레이블 문자열의 위치를 표현하는 Offset 값 입니다. 자세한 사항은 DNS 메시지 압축(DNS Message Compression)에 대한 별도 포스팅에서 다루기로 합니다.

그림) Label Type = 0b11 경우, 레이블 Offset 포맷 개념도

루트 레이블 (root label)

도메인 이름은 다수의 연속된 레이블로 구성되어 있습니다. 점(dot, ".")을 구분자로 삼아 각 레이블을 순서대로 나열하여 도메인 이름을 형성합니다.

도메인 이름 dnssec.tistory.com에서 'dnssec', 'tistory', 'com'이 각각 레이블(label) 입니다. 하지만, 여기서 언급이 누락된 레이블이 하나 있습니다. 맨 마지막의 루트 레이블(root label)이 바로 그것 입니다.

루트 레이블은 특수한 레이블입니다. 루트 레이블은 항상 0x00 값을 가집니다. 모든 레이블은 Len|Label 형태의 포맷을 갖습니다. 이는 루트 레이블에도 그대로 적용됩니다. 루트 레이블 경우 레이블(Label) 문자열은 "NULL 문자열" 입니다. "NULL 문자열" 은 길이가 0인 문자열 입니다. "NULL 문자"와는 다릅니다. 개념상 유의해야 할 부분입니다. "NULL 문자"는 길이가 1 바이트이고 "NULL 문자"의 코드 값은 1 바이트의 0x00 입니다. ASCII 문자 코드 테이블의 첫번째 문자가 바로 이 "NULL 문자" 입니다. 이에 비해 "NULL 문자열" 은 아무런 값이 없고 길이도 없어 그 길이는 0 바이트입니다. 루트 레이블(root label)은 NULL 문자열 입니다. 그래서 Len 값이 0x00이고 그 레이블 문자열은 데이터가 비어있는 "NULL 문자열" 입니다.

루트 레이블을 고려하면 도메인 이름 dnssec.tistory.com을 구성하는 레이블은 'dnssec', 'tistory', 'com', 그리고 마지막의 루트 레이블 입니다.

이렇게 모든 도메인 이름의 마지막 레이블은 항상 루트 레이블 입니다. 모든 도메인은 루트 도메인 영역에 속해 있다는 것을 의미합니다.

FQDN (Fully Qualified Domain Name)

모든 도메인 이름의 마지막 레이블은 항상 루트 레이블입니다.

루트 레이블은 텍스트 형태로 표기할 때 "."으로 표기합니다. 레이블의 문자열 값이 없다는 것을 표시하는 표기입니다. 레이블 사이를 구분하는 점(dot, ".") 뒤에 따라오는 레이블이 아무런 문자를 가지지 않는 것을 표시하는 표기 방식입니다.

흔히 도메인 이름은 "dnssec.tistory.com" 과 같이 표기합니다. 하지만 이러한 표기는 마지막의 루트 레이블을 생략한 표기 방식입니다. 루트 레이블을 생략했기 때문에 이 도메인 이름이 루트 도메인 영역에 속해 있는 이름인지 아니면 "com.cn."이나 "com.br."과 같이 어떤 도메인 영역 하위에 속한 이름인지 확실히 알 수 없습니다.

도메인 이름 "dnssec.tistory.com"의 전체 내용을 표기한다면 "dnssec.tistory.com."이 되어야 합니다. 루트 레이블(".")을 명기하는 것입니다.

"dnssec.tistory.com."으로 루트 레이블까지 명시하여 표기한 도메인 이름 표기 방식을 FQDN (Fully Qualified Domain Name) 이라 합니다. 이 용어를 한국어로 어떻게 번역해야 할 지 좀 난감합니다. 의역한다면 대략 "완전한 도메인 이름", "약칭이 아닌 온전한 전체 이름", 또는 "절대적 도메인 이름" 정도가 되지 않을까 싶습니다. 루트 레이블까지 포함한 전체 도메인 이름을 명확히 명시한 도메인 이름이라는 의미입니다.

참고하세요 : Fully qualified domain name - Wikipedia

FQDN을 기준으로 본다면, "dnssec.tistory.com"으로 표기한 도메인 이름은 상대적 도메인 이름으로써 도메인 이름의 일부분만을 표기한 도메인 이름이라 할 수 있습니다. 도메인 이름 "dnssec.tistory.com"은 "dnssec.tistory.com.cn."이란 도메인 이름의 일부분 일 수도, 아니면 "dnssec.tistory.com.br."의 일부분 일 수도 있습니다. 이 도메인 이름이 최종적으로 소속된 도메인 영역이 어디인지 표기되지 않았기 때문입니다. (중국 .cn 도메인은 com.cn. 이라는 서브 도메인 영역을, 브라질 .br 도메인 역시 com.br. 서브 도메인 영역을 가지고 있습니다.) 이에 반해 FQDN "dnssec.tistory.com."은 이 이름이 루트에서 바로 위임된 'com', 그리고 'com' 에서 'tistory.com'로 위임된 도메인 영역에만 속하는 유일한 도메인 이름 임을 의미 합니다. FQDN "dnssec.tistory.com."은 "dnssec.tistory.com.cn." 일 수 없습니다.

FQDN 방식으로 표기된 도메인 이름은 인터넷 상에서 유일한 이름을 명확히 표현하는 역할을 합니다. 인증서 발급 신청 경우와 같이, 표기하는 도메인 이름에 대해 아주 정확한 도메인 이름 정보가 필요한 경우에 FQDN 방식으로 도메인 이름을 표기할 것을 요구하는 것은 이러한 이유 때문입니다.

호스트 이름, 도메인 이름

승홍 — Fri, 27 Dec 2019 22:42:14 +0900

호스트 이름 (hostname)

인터넷 망에서 호스트(host)라고 하면, IP주소를 설정함으로써 인터넷 망에 연결된, 통신 가능한 요소를 의미합니다. IP주소를 사용하여 통신할 수 있는 '어떤 것'입니다. 예전에는 서버 시스템이나 개인용 컴퓨터 등이 호스트에 해당한다고 말할 수 있었지만, 이제 IoT 시대가 되면서부터는 인터넷에 연결되는 '어떤 것'이라 지칭해야 할 것 같습니다.

'호스트(host)'의 기준은 IP 주소입니다. 서버 시스템, 개인용 컴퓨터(PC), 라우터 모두 인터넷 망의 호스트입니다. 모두 IP주소를 사용해 통신할 수 있는 '어떤 것' 입니다. 앞으로 IoT가 보편화되면서 자동차에 IP 주소가 부여되어 인터넷 망을 통해 통신할 수 있는 장치가 된다면 자동차 역시 하나의 호스트(host)가 됩니다. 인터넷에 연결된 냉장고도 '호스트'입니다. 현재 IP주소라고 하면 IPv4 주소 만을 의미하지 않고 'IPv6 주소'도 포함합니다.

호스트 이름(hostname)은 이런 호스트(host)에 부여된 이름(name)입니다. IP주소를 갖고 있는 '어떤 것'에 '이름(name)'을 부여한 것입니다. 이미 IP주소를 갖고 있는데 왜 이름을 더 부여할까요? IP주소는 사람이 일일이 기억하기 힘들기 때문에 기억하기 쉬운 이름을 부여하여 통신에 사용합니다.

컴퓨터에 리눅스를 설치하는 과정에서, 또는 윈도우즈를 설치하는 과정에서 반드시 설정해야 하는 정보 중 하나가 바로 컴퓨터 이름입니다. 이 이름이 바로 호스트 이름(hostname)입니다. 컴퓨터에 명칭(name)을 부여합니다.

그런데, 컴퓨터의 이름으로 한글 이름을 설정할 수 없습니다. 오직 영문자로 이름을 설정하라고 요구합니다. 왜 이런 걸까요? 이 컴퓨터 이름이 인터넷 망에서는 그대로 호스트 이름(hostname)으로 쓰이기 때문입니다.

호스트 이름을 명명(naming)하는 규칙은 아주 엄격합니다. 호스트 이름으로는 오직 영문자, 숫자(0 ~ 9), 하이픈('-'), 문자만 사용할 수 있습니다. 호스트 이름의 첫 문자에 하이픈('-')을 사용할 수 없습니다. 또 호스트 이름의 마지막 문자로 하이픈('-')를 사용할 수 없습니다. 이 규칙을 지켜야 호스트 이름으로 입력이 가능합니다.

"영문자, 하이픈('-'), 숫자(0 ~ 9) 문자만 사용할 수 있다"라는 규칙을 접하면서 뭔가 떠오를 듯하는 게 없나요? 바로 도메인 이름을 등록할 때 지켜야 하는 도메인 이름 짓기 규칙입니다. 그렇다면, 도메인 이름은 곧 호스트 이름인 걸까요? 도메인 이름과 호스트 이름은 동일한 걸까요?

사례) .kr 도메인 명명규칙 : KISA 한국인터넷정보센터(KRNIC), .kr 도메인

도메인 이름(domain name)과 호스트 이름(hostname)의 관계

단적으로 말하자면, 호스트 이름은 도메인 이름의 한 가지 특수한 유형입니다. 도메인 이름 중에서 IP주소를 설정할 수 있는 이름이 호스트 이름입니다. 호스트 이름은 도메인 이름의 유형 중 일부분입니다.

원칙적으로 도메인 이름에 사용할 수 있는 문자에 제한은 없습니다. 한글을 그대로 사용하는 도메인 이름 사용도 문제없습니다. 다만 이 경우 한글로 된 도메인 이름에는 IP주소 레코드(A 또는 AAAA 레코드)를 설정할 수 없습니다. 왜냐하면 한글로 된 도메인 이름은 도메인 이름이기는 하지만 호스트 이름이 아니기 때문입니다. 한글을 표현하는 문자열은 영문자 ASCII 코드 범위를 벗어난 범위의 문자코드를 사용하기에 호스트 이름일 수 없습니다.

흔히 한글 도메인이라 불리는 도메인 이름은 사람이 볼 때는 한글로 표현되지만 DNS 서버가 처리하는 실제 이름은 'xn--'으로 시작하는 이름으로써, 사실상 호스트 이름 규칙에 부합하는, 영문자와 숫자(0 ~ 9), 하이픈('-')으로 구성된 호스트 이름입니다. 이 'xn--'으로 시작하는 도메인 이름을 퓨니코드(punny code) 도메인 이름이라 합니다. 퓨니코드는 원래 호스트 이름이 될 수 없는 한국어 도메인 이름(다국어 도메인 이름)을 일정한 변환 규칙에 따라 호스트 이름 규칙에 적합한 이름으로 '변환 처리된 이름'입니다. 그래서 'xn--'으로 시작하는 해독하기 어려운 요상한 모습의 도메인 이름이 됩니다. 퓨니코드를 사용하는 '다국어 도메인(IDN)'에 대한 이야기는 별도 포스팅으로 다루고자 합니다.

예시) '대한민국. kr'이라는 한글 도메인이 실제 DNS 서버에 반영될 때는 'xn--3e0bs9hfvinn1a.kr'이라는 호스트 명명 규칙에 적합한 이름(punny code name)으로 변환되어 적용
대한민국.kr -> xn--3e0bs9hfvinn1a.kr

요즘 전자메일 보안정책 설정과 관련된 DNS 레코드 설정 중에 _dmarc.daum.net과 같이 호스트 이름이 아닌 도메인 이름을 사용하는 방식이 있습니다. 호스트 이름에는 절대로 사용할 수 없는 언더바('_') 문자를 갖는 이름 _dmarc를 도메인 이름에 포함하여에 사용하고 있습니다. _dmarc.daum.net은 DMARC라고 하는 전자메일 스팸 차단 관리정책 내용을 설정하는 DNS 레코드의 도메인 이름입니다. 이런 이름의 사용 방식은 DNS 체계에서 전혀 문제가 되지 않습니다. 왜냐하면 이 _dmarc.daum.net 도메인 이름에는 TXT 레코드만 사용하도록 DMARC 표준에서 정의되어 있기 때문입니다. 즉 IP주소를 가진 호스트 이름으로 사용하는 경우가 없는 이름이기 때문에 호스트 이름 명명 규칙을 따를 필요가 없습니다.

현시점의 호스트 이름(hostname) 표준 규정

현재 호스트 이름 규칙은 RFC1123 Requirements for Internet Hosts -- Application and Support / Internet Standard / 1989 문서의 '2.1 Host Names and Numbers' 장에서 정의된 사항을 따릅니다. 이 표준 문서는, 인터넷에 연결되는 호스트를 구현하는 경우 그 구현에 있어 준수해야 하는 표준 규격 사항을 정하고 있습니다. 인터넷에 연결되어 사용될 용도로, 즉 공유기나 PC, IoT 장비용 OS 등 IP주소를 설정하여 인터넷에 연결되는 장치를 구현한다면 이 표준을 준수하여 OS를 구현해야 합니다. 이 표준 문서에서 인터넷 초기의 호스트 이름 명명 규칙과 달리 변경된 점은 숫자(0 ~ 9) 문자를 호스트 이름의 첫 번째 문자로 사용할 수 있게 되었다는 점입니다. 이 사항은 도메인 등록 시, 도메인 이름 작명 규칙에도 반영되어 현재는 숫자(0 ~ 9)로 시작하는 도메인 이름의 등록도 가능하게 되었다는 것을 의미합니다. 숫자만으로 구성된 도메인 이름도 호스트 이름으로 이제는 사용 가능합니다. 따라서 현재는 0-9만으로 이루어진 숫자 도메인도 도메인 이름으로 등록하여 사용 가능합니다.

Q. 호스트 이름은 왜 영문자, 숫자(0 ~ 9), 하이픈('-') 문자만 사용하는 명명 규칙을 갖게 되었을까요?

영국과 미국에서 시작된 컴퓨터 역사 속에서 그렇게 정해졌습니다. 그리고 지금까지 이어져 오고 있습니다. DNS 표준이 만들어지기 이전에 이미 호스트 이름과 그 명명 규칙은 있었습니다. 1980년대 초에 등장한 DNS는 이 기존의 호스트 이름 체계를 포함하면서도 더 포괄적이고 보편적인 네이밍(naming) 체계로써 도메인 이름 체계를 새롭게 정의한 것일 뿐입니다. 즉, 기존의 호스트 이름 체계를 그대로 인정, 포용하면서도 이를 포함하면서 보다 광범위한 이름을 사용할 수 있도록 한 것이 도메인 이름 체계입니다.

Q. 도메인 등록을 할 때, 왜 도메인 이름 작명을 호스트 이름 명명 규칙으로 한정하고 있나요?

등록할 도메인이 이 도메인 이름을 포함하는 호스트 이름을 명명하여 사용하게 될 것이 분명하기 때문에, 보다 제한적인 호스트 이름 명명 규칙을 도메인 이름 작명 규칙으로 적용하여 등록받고 있는 것일 뿐입니다.

예를 들어, _tistory.com으로 도메인 이름을 등록할 수 있다 하더라도 여기에 dnssec._tistory.com이라는 호스트 이름에 A 레코드를 설정하여 사용할 수 없게 됩니다. 도메인 이름 dnssec._tistory.com에 A 레코드를 설정하려 한다면 dnssec._tistory.com 이름 자체가 호스트 이름 규칙에 어긋나기 때문입니다. 결국 호스트 이름 규칙에 어긋난 _tistory.com 존을 DNS 서버에 설정할 수는 있을지 모르지만 이 도메인 영역 내부에서는 A 레코드를 설정하는 도메인 이름(곧 호스트 이름)을 전혀 설정할 수 없게 되어 사실상 쓸모없는 도메인이 되어 버립니다. _tistory.com 존에서는 웹 서버 이름에 IP주소도 설정할 수 없는 상황이 발생하게 됩니다. 이러한 이유로 도메인 이름을 등록하는 단계에서 호스트 명명 규칙을 최소한의 규칙으로 정하여 등록할 도메인 이름을 제한하고 있습니다.

_tistory.com 존의 네임서버 이름으로 ns1._tistory.com을 사용할 수 없습니다. 언더바('_') 문자가 포함되어 있어 호스트 이름이 아니기 때문에 이 이름에 IP주소 레코드를 설정할 수 없습니다. _tistory.com 이름에 A 레코드 설정하는 것은 당연히 불가능합니다. _tistory.com의 MX 레코드로 mail._tistory.com을 지정할 수도 없습니다. mail._tistory.com이 호스트 이름이 아니기에 mail._tistory.com에 메일서버 IP주소를 설정할 수가 없습니다. 이 정도면 실질적으로 거의 쓸모없는 도메인이 될 수밖에 없을 것입니다. IP주소 설정이 없는 특수한 용도의 존이 아니라면 등록할 가치가 없는 도메인이 될 것입니다.

따라서, 도메인 이름 등록 절차에 괜히 쓸데없는 제한을 두고 있는 것은 아닙니다. 도메인을 등록한 이후에 이 도메인을 활용하는 데에 아무런 문제가 없도록 보장해 주기 위함입니다.

DNS 서버 S/W에서도 호스트 이름 규칙을 벗어난 도메인 이름에 A 레코드를 설정한 존 파일을 반영하려고 시도하면 DNS 서버는 이 존 파일을 오류로 판정하고 아예 DNS 서버에 반영하지 않습니다. 불만에 찬 듯한 오류 로그만 남기고 도메인 존 파일의 DNS 서버 반영 처리는 거부합니다. 하지만, 만일 이 존 파일 안에 A 레코드나 AAAA 레코드의 IP 주소가 설정된 도메인 이름이 전혀 없다면, 즉 호스트 이름이 전혀 없다면 DNS 서버 S/W는 아무런 불만 없이 그 존 파일을 받아들입니다. 문제는 이 존 파일에 IP주소 A/AAAA 레코드를 추가 설정하는 경우에 발생합니다. 이때 DNS 서버 S/W는 갱신된 존 파일을 반영하는 처리를 그 즉시 거부합니다.

IPTables, DNS 패킷 차단 설정 방법 모색 (2)

승홍 — Fri, 13 Jan 2017 21:09:09 +0900

DNS ANY 타입 질의와 DDoS 증폭공격

2013년 초 DNS증폭 DDoS공격은 300Gbps의 트래픽 공격능력을 보여주어 모두를 놀라게 했었습니다.

공격자들은 'isc.org' ANY 질의 또는 'ripe.net' ANY 질의를 이용하였습니다.

이후 'isc.org'와 'ripe.net'에 대한 ANY 질의는 캐시DNS서버를 구동하는 사이트에서 속속 차단조치 되었습니다.

하지만 DNS증폭 DDoS공격에 이들 도메인만 꼭 사용해야 하는 것은 아닙니다. 적당한 다른 도메인을 찾아내어 ANY 질의를 사용할 수 있습니다.

DNS 증폭 DDoS 공격 개념도

DDoS 증폭공격에 특정 도메인 사용 이유

그런데, 왜 수많은 도메인 중에서 하필 isc.org, ripe.net을 이용했을까요?

첫째, 이들은 잘 알려진 도메인입니다.

isc.org는 DNS BIND 네임서버를 제작 배포하는 기관입니다. 네임서버 S/W 외에도 DNS와 관련된 각종 활동을 활발히 전개하고 있습니다.

ripe.net은 유럽지역의 RIR입니다. 유럽대륙에 IP주소와 AS번호 자원의 할당업무를 담당하고 있으며, 이외에 DNS 관련 모니터링과 네트워크 모니터링 등 인터넷 운영관리에 관련된 각종 선도적 프로젝트를 수행하고 있는 기관입니다.

둘째, 이들 도메인은 모두 일찌기 DNSSEC을 선도적으로 도입 적용한 도메인입니다.

DNSSEC을 도입한 도메인은 DNS응답 메시지 사이즈가 늘어납니다. DNS 레코드의 위-변조 방지를 위한 전자서명 레코드(RRSIG)가 응답에 추가 포함되기 때문입니다.

DDoS 증폭공격에 ANY 질의사용 이유

왜 ANY 타입 질의를 사용할까요?

ANY 타입 질의는 메타 질의타입입니다. '메타질의'라는 의미는 그 질의하고자 하는 대상이 실재하지 않다는 의미입니다.

ANY 타입질의가 있지만 "ANY 레코드"는 없습니다.

ANY 질의는 모든 유형의 레코드를 질의하는 용도로 정의되었습니다. 1980년대 DNS의 초기 표준시절부터 정의되어 사용되어 온 오래된 질의타입입니다.

ripe.net에 대해 ANY 질의를 하면, repe.net 도메인이름에 설정된 '응답 가능한 모든(ANY)' 유형의 DNS 레코드들이 한꺼번에 응답됩니다.

ripe.net 도메인은 존 이름으로써 여기에는 SOA 레코드, NS 레코드, MX 레코드, 메일발송 호스트를 지정하는 TXT(SPF) 레코드 등이 기본적으로 설정됩니다.

요즈음은 웹 브라우저에 www.ripe.net이 아니라 ripe.net 만 입력해도 웹 사이트 홈 페이지에 접속되도록 A 레코드와 AAAA 레코드가 설정되어 있기도 합니다.

DNSSEC이 적용된 경우, ripe.net에 DNSSEC 서명 공개키인 DNSKEY가 설정되어 있고, 서명레코드인 RRSIG 레코드가 각각의 레코드 종류에 따라 다수 설정됩니다.

이 뿐만 아니라, Authority 섹션과 Additional 섹션에 딸려 응답되는 레코드들도 있습니다.

이러한 레코드들이 한꺼번에 응답됩니다. 응답 메시지 전체 사이즈가 커질 수 밖에 없습니다.

DNSSEC이 적용된 ripe.net이나 isc.org에 대해 직접 ANY 질의를 해 보면 응답 메시지 사이즈가 상당히 크다는 것을 확인할 수 있습니다.

isc.org의 ANY 질의를 해보면, 이에 대한 응답메시지에는 ANSWER 섹션에 30개 레코드, AUTHORITY 섹션에 4개, ADDITIONAL 섹션에 15개 레코드가 설정되어 있습니다.

응답메시지 총 사이즈는 무려 3,731 바이트에 이릅니다.

$
$ dig @192.168.123.104 isc.org ANY +noall +comment +stats

; <<>> DiG 9.11.0b1 <<>> @192.168.123.104 isc.org ANY +noall +comment +stats
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42105
;; flags: qr rd ra; QUERY: 1, ANSWER: 30, AUTHORITY: 4, ADDITIONAL: 15

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 24b32c5f3ab3595b63a9523f5843c93ad2f0d0763cf884ea (good)
;; Query time: 1 msec
;; SERVER: 192.168.123.104#53(192.168.123.104)
;; WHEN: Sun Dec 25 16:43:54 KST 2016
;; MSG SIZE  rcvd: 3731
$

ripe.net의 ANY 질의 경우, 응답메시지에 ANSWER 섹션에 25개 레코드, AUTHORITY 섹션에 7개, ADDITIONAL 섹션에 8개 레코드가 설정되어 있습니다.

응답메시지 총 사이즈는 2,739 바이트 입니다.

$
$ dig @192.168.123.104 ripe.net ANY +noall +comment +stats

; <<>> DiG 9.11.0b1 <<>> @192.168.123.104 ripe.net ANY +noall +comment +stats
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13022
;; flags: qr rd ra; QUERY: 1, ANSWER: 25, AUTHORITY: 7, ADDITIONAL: 8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0d02ab9f6291747570659bfa5843c946961681e3eb551daa (good)
;; Query time: 980 msec
;; SERVER: 192.168.123.104#53(192.168.123.104)
;; WHEN: Sun Dec 25 16:44:06 KST 2016
;; MSG SIZE  rcvd: 2739

$

DNS 질의응답의 "증폭"효과를 악용하는 DDoS 증폭공격

DNS증폭 DDoS 공격의 파괴력은 'DNS질의패킷 사이즈' 대비 'DNS응답패킷 사이즈'의 배율이 얼마나 되는가에 달려 있습니다.

ripe.net 경우, ripe.net ANY 질의 패킷길이는 91 바이트, 이에 대한 응답 패킷 길이는 2,325 바이트입니다.

91바이트 패킷 발생 --> 2,325 바이트 패킷 발생 유발 :=> 25.5 배의 증폭효과 가 발생합니다.

즉, 소량의 패킷으로 대량의 패킷의 발생을 유발시킬 수 있습니다.

isc.org 경우, isc.org ANY 질의 패킷길이는 90 바이트, 이에 대한 응답 패킷 길이는 3,370 바이트입니다.

90바이트 패킷 발생 --> 3,370 바이트 패킷 발생 유발 :=> 37.4 배의 증폭효과 가 발생합니다.

DDoS 증폭공격은 캐시DNS 네임서버가 작은 사이즈의 DNS질의에 대해 큰 사이즈의 DNS응답 메시지를 발생시키는 특성을 이용합니다.

캐시DNS 네임서버를 "트래픽 증폭기" 용도로 악용하는 공격방식입니다.

DNS증폭 DDoS 공격은 이렇게 발생하는 큰 사이즈의 DNS응답 패킷을 공격목표 사이트로 돌려놓는 방법을 사용합니다.

DNS 질의 패킷의 소스 IP주소를 공격목표 사이트의 서버 IP주소로 설정하는 방식을 사용합니다.

DNS 질의패킷의 IP 소스 주소를 가짜로 설정하는 것입니다. (IP spoofing)

공격자는 리커시브 네임서버(캐시DNS서버)를 인터넷에서 찾아내어 이들을 동원하여 공격에 악용합니다.

캐시DNS서버를 사용하는 사용자 호스트를 제한하는 설정없이 인터넷 누구에게나 열려 있는 리커시브 네임서버(캐시DNS서버)가 공격에 악용됩니다.

"우리 사이트 네임서버가 공격받는게 아니고 다른 사이트를 공격하는 데에 이용되는 것일 뿐이니 괜찮다"고 생각할 수도 있습니다.

그러나 이런 저런 DDoS공격에 캐시DNS 네임서버가 이용되면 어떻게 될까요?

이 네임서버를 '차단'하는 사이트가 인터넷에서 점차 늘어나게 됩니다.

공격을 받는 사이트 입장에서는 공격에 '가담한' 네임서버에 대해 아무런 조치 없이 그대로 둘 수는 없습니다.

공격상황 가운데, 그리고 공격종료 이후에도 차단 조치합니다. DDoS 공격에 이용당하는 네임서버는 보안관리가 되지 않는 서버/사이트로 간주될 수 밖에 없습니다.

공격에 '가담한' 네임서버는 인터넷 이곳 저곳에서 차단당하여 DNS 질의응답을 정상적으로 수행하지 못하는 상태가 될 가능성이 높습니다.

어느 시점이 되면, 이런 저런 도메인 접속이 안되고 있다는 불만을 사용자들이 제기하기 시작할 것입니다.

IPTables로 모든 ANY 질의 차단하기 위한 설정 방법

ANY 질의를 캐시DNS 네임서버가 스스로 질의하는 경우는 거의 없습니다.

곧, 인터넷 서비스를 진행하는 과정에서 ANY 질의를 사용하는 경우는 거의 없습니다.

관리자가 DNS 상태 점검을 위해 ANY 질의를 하거나, 연구기관에서 DNS 관련 데이터 수집을 위해 사용하기도 합니다.

ANY 질의를 거의 사용하지 않지만, 사용하는 경우가 드물게 있기도 합니다.

지금은 그렇지 않겠지만, 메일서버 개발자들이 메일서버를 개발하면서 도메인의 ANY 질의를 사용하도록 코딩한 사례가 있습니다.

MX 질의를 따로 하지 않고 도메인의 ANY 질의로 한번에 필요한 레코드를 모두 조회하여 한번에 처리하고자 하는 편이성 때문이었습니다.

전자메일 규격에는 착신 도메인의 MX 레코드가 없는 경우, 그 도메인의 A 레코드에 설정된 IP주소로 메일 착신을 시도하도록 하고 규정하고 있기 때문으로 보입니다. 도메인의 ANY 질의에 대한 응답은 MX 레코드와 도메인의 A, AAAA 2가지 레코드 모두를 하나의 응답 메시지로 한꺼번에 응답합니다.

지금처럼 DNS를 악용하는 공격이 빈발한 시점에서는 DNS ANY 질의는 되도록 차단해 두는 것이 바람직해 보이기도 합니다.

그러면, 모든 ANY 질의를 차단하기 위해서 IPTables 룰셋은 어떻게 작성할 수 있을까요?

DNS 질의메시지의 '질의타입' 필드는 DNS 메시지 첫 바이트를 기준할 때 그 떨어진 위치(offset)가 고정되어 있지 않고 질의하는 도메인이름 길이에 따라 위치가 변동됩니다.

이러한 특성에 의해 DNS 메시지 어느 지점을 검사할 것인지를 확정하여 정하는 것이 쉽지 않습니다.

그렇다면, '고정된 위치의 데이터 값을 검사하는 방법' 대신에 '어떤 범위 내에 특정 값이 있는지 검사하는 방법'을 고려할 수 있습니다.

IPTables의 STRING 모듈을 여기에 다시 이용할 수 있습니다.

STRING 모듈은 검사 영역을 한정하여 지시할 수 있습니다. 검사대상 영역 내에 --hex-string 옵션으로 지정된 매칭 조건의 데이터 패턴이 존재하는지 검사할 수 있습니다.

먼저, ANY 질의 패킷 샘플 내용을 살펴 봅니다. ripe.net ANY 질의 패킷을 하나 수집하고 DNS 부분을 제외한 나머지 상세부분은 생략처리한 내용입니다.

$
$ tshark -nnn -i enp0s3 -f "udp port 53 and udp[12] & 0x80 = 0" -c 1 -Vx
Capturing on 'enp0s3'
Frame 1: 91 bytes on wire (728 bits), 91 bytes captured (728 bits) on interface 0
...
Ethernet II, Src: 52:54:00:12:35:02, Dst: 08:00:27:79:7a:18
...
Internet Protocol Version 4, Src: 10.0.2.2, Dst: 10.0.2.15
...
User Datagram Protocol, Src Port: 46543 (46543), Dst Port: 53 (53)
...
Domain Name System (query)
    Transaction ID: 0x3857
    Flags: 0x0120 Standard query
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..1. .... = AD bit: Set
        .... .... ...0 .... = Non-authenticated data: Unacceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        ripe.net: type ANY, class IN
            Name: ripe.net
            [Name Length: 8]
            [Label Count: 2]
            Type: * (A request for all records the server/cache has available) (255)
            Class: IN (0x0001)
    Additional records
        <root>: type OPT
            Name: <root>
            Type: OPT (41)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x00
            EDNS0 version: 0
            Z: 0x0000
                0... .... .... .... = DO bit: Cannot handle DNSSEC security RRs
                .000 0000 0000 0000 = Reserved: 0x0000
            Data length: 12
            Option: COOKIE
                Option Code: COOKIE (10)
                Option Length: 8
                Option Data: 1e319ccbfe856d3f
                Client Cookie: 1e319ccbfe856d3f
                Server Cookie: <missing>

0000  08 00 27 79 7a 18 52 54 00 12 35 02 08 00 45 00   ..'yz.RT..5...E.
0010  00 4d 11 05 00 00 40 11 51 8b 0a 00 02 02 0a 00   .M....@.Q.......
0020  02 0f b5 cf 00 35 00 39 38 6b 38 57 01 20 00 01   .....5.98k8W. ..
0030  00 00 00 00 00 01 04 72 69 70 65 03 6e 65 74 00   .......ripe.net.
0040  00 ff 00 01 00 00 29 10 00 00 00 00 00 00 0c 00   ......).........
0050  0a 00 08 1e 31 9c cb fe 85 6d 3f                  ....1....m?

1 packet captured
$

이 내용 중에서 바이너리 데이터로 표현된 영역을 살펴 봅니다.

아래 해당 부분을 정리했습니다. DNS 메시지 부분은 보라색으로 표시했습니다. Question 섹션의 질의도메인, 질의타입, 질의클래스 영역은 굵은 글자로 표시했습니다.

0000  08 00 27 79 7a 18 52 54 00 12 35 02 08 00 45 00   ..'yz.RT..5...E.

0010  00 4d 11 05 00 00 40 11 51 8b 0a 00 02 02 0a 00   .M....@.Q.......

0020  02 0f b5 cf 00 35 00 39 38 6b 38 57 01 20 00 01   .....5.98k8W. ..

0030  00 00 00 00 00 01 04 72 69 70 65 03 6e 65 74 00   .......ripe.net.

0040  00 ff 00 01 00 00 29 10 00 00 00 00 00 00 0c 00   ......).........

0050  0a 00 08 1e 31 9c cb fe 85 6d 3f                  ....1....m?

< 04 72 69 70 65 03 6e 65 74 00 00 ff 00 01 > 은 질의 정보인 ripe.net ANY IN 이 지정된 부분입니다. 이 중에서 ANY IN 요소 부분은 < 00 ff 00 01 > 입니다. ANY 질의타입은 0x00ff 이고, 질의클래스 IN 은 0x0001 입니다.

< 04 72 69 70 65 03 6e 65 74 00 00 ff 00 01 > 이후에 나오는 데이터들은 DNS OPT 레코드로써, 이 데이터 부부은 달려 있을 수도 있고 없을 수도 있는 '옵션' 데이터입니다. 따라서 이 부분을 포함하는 매칭 조건을 설정하는 것은 의미가 없습니다.

DNS[12] 이후 영역에 대해 < 00 ff 00 01 > 에 일치하는 데이터가 있는지 검사함으로써 ANY IN 질의 여부를 식별해 낼 수 있을 것 같습니다.

하지만, 보다 정확한 식별을 위해 < 00 00 ff 00 01 >을 사용하는 것이 좋습니다. 여기서 < 00 >은 질의된 도메인 이름의 맨 마지막 레이블인 루트 도메인의 1바이트 값입니다. 모든 질의도메인은 < 00 >으로 끝나므로, < 00 >를 검사요건 앞에 포함함으로써 "질의도메인 바로 다음의 4바이트 데이터가 < 00 ff 00 01 > 에 일치하는 경우"를 검사한다는 의미가 됩니다.

STRING 모듈의 --hex-string 옵션부분은 --hex-string "|00 00 ff 00 01|" 으로 지정할 수 있습니다.

검사할 대상 영역 범위를 정해야 합니다. 질의타입 필드와 질의클래스 필드는 Question 섹션에 있습니다.

Question 섹션의 시작점은 DNS[12]입니다. 곧 DNS 메시지 첫바이트로부터 12번째 바이트부터 Question 섹션입니다.

하지만 STRING 모듈의 검사대상 영역은 IP헤더 첫바이트를 기준점으로 삼습니다.

DNS 메시지 시작지점 DNS[0]는 IP 헤더를 기준할 때 IP[28]이라 할 수 있습니다. IP헤더 20바이트 기본 길이와 UDP헤더 8바이트 고정길이를 합하여 28바이트를 건너뛴 위치입니다.

DNS Question 섹션은 IP헤더를 기준할 때 IP[40]입니다. DNS헤더의 12번째 바이트 지점이므로 IP[28+12]인 IP[40]이 됩니다.

그래서 검사영역 범위의 시작점은 STRING 모듈 --from 옵션을 사용하여 --from 40 으로 설정할 수 있습니다.

문제는 어디까지 검사할 것인가 하는 점입니다. Question 섹션의 길이는 고정되어 있지 않고 질의도메인 길이에 따라 달라지기 때문입니다.

질의가 가능한 도메인이름의 길이는 어떤 범위의 값을 가질 것으로 예상될까요?

레이블 하나의 최대길이는 63바이트입니다. 루트 도메인 바로 아래에 있는 TLD 이름은 2바이트(ccTLD), 3바이트(gTLD)에서 최대 24바이트(다국어도메인)에 이르고 있습니다.

ANY 질의를 하게 될 대상 도메인은 대략 최대 63바이트의 레이블 하나와 최대 24바이트의 TLD 레이블 하나를 가진다고 가정하면 합리적일 수 있습니다.

최대의 경우를 기준한다면, 최대 길이의 질의도메인 이름은 1 (len) + 63 (label) + 1 (len) + 24 (label) + 1 (root) = 90바이트의 길이를 가지게 될 것입니다.

그렇다면 약간 넉넉하게 잡아서 검사범위를 100바이트로 한정해도 무방할 것입니다. '질의타입' 및 '질의클래스'의 4바이트를 포함해서 입니다.

이제 검사범위가 대략 정해졌습니다. DNS 첫바이트로부터 12번째 바이트에서 시작하여 100바이트 범위 내 영역을 검사영역으로 삼는 것입니다.

STRING 모듈의 옵션 --from, --to 를 사용하여 --from 40 --to 140로 매칭조건 검사대상 영역을 설정할 수 있습니다.

-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 140 --hex-string "|00 00 ff 00 01|" -j DROP

외부에서 유입되어 서버의 네임서버 53번 포트로 착신하는 트래픽이 DNS 질의트래픽 밖에 없다고 가정한다면, 위 IPTables 룰셋은 모든 ANY 질의를 차단할 수 있을 것입니다.

서버 시스템 적용 & 확인

IPTables 룰셋을 작성하였습니다.

$ 
$ cat ipt-drop-all-ANY-LOG.txt 
*filter
:INPUT ACCEPT 
:FORWARD ACCEPT 
:OUTPUT ACCEPT
-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 140 --hex-string "|00 00 ff 00 01|" -j LOG --log-prefix "DROP ALL ANY :" --log-level info
-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 140 --hex-string "|00 00 ff 00 01|" -j DROP
COMMIT
$

서버시스템에 반영햇습니다.

$ 
$ cat ipt-drop-all-ANY-LOG.txt | sudo iptables-restore 
$

차단 패킷 현황를 확인했습니다.

$ 
$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 44 packets, 2480 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0000ff0001|" ALGO name bm FROM 40 TO 140 LOG flags 0 level 6 prefix "DROP ALL ANY :"
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0000ff0001|" ALGO name bm FROM 40 TO 140

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 24 packets, 2064 bytes)
 pkts bytes target     prot opt in     out     source               destination         
$

외부에서 ripe.net ANY 질의, ripe2.net ANY 질의, 123456789012345678901234567890.net ANY 질의를 했습니다.

모두 timeout 무응답 결과를 얻었습니다.

$ dig @10.0.2.15  ripe.net any +multi

; <<>> DiG 9.11.0b1 <<>> @10.0.2.15 ripe.net any +multi
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
$ 
$ 
$ dig @10.0.2.15  ripe2.net any +multi

; <<>> DiG 9.11.0b1 <<>> @10.0.2.15 ripe2.net any +multi
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
$ dig @10.0.2.15  123456789012345678901234567890.net any +multi

; <<>> DiG 9.11.0b1 <<>> @10.0.2.15 123456789012345678901234567890.net any +multi
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
$

서버 시스템에서 IPTables 차단현황을 확인했습니다.

총 9개의 패킷이 차단처리되었습니다. dig을 사용한 3번의 질의마다 3번까지 재시도한 패킷을 모두 차단한 결과입니다.

$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 118 packets, 5896 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    9   774 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0000ff0001|" ALGO name bm FROM 40 TO 140 LOG flags 0 level 6 prefix "DROP ALL ANY :"
    9   774 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0000ff0001|" ALGO name bm FROM 40 TO 140

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 89 packets, 9868 bytes)
 pkts bytes target     prot opt in     out     source               destination         
$

kernel 로그의 IPTables 로그를 확인했습니다. 9개의 패킷이 조건에 매칭되어 기록되어 있음을 확인할 수 있습니다.

$ grep 'DROP ALL ANY' /var/log/kern.log 
Dec 25 20:42:06 SLab1 kernel: [16446.292805] DROP ALL ANY :IN=enp0s3 OUT= MAC=08:00:27:79:7a:18:52:54:00:12:35:02:08:00 SRC=10.0.2.2 DST=10.0.2.15 LEN=77 TOS=0x00 PREC=0x00 TTL=64 ID=5545 PROTO=UDP SPT=50373 DPT=53 LEN=57 
Dec 25 20:42:09 SLab1 kernel: [16448.981337] DROP ALL ANY :IN=enp0s3 OUT= MAC=08:00:27:79:7a:18:52:54:00:12:35:02:08:00 SRC=10.0.2.2 DST=10.0.2.15 LEN=77 TOS=0x00 PREC=0x00 TTL=64 ID=5546 PROTO=UDP SPT=50373 DPT=53 LEN=57 
Dec 25 20:42:11 SLab1 kernel: [16451.149851] DROP ALL ANY :IN=enp0s3 OUT= MAC=08:00:27:79:7a:18:52:54:00:12:35:02:08:00 SRC=10.0.2.2 DST=10.0.2.15 LEN=77 TOS=0x00 PREC=0x00 TTL=64 ID=5547 PROTO=UDP SPT=50373 DPT=53 LEN=57 
Dec 25 20:43:06 SLab1 kernel: [16476.165277] DROP ALL ANY :IN=enp0s3 OUT= MAC=08:00:27:79:7a:18:52:54:00:12:35:02:08:00 SRC=10.0.2.2 DST=10.0.2.15 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=5566 PROTO=UDP SPT=56316 DPT=53 LEN=58 
Dec 25 20:43:09 SLab1 kernel: [16478.859418] DROP ALL ANY :IN=enp0s3 OUT= MAC=08:00:27:79:7a:18:52:54:00:12:35:02:08:00 SRC=10.0.2.2 DST=10.0.2.15 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=5567 PROTO=UDP SPT=56316 DPT=53 LEN=58 
Dec 25 20:43:11 SLab1 kernel: [16481.437451] DROP ALL ANY :IN=enp0s3 OUT= MAC=08:00:27:79:7a:18:52:54:00:12:35:02:08:00 SRC=10.0.2.2 DST=10.0.2.15 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=5568 PROTO=UDP SPT=56316 DPT=53 LEN=58 
Dec 25 20:43:30 SLab1 kernel: [16500.014931] DROP ALL ANY :IN=enp0s3 OUT= MAC=08:00:27:79:7a:18:52:54:00:12:35:02:08:00 SRC=10.0.2.2 DST=10.0.2.15 LEN=103 TOS=0x00 PREC=0x00 TTL=64 ID=5592 PROTO=UDP SPT=41649 DPT=53 LEN=83 
Dec 25 20:43:33 SLab1 kernel: [16502.931866] DROP ALL ANY :IN=enp0s3 OUT= MAC=08:00:27:79:7a:18:52:54:00:12:35:02:08:00 SRC=10.0.2.2 DST=10.0.2.15 LEN=103 TOS=0x00 PREC=0x00 TTL=64 ID=5593 PROTO=UDP SPT=41649 DPT=53 LEN=83 
Dec 25 20:44:06 SLab1 kernel: [16505.440390] DROP ALL ANY :IN=enp0s3 OUT= MAC=08:00:27:79:7a:18:52:54:00:12:35:02:08:00 SRC=10.0.2.2 DST=10.0.2.15 LEN=103 TOS=0x00 PREC=0x00 TTL=64 ID=5595 PROTO=UDP SPT=41649 DPT=53 LEN=83 
$

이로써 질의도메인이 무엇이든, ANY 타입의 질의를 모두 차단하는 룰셋을 작성해 보았습니다.

룰셋 하나로 다양한 형태의 ANY 질의를 차단할 수 있으므로, 보다 효과적인 방식이라 할 수 있습니다.

한계점 체크

ANY 타입 질의는 통상 IN 클래스를 사용합니다.

하지만, 공격에서 사용하는 질의메시지는 '만들어진 메시지'입니다. 즉, DNS 메시지 내의 모든 데이터를 마음대로 변경 조작하는 것이 가능합니다.

ANY 질의의 또 다른 형태가 가능합니다.

질의도메인 ANY ANY 형태입니다. 질의클래스로 IN이 아니라 대신에 ANY 클래스를 사용하는 것입니다.

ANY 클래스라니? 그런 것도 있어? 라고 의문을 가질 수 있습니다. ANY 클래스가 있습니다.

IANA의 "DNS CLASSes" 페이지를 보면, ANY 클래스가 정의되어 있는 것을 확인할 수 있습니다.

ANY 클래스의 코드값은 255 (0xff) 입니다.

ANY 클래스로 ANY 타입질의를 하면 도메인이름의 IN (Internet), CH (Chaos) 등의 여러 클래스에 설정된 모든 레코드를 "한번에" 조회할 수 있습니다.

현재 DNS에서는 IN 클래스 외에 다른 클래스는 쓰이지 않고 있어 실제 그 유용성은 없다고 볼 수 있습니다.

그러나, 표준으로 처리하도록 규정되어 있는 ANY 클래스에 대한 처리는 공격의 우회통로로 악용될 수 있습니다.

ripe.net ANY IN 질의는 차단되고 있는 상태에서, ripe.net ANY ANY 질의를 해 보았습니다.

dig에서는 ANY 클래스는 class255 ( 또는 -c any )로 표기해 주어야 합니다.

질의 결과, IPTables 차단 룰셋에 의해 차단되지 않고 그대로 통과하여 정상처리 응답되고 있습니다.

 
$ dig @10.0.2.15 ripe.net any class255 +noall +comment +stats

; <<>> DiG 9.11.0b1 <<>> @10.0.2.15 ripe.net any class255 +noall +comment +stats
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63848
;; flags: qr rd ra; QUERY: 1, ANSWER: 25, AUTHORITY: 7, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 52138f02ff3b7898f761a81458440a48ad91570c11ef5714 (good)
;; Query time: 734 msec
;; SERVER: 10.0.2.15#53(10.0.2.15)
;; WHEN: Sun Dec 25 21:21:33 KST 2016
;; MSG SIZE  rcvd: 2855

$

보완이 필요합니다.

ANY질의 ANY 클래스인 질의 경우를 차단하는 룰셋을 추가 하는 것입니다.

-A INPUT -p udp --dport 53 -m string --algo bm --from 12 --to 112 --hex-string "|00 00 ff 00 ff|" -j DROP

서버 시스템에 반영하기 위한 IPTables 룰셋을 고쳐 작성한 내용입니다.

$ 
$ cat ipt-drop-all-ANY-LOG.txt 
*filter
:INPUT ACCEPT 
:FORWARD ACCEPT 
:OUTPUT ACCEPT
-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 140 --hex-string "|00 00 ff 00 ff|" -j LOG --log-prefix "DROP ALL ANY ANY :" --log-level info
-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 140 --hex-string "|00 00 ff 00 ff|" -j DROP
-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 140 --hex-string "|00 00 ff 00 01|" -j LOG --log-prefix "DROP ALL ANY IN  :" --log-level info
-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 140 --hex-string "|00 00 ff 00 01|" -j DROP
COMMIT
$

다시 ripe.net ANY ANY 질의를 한 결과, 이번에는 차단되어 무응답 결과를 얻었습니다.

하다보니 룰셋항목 개수가 많아졌습니다. 복잡해 보입니다.

-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 140 --hex-string "|00 00 ff 00 ff|" -j DROP

-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 140 --hex-string "|00 00 ff 00 01|" -j DROP

이 2개 차단 룰셋의 매칭조건을 "|00 00 ff 00|" 하나로 변경하면 하나의 차단 조건으로 작성하는 것이 가능합니다.

2개의 차단용 매칭조건에 공통되는 조건을 사용하는 것입니다.

매칭조건이 짧아졌다는 것은 매칭 오류 경우가 발생할 확률이 높아질 수 있음을 의미합니다.

질의내용이 아닌 다른 부분(DNS OPT 레코드)에 우연히 "|00 00 ff 00|" 형태를 갖는 바이너리 데이터가 포함되는 경우가 이에 해당합니다.

이런 경우가 발생하면, ANY 질의가 아님에도 불구하고 차단처리되는 DNS질의가 발생할 수 있습니다.

매칭 오류 경우를 최대한 줄이기 위해서는 별도의 매칭 조건을 부가할 필요가 있을 수 있습니다. (이에 대해서는 다른 기회에 다루기로 합니다.)

IPTables 내용을 다시 작성했습니다.

$ 
$ cat ipt-drop-all-ANY-LOG.txt 
*filter
:INPUT ACCEPT 
:FORWARD ACCEPT 
:OUTPUT ACCEPT
-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 140 --hex-string "|00 00 ff 00|" -j LOG --log-prefix "DROP ALL ANY IN  :" --log-level info
-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 140 --hex-string "|00 00 ff 00|" -j DROP
COMMIT
$

이 조건으로 모든 종류의 UDP ANY 질의를 차단할 수 있습니다.

다만, ANY 질의가 아님에도 불구하고 <00 00 ff 00> 패턴이 엉뚱한 곳에서 나타나 매칭되는 바람에 잘못 차단되는 경우를 방지하는 장치를 부가해 줄 필요가 있습니다.

IPTables, DNS 패킷 차단 설정 방법 모색 (1)

승홍 — Sat, 17 Dec 2016 13:33:25 +0900

DNS 질의 트래픽을 질의한 도메인이름, 질의타입을 기준으로 선별, 차단하는 방법은 없을까?

요즘 네임서버에 유입되는 DNS 질의 중에는 보안공격과 연관된 것으로 의심되는 각종 질의가 포함되어 있습니다.

어떤 경우는 차단이 필요하다고 여겨지지만, 마땅한 방법이 없는 경우도 있습니다.

특정 IP 주소에서만 공격성 질의가 발생한다면, 해당 IP주소 기준으로 차단하는 것은 그리 어렵지 않습니다.

라우터 ACL, 방화벽, 서버 IPTables의 단순한 설정을 사용할 수 있습니다.

그러나 불특정 IP주소에서 공격성 질의가 발생하는 경우는 대응이 달라져야 합니다.

IP주소 대신 질의된 도메인이름과 질의타입을 기준으로 선별 차단해야 한다면, DNS 질의 메시지 내용을 분석하여 차단해야 합니다.

즉 어플리케이션 계층(L7)에서 선별하여 차단하는 기능이 필요합니다.

여기서는 리눅스 시스템의 IPTables/Netfilter를 사용하여 특정 질의도메인/질의타입 DNS 유입 패킷을 차단방법을 기본 원리 중심으로 검토해 봅니다.

IPTabbles를 사용하는 것만이 유일한 해법이라고 할 수는 없습니다.

기능이 제한적이긴 하지만, 현재 일부 네임서버가 구현하고 있는 RPZ(Response Policy Zones) 기능을 활용해 보는 방법도 있습니다.

최근에는 인터넷 표준 측면에서 네임서버가 공격과 관련된 특정 DNS질의를 차단 할 수 있는 기능을 구현할 수 있도록 표준안 작업을 하고 있기도 합니다.

DNS 메시지 구조

질의도메인과 질의타입을 기준으로 선별하여 차단하려면, 먼저 DNS 메시지 구조를 알아둘 필요가 있습니다.

DNS 메시지 패킷은 < IP헤더 | UDP헤더 | DNS 메시지 >로 구성됩니다.

아래는 DNS 메시지 구조도입니다. UDP를 사용하는 DNS 메시지 경우로써, UDP 헤더 이후의 DNS 부분입니다.

DNS 메시지는 크게 DNS헤더 부분, 그리고 나머지 DNS 레코드가 채워지는 4개의 섹션으로 구분됩니다.

이 중에서 이번에 주목할 부분은 DNS헤더와 Question 섹션입니다.

'DNS질의'에서 '질의도메인(QNAME)'과 '질의타입(QTYPE)'을 기준으로 선별하는 방법이 필요합니다.

'DNS질의' 메시지 판별 기준

'DNS질의' 메시지인지 여부는 위 그림 중 QR 필드값으로 판별할 수 있습니다.

DNS 메시지 내에서 특정 필드 위치를 표시하는 방식으로 DNS[offset] 방식을 사용하기로 합니다.

DNS 메시지의 첫번째 바이트 위치(offset)를 0으로 정하면, DNS 메시지의 첫번째 바이트는 DNS[0]으로 표시합니다.

QR 필드가 속한 1개 바이트 위치는 DNS[2]입니다.

DNS[2] & 0x80 == 0x00 이면 'DNS질의' 메시지라고 판단할 수 있습니다.

DNS[2]는 DNS[0], DNS[1]의 2개 바이트인 DNS ID 다음에 오는 1개 바이트를 의미합니다.

0x80은 16진수 표현으로써, DNS[2] 1개 바이트 8비트 값 중에서 첫번째 비트인 QR 플래그 비트만 세팅한 값입니다.

DNS[2] 값에 0x80(QR bit)로 매스킹(&)한 결과 값이 0x80과 동일하면 DNS[2]의 QR 비트는 1로 세팅되어 있다는 의미입니다. 이 경우 'DNS응답' 메시지입니다. 그렇지 않고 이 값이 0이라면, QR 비트는 0으로 클리어된 상태이면, 이는 'DNS질의' 메시지임을 뜻합니다.

이에 더하여 DNS헤더의 Opcode 필드값도 함께 체크할 필요성이 있습니다. DNS Opcode는 DNS 메시지가 질의응답(Query) 메시지인지, 존 데이터의 변동을 알리는 Notify 메시지인지, DNS 동적업데이트 메시지(Update) 인지 여부를 표시합니다. Opcode 코드 값 전체 리스트는 IANA의 'DNS OpCodes' 페이지에 게재되어 있습니다.

DNS 질의응답 용 Opcode는 0 (0x00) 입니다.

따라서 Opcode까지 포함하여 DNS 질의메시지 여부를 판별하는 조건은 DNS[2] & 0xf8 == 0x00 이 됩니다. 0xf8 은 첫번째 비트(QR flag)와 이후 연속한 4개 비트(Opcode) 값를 매스킹하는 16진수 값입니다. 매스킹 처리한 결과이 0이 되면 QR flag가 0이고, Opcode 도 0인 경우입니다.

이 방법은 세밀하고 정확한 조건을 지정할 수 있는 장점을 지니지만, IPTables 룰셋으로 '간단하게' 표현하기에는 다소 어려움이 있습니다. IPTables의 U32 확장모듈과 같이 정밀한 필드값 검사기능을 사용하여 설정하는 것이 필요합니다. U32 확장모듈을 사용한 설정은 후에 다루기로 합니다.

네임서버에 유입되는 DNS 질의응답 트래픽이 단순한 형태라면, 대신에 'UDP 착신포트가 53일때' 라는 '대략적인' 조건을 사용할 수 있습니다.

'질의도메인' 식별 기준

'질의도메인'은 Question 섹션의 첫부분에 자리하고 있습니다. DNS헤더의 바로 다음입니다.

Question 섹션은 DNS[12]부터 시작합니다. DNS헤더가 항상 12바이트 길이를 가지므로, DNS 메시지 첫 바이트 이후의 12번째 바이트가 Question 섹션의 시작 바이트입니다.

Question 섹션의 '질의도메인' 길이는 미리 알 수 없습니다. 도메인이름은 IP 패킷의 DNS 메시지에서는 특별한 형태를 가진 가변 필드이기 때문입니다.

이 특성 때문에 각각의 DNS메시지를 '질의도메인' 기준으로 판별 차단하는 기능을 이용에 편리하도록 구현하는 것이 상당히 어렵습니다.

구체적인 사례로써 'ripe.net'이라는 도메인이름 경우를 살펴봅니다.

도메인이름 'ripe.net'은 IP 패킷의 DNS 메시지에서는 < 4 | ripe | 3 | net | 0 >의 값으로 설정됩니다.

'ripe', 'net'은 레이블(label) 입니다. 도메인이름은 레이블이 연속으로 이루어져 있습니다.

'ripe'는 4개 문자(바이트), 'net'은 3개 문자(바이트)를 가집니다. 여기에서 4, 3은 각 레이블 앞에 오는 len 필드 값이 됩니다.

< len | label#1 | len | label#2 | ... | len | label#n | 0 > 에서 마지막 남은 < 0 > 값은 루트 도메인(.)을 의미합니다. 루트 도메인은 특수한 도메입니다. 루트 도메인 이름은 0개 문자로 된 레이블 갖습니다. 그래서 이를 IP 패킷에서 동일한 규칙에 따라 표현하면 < 0 > 이 됩니다. 이를 달리 표현하면, 루트 도메인 이름은 "이름이 없는 도메인이름"이라 할 수 있습니다.

< len | 문자열 >로 표현하는 방식은 문자열을 표현하는 데이터 구조 방식 중 하나입니다.

문자열은 여러 개의 문자로 이루어지고 그 길이를 미리 알 수 없는 가변길이 데이터입니다. 그래서 문자열을 다루려면 '길이' 정보가 필요합니다.

< len | 문자열 > 의 표현방식은 문자열 데이터의 첫번째 바이트가 문자열 길이 값을 가지고, 이 길이 만큼의 나머지 데이터가 '문자열' 값을 가진다는 것을 의미합니다. 도메인이름은 이와 같은 문자열 표현 방식을 따르고 있습니다.

< len | 문자열 > 표현방식은 표현할 수 있는 문자열 개수에 한계가 있습니다. len이 1개 바이트일 때, 1개 바이트가 표현할 수 있는 최대 길이는 0xff = 255입니다. 따라서 255개 문자를 초과하는 문자를 가진 문자열은 이 방식으로 표현할 수 없습니다.

이에 반하여 C 언어에서는 문자열을 < 문자열 | 0 >이라는 형식으로 표현 합니다. 맨 마지막에 특수한 null 문자(0x00)를 붙임으로써 문자열의 끝을 표시하는 것으로 정의하여 사용합니다. 문자열 길이는 문자열 첫부분부터 null문자 이전까지 문자(바이트) 개수를 별도로 세어 파악할 수 있습니다.

C언어의 문자열 표현방식에서는 원칙적으로 문자열의 길이에 제한이 없습니다. 문자열 처음지점부터 0x00(null) 문자에 이르는 모든 데이터가 문자열이 됩니다. 그러나 문자열 데이터 끝의 0x00(null)의 설정처리가 제대로 되어 있지 않을 경우 심각한 시스템 에러를 유발하는 단점이 있습니다.

만일 'ripe.net'으로 질의하는 DNS 메시지를 검출하려면, Question 섹션 첫바이트 값은 4, 그 이후 4개 바이트는 'ripe', 그 다음 바이트 값은 3, 이후의 3개 바이트는 'net', 그리고 이 다음 마지막 바이트 값은 0 이어야 합니다.

Question 섹션의 첫바이트는 DNS[12]이므로 ( DNS[12] 부터 10개 바이트 영역 ) == < 4 | ripe | 3 | net | 0 > 이면 ripe.net을 질의하는 DNS 메시지라고 판단할 수 있습니다. 여기서 '10개 바이트 영역'은 < 4 | ripe | 3 | net | 0 >이 차지하는 바이트 영역을 의미합니다. 세어보면 10개 바이트를 차지하고 있습니다.

'질의타입' 식별 기준

'질의타입' 값은 '질의도메인' 바로 다음의 2바이트 필드에 설정됩니다.

질의타입 A는 'A'라는 문자로 설정되는 것이 아니라, 숫자 코드값 1로 설정됩니다.

DNS 질의타입은 표준으로 정해집니다. 전체 질의타입 코드 리스트는 IANA의 "Resource Record Types" 페이지에 게재되어 있습니다.

여기서는 'ANY' 질의를 차단한다고 가정합니다.

이전에 DNS증폭 DDoS 공격이 'ripe.net' 등에 대한 ANY 질의를 주로 사용하고 있었기에 이들 도메인에 대한 ANY 질의차단의 필요성이 있었습니다.

ANY 질의의 질의코드 값은 255입니다. 16진수 값으로는 0x00ff입니다. 질의필드는 2바이트이기에 ANY 질의코드는 2바이트 값 0x00ff로 표현됩니다.

'질의타입' 값을 검사하려 할 때 '질의타입' 필드 위치는 '질의도메인'이 무엇인지에 따라 달라집니다. '질의도메인' 필드길이가 가변적이기에 그 다음에 오는 '질의타입' 필드의 위치 역시 가변적입니다.

그렇기에 '질의도메인'과 '질의타입' 값은 함께 검사하는 것이 필요합니다.

예로써, 'ripe.net'에 대해 'ANY'를 질의하는 DNS 질의메시지를 차단한다고 가정한다면, 다음과 같이 검사합니다.

( DNS[12] 부터 12개 바이트 영역 ) == < 4 | ripe | 3 | net | 0 | 0 | 255 > 이 일치한다면, 이 DNS질의 메시지는 'ripe.net'의 ANY 질의라고 판단합니다.

IPTables 차단 룰셋 작성하기

그러면, 이것을 IPTable에 설정하는 구체적인 방법은 어떻게 될까요?

여러 가지 방법이 있을 수 있습니다. 그 중에서 되도록 단순한 방법을 사용하여 작성하는 사례를 보이도록 하겠습니다.

IPTables는 IP 패킷을 검사하는 다양한 방식을 여러 모듈로 제공하고 있습니다.

이 중에 STRING 모듈이 있습니다.

우선 STRING 모듈을 사용하여 유입되는 UDP DNS 메시지 중 ripe.net ANY 질의 메시지를 차단하는 룰셋을 아래와 같이 작성할 수 있습니다.

( DNS[12] 부터 12개 바이트 영역 ) == < 4 | ripe | 3 | net | 0 | 0 | 255 > 의 매칭 조건을 IPTables의 STRING 모듈이 요구하는 문법에 따라 작성하면 다음과 같습니다.

-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 52 --hex-string "|04|ripe|03|net|00 00 ff|" -j DROP

UDP를 사용하여 53 포트로 착신하는 ( -p udp --dport 53) 패킷에 대해서 STRING 모듈( -m string )을 적용한 매칭 조건에 일치하는 경우 패킷을 차단하는 룰셋을 작성하였습니다.

STRING 모듈의 매칭조건 인자설정 세부사항은 다음과 같습니다.

STRING 모듈이 제공하는 문자열 매칭 알고리듬 중에서 bm(Boyer-Moore) 알고리듬을 사용합니다 ( --algo bm ).

IP 헤더의 첫 바이트 기준으로 40 바이트 떨어진 지점부터 IP 헤더 첫 바이트에서 52번째 바이트 이전 범위 내에서 패턴 매칭을 시도합니다 ( --from 40 --to 52 ).

40 바이트는 IP 헤더를 기준한 DNS 메시지의 Question Section 시작 지점으로써, 20 (IP헤더 기본 길이) + 8 (UDP헤더 고정 길이) + 12 (Question Section 시작지점) = 40 바이트로 계산됩니다. IP헤더 옵션이 달릴 경우 IP헤더 길이는 더 길어질 수 있지만, IP헤더 최소 길이 20바이트를 기준으로 계산합니다. UDP헤더는 항상 8 바이트 길이를 가집니다. DNS 메시지 내에서 12바이트 지점에서 Question Section이 시작되므로 12바이트를 더합니다.

52바이트는 40바이트 지점에서 12바이트 떨어진 지점으로써, 40 +12 = 52 바이트로 계산됩니다.

매칭검사 범위를 이와 같이 IP헤더 첫바이트에서 40 바이트 ~ 52바이트 사이 영역으로 한정시키는 경우, IP옵션이 달린 IP헤더가 사용되면 검출에 실패할 수 있습니다.

IP헤더 옵션 길이만큼 DNS Question 섹션영역 범위가 밀려서 그 위치가 변동되기 때문입니다.

그러나 IP헤더 옵션은 사용되는 경우가 거의 없어서 이러한 매칭검사 실패가 발생할 확률은 아주 적어서 별 문제가 되지는 않는다고 할 수는 있습니다.

IP헤더 옵션이 있는 경우까지 고려한는 경우, 검사대상 영역의 끝지점인 52바이트 값을 좀 더 늘려서 52 + 40 = 92 바이트 정도로 설정할 수도 있습니다.

IP헤더 길이는 최소 20바이트 ~ 최대 60바이트까지 가능하므로 IP헤더 옵션이 40바이트 길이까지 부가되는 경우를 고려할 때 그렇게 설정할 수 있습니다.

도메인이름 ripe.net과 ANY 질의타입(0x00ff)이 여기에 연이어 지정되어 있는지 검사합니다 ( --hex-string "|04|ripe|03|net|00 00 ff|" ).

이 조건에 부합하는 경우, 패킷을 차단합니다 ( -j DROP )

여기에서 --hex-string 설정문에 대해서는 좀 자세히 살펴 볼 필요가 있습니다.

--hex-string 옵션은 바이너리 데이터에 대한 16진수 표현과 문자열 표현을 혼용하여 매칭 조건을 설정하는 용도의 옵션입니다.

"|04|ripe|03|net|00 00 ff|" 에서 16진수표현 부분은 '|' 구분자로 구분하여 일반 문자열 내용과 서로 혼동되지 않도록 설정합니다.

'|04|'은 다음 레이블 길이를 나타내는 숫자 4입니다. 16진수 표현으로 1개 바이트 값인 0x04입니다. '|04|'은 0x04을 구분자 '|'를 사용하여 표현한 것입니다.

이후의 '|03|' 은 동일하게 'net' 레이블 길이 값을 설정한 16진수입니다.

ripe, net 은 일반 문자열입니다. 이 부분은 문자열 그대로 설정합니다.

끝 부분의 '|00 00 ff|' 은 도메인 이름의 마지막 1바이트, 곧 루트 도메인이름인 1바이트 값 0x00 과 'A 질의타입' 2바이트 값인 0x00ff을 연이어 16진수로 표현한 것입니다.

서버 시스템 적용 & 확인

서버 시스템에 적용하고 원하는 대로 동작하는지 확인합니다.

아래와 같이 IPTables 룰셋 설정파일을 작성합니다.

$
$ cat ipt-drop-ripe.net-ANY.txt 
*filter
:INPUT ACCEPT 
:FORWARD ACCEPT 
:OUTPUT ACCEPT
-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 52 --hex-string "|04|ripe|03|net|00 00 ff|" -j DROP
COMMIT
$

서버 시스템에 iptables로 적용합니다.

$ 
$ cat ipt-drop-ripe.net-ANY.txt | sudo iptables-restore 
$

iptables로 상태를 확인합니다.

룰셋 항목의 pkts와 bytes는 아직 0 인 상태입니다.

$ 
$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 106 packets, 13066 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0472697065036e65740000ff|" ALGO name bm FROM 40 TO 52

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 104 packets, 9434 bytes)
 pkts bytes target     prot opt in     out     source               destination         
$

이 서버 시스템의 외부에서 ripe.net에 대한 ANY 질의를 합니다.

질의 결과, timeout 무응답 오류가 발생합니다.

$
$ dig @10.0.2.15 ripe.net ANY +multi

; <<>> DiG 9.11.0b1 <<>> @10.0.2.15 ripe.net ANY +multi
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
$

룰셋을 적용한 서버에서 iptables로 상태를 확인합니다.

룰셋항목의 pkts와 bytes 값이 각각 3, 231로 증가했습니다.

dig 유틸리티는 시도 후 무응답 오류가 발생하면 default로 3번 재시도합니다. 그래서 pkts 값이 0 --> 3으로 증가했습니다.

$
$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 133 packets, 14298 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    3   231 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 STRING match  "|0472697065036e65740000ff|" ALGO name bm FROM 40 TO 52

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 127 packets, 12038 bytes)
 pkts bytes target     prot opt in     out     source               destination         
$

지정된 조건의 DNS질의 패킷이 차단되기 직전에 로그파일에 로그를 남기면 좋을 것 같습니다.

동일한 조건에 일치할 때 로그를 남기도록 추가해 봅니다.

$ 
$ cat ipt-drop-ripe.net-ANY-LOG.txt
*filter
:INPUT ACCEPT 
:FORWARD ACCEPT 
:OUTPUT ACCEPT
-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 52 --hex-string "|04|ripe|03|net|00 00 ff|" -j LOG --log-prefix "DROP RIPE.NET ANY :" --log-level info
-A INPUT -p udp --dport 53 -m string --algo bm --from 40 --to 52 --hex-string "|04|ripe|03|net|00 00 ff|" -j DROP
COMMIT
$

LOG는 로그를 기록처리하면서 해당 패킷 처리를 종료하지 않고 다음 순서의 룰셋 적용으로 절차를 넘겨줍니다.

따라서 이 패킷은 로그처리를 한 후 다음 순서의 룰셋에서 조건에 일치하여 DROP 처리됩니다.

사실 이러한 방식의 설정은 비효율적이라 할 수 있습니다. 동일한 매칭조건 검사를 2번 반복해야 합니다. 효율적인 매칭조건 검사를 위해 IPTables의 MARK 모듈을 사용할 수 있습니다.

서버 시스템에 적용한 후 로그를 체크한 결과입니다. dig을 사용하여 외부에서 서버로 ripe.net ANY를 질의했을 때 다음과 같이 로그가 남겨집니다.

$ 
$ tail -f /var/log/kern.log | grep 'RIPE.NET ANY'
Dec 11 13:27:14 SLab1 kernel: [ 1235.268966] DROP RIPE.NET ANY :IN=enp0s3 OUT= MAC=08:00:27:79:7a:18:52:54:00:12:35:02:08:00 SRC=10.0.2.2 DST=10.0.2.15 LEN=77 TOS=0x00 PREC=0x00 TTL=64 ID=3649 PROTO=UDP SPT=45379 DPT=53 LEN=57 
Dec 11 13:27:17 SLab1 kernel: [ 1238.068522] DROP RIPE.NET ANY :IN=enp0s3 OUT= MAC=08:00:27:79:7a:18:52:54:00:12:35:02:08:00 SRC=10.0.2.2 DST=10.0.2.15 LEN=77 TOS=0x00 PREC=0x00 TTL=64 ID=3652 PROTO=UDP SPT=45379 DPT=53 LEN=57 
Dec 11 13:27:20 SLab1 kernel: [ 1241.114650] DROP RIPE.NET ANY :IN=enp0s3 OUT= MAC=08:00:27:79:7a:18:52:54:00:12:35:02:08:00 SRC=10.0.2.2 DST=10.0.2.15 LEN=77 TOS=0x00 PREC=0x00 TTL=64 ID=3655 PROTO=UDP SPT=45379 DPT=53 LEN=57 
^C
$

dig에 의해 3번 시도된 패킷 3개가 모두 차단되었습니다.

IPTables에 지정된 LOG 동작으로 남겨지는 로그는 kernel 로그 파일에 기록됩니다.

ripe.net ANY 질의는 차단되지만, ripe.net A 질의는 정상적으로 처리되어 응답됩니다.

$
$ dig @10.0.0.15 ripe.net A +multi

; <<>> DiG 9.11.0b1 <<>> @10.0.0.15 ripe.net A +multi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7011
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 15

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 9e034752013b5bab3bad14c75843a2e9f0eb1504e94721ca (good)
;; QUESTION SECTION:
;ripe.net.IN A

;; ANSWER SECTION:
ripe.net.21547 IN A 193.0.6.139

;; AUTHORITY SECTION:
ripe.net.3547 INNS a2.verisigndns.com.
ripe.net.3547 INNS manus.authdns.ripe.net.
ripe.net.3547 INNS a1.verisigndns.com.
ripe.net.3547 INNS sns-pb.isc.org.
ripe.net.3547 INNS sec3.apnic.net.
ripe.net.3547 INNS tinnie.arin.net.
ripe.net.3547 INNS a3.verisigndns.com.

;; ADDITIONAL SECTION:
a1.verisigndns.com.3547 INA 209.112.113.33
a2.verisigndns.com.3547 INA 209.112.114.33
a3.verisigndns.com.3547 INA 69.36.145.33
sec3.apnic.net.172747 IN A 202.12.28.140
manus.authdns.ripe.net.3547 INA 193.0.9.7
sns-pb.isc.org.7147 INA 192.5.4.1
tinnie.arin.net.172747 IN A 199.212.0.53
a1.verisigndns.com.3547 INAAAA 2001:500:7967::2:33
a2.verisigndns.com.3547 INAAAA 2620:74:19::33
a3.verisigndns.com.3547 INAAAA 2001:502:cbe4::33
sec3.apnic.net.172747 IN AAAA 2001:dc0:1:0:4777::140
manus.authdns.ripe.net.3547 INAAAA 2001:67c:e0::7
sns-pb.isc.org.7147 INAAAA 2001:500:2e::1
tinnie.arin.net.172747 IN AAAA 2001:500:13::c7d4:35

;; Query time: 1 msec
;; SERVER: 10.0.0.15#53(10.0.0.15)
;; WHEN: Sun Dec 11 14:00:28 KST 2016
;; MSG SIZE  rcvd: 562

$

한계점

이로써 특정 질의도메인과 질의타입을 갖는 패킷을 골라 차단하는 설정을 보았습니다.

하지만 실제 적용할 때, 위에 제시된 방법만으로는 적용에 한계가 있습니다.

질의도메인 개수가 아주 많을 경우, 그 개수 만큼 일일이 IPTables 룰셋으로 작성해서 설정해야 하는 문제점이 있습니다.

IPTables의 룰셋 개수가 질의도메인 개수만큼 많아지고, 그러면 아무래도 DNS 패킷 검사에 소요되는 부하도 증가합니다.

특정 질의타입의 DNS 메시지 패킷을 질의된 도메인에 상관없이 모두 차단하려면?

예를 들어 ANY 질의하는 모든 DNS 패킷을 차단하려고 할 때, 질의하는 도메인의 길이를 미리 알 수 없으므로 '질의타입' 필드위치를 정할 수 없는 문제가 있습니다. 각각의 DNS질의 메시지에서 '질의타입' 필드의 위치는 질의된 도메인 길이에 따라 상시 달라지기 때문입니다.

IPTables 사용한 DNS 매칭조건 설정 방법을 더 확장해 볼 필요성이 있습니다.

Q. SOA 레코드 필드 값은 어떤 기준으로 어떻게 설정해야 하나?

승홍 — Fri, 11 Dec 2015 21:12:00 +0900

Q. SOA 레코드는 왜 있는 건가요?

A. SOA 레코드는 필수 레코드입니다. SOA레코드는 도메인 영역을 표시하는 역할을 합니다. 또 네임서버에게 어떤 기준에 의해 이 도메인을 관리하여야 하는지 알려주는 역할을 합니다.

SOA 레코드는 도메인 존 파일 작성에서 반드시 작성해야 하는 레코드입니다. 이것은 표준 사항인 동시에 인터넷 도메인 이름(domain name) 체계의 기본 원칙에 관련된 사항입니다.

SOA 레코드는 이 도메인 영역이 구분된 관리영역을 갖는 독립적인 도메인 존(zone)임을 표시해 줍니다.

예를 들어 도메인 이름 tistory.com에 SOA 레코드가 설정되어 있으면, 인터넷 전체 도메인 영역 중 tistory.com 이름 이하의 도메인 영역(zone)은 독자적인 관리주체에 의해 관할 관리되는 영역임을 알 수 있습니다. 즉, com 도메인 영역에 속하기는 하지만 com 영역관리 주체와는 다른 주체에 의해서, 또는 별도의 독자적인 관리정책으로 tistory.com 이하의 내부 영역이 관리되고 있음을 표시합니다.

만일 SOA 레코드가 누락된 도메인 존 파일을 네임서버에 반영시키려 하면, 네임서버는 에러 로그를 몇 줄 남기고 처리하지 않고 무시해 버립니다. 네임서버가 지나치게 깐깐해서 그렇게 무시해 버리는 것은 아닙니다. 네임서버 입장에서는 SOA 레코드가 누락된 도메인 존을 ‘어떻게 관리해야 하는지 도무지 알 수가 없기 때문’에 아예 처음부터 반영하지 않음으로써 문제발생을 미연에 방지하려는 것일 뿐입니다.

SOA 레코드는 이 도메인 존(zone)으로 별도로 구분된 도메인 영역이며 이 도메인 영역은 이러이러한 기준으로 관리되어야 한다고 “네임서버에게” 알려주는 정보를 담고 있습니다. 이때 “네임서버”는 마스터 네임서버, 슬레이브 네임서버는 물론, 캐시DNS서버까지 포함하는 모든 네임서버를 지칭합니다.

SOA 레코드는 “Start Of Authority”의 약자입니다. 여기서 Authority는 관리권한을 의미하는 것으로 번역할 수 있습니다. 관리권한이 시작되는 곳으로 도메인 존 영역의 시작점을 의미합니다. 이 지점부터는 관리영역이 나뉘어 지는 것을 표시합니다. 한마디로 쉽게 말하자면 “영역 표시” 역할입니다. “여기부터는 내가 관할하는 영역이다”라는 표시를 SOA 레코드가 해 줍니다.

크게 보면, Domain Name System(DNS) 체계는 루트 도메인(.)이 전체 도메인 영역을 대표하고 그 내부에 다시 도메인 영역들을 분할하여 각자 알아서 분할된 영역을 관리하는 방식으로 구성되어 있습니다. 나누어진 각 도메인 영역을 표시하는 수단이 SOA 레코드입니다. 도메인 존(domain zone)은 SOA 레코드에 의해 그 영역의 범위가 구체적으로 규정됩니다.

도메인에 서브 도메인을 두어 하위 영역을 분할하는 경우, 즉 도메인을 위임(delegation)하는 경우, NS레코드(글루레코드)로 해당 서브 도메인(또는 자식 도메인)이 소재한 네임서버를 지정해 주고, 서브 도메인의 마스터 네임서버에서는 이 서브 도메인 이름에 대해 “반드시” SOA 레코드를 설정해야 합니다. 위임(delegation)이라는 것은 일정 도메인 영역의 관리권한을 위임한다는 의미이고, 이렇게 위임받은 주체는 독자적인 관리정책으로 그 도메인 영역을 관리하게 됩니다. 이때 그 관리정책 중 네임서버가 알아야 할 도메인 존의 관리정책을 DNS 레코드로 표현한 것이 바로 SOA 레코드입니다.

Q. SOA 필드 값은 어떤 기준으로 작성해야 하나요?

A. 이러이러한 값으로 꼭 설정해야 한다고 정해진 특별한 값은 없습니다. 자신의 인터넷 서비스 특성과 운영방식을 고려해서 정하면 됩니다. 하지만 몇 가지 주요하게 고려해야 할 사항은 있습니다.

먼저 SOA 레코드의 구체적인 사례를 보면 다음과 같습니다. 가장 만만해 보이는(?) 여기 티스토리의 SOA 레코드 경우를 선택해 보았습니다.

$ dig tistory.com soa +multi +noall +answer 
; <<>> DiG 9.9.5-9ubuntu0.3-Ubuntu <<>> tistory.com soa +multi +noall +answer 
;; global options: +cmd 
tistory.com. 600 IN SOA ns.daumzone.com. hostmaster.daum.net. ( 
                     2015090300 ; serial 
                     2700       ; refresh (45 minutes) 
                     900        ; retry (15 minutes) 
                     604800     ; expire (1 week) 
                     3600       ; minimum (1 hour) 
                     ) 
$

SOA 레코드가 가지는 필드는 그 순서에 따라 개괄하면 다음과 같습니다. 필드명은 표준 명칭을 기준합니다.

용도 구분	SOA 필드 명칭	개요
마스터 네임서버 표시	mname	‘master name’의 약자 마스터 네임서버의 도메인 이름을 설정함
존 관리자 연락처 표시	rname	‘responsible name’의 약자 도메인 존 관리자/담당자의 e-mail 주소를 도메인이름 형식으로 표현하여 설정
존 데이터 동기화 관리기준	serial	도메인 존의 갱신 버전번호 정보 설정
	refresh	도메인 존을 갱신하는 주기 시간을 초단위로 설정
	retry	도메인 존 갱신여부 확인에 실패한 경우, 재시도 주기 시간을 초단위로 설정
	expire	도메인 존 갱신이 실패하여 도메인에 대한 DNS질의응답을 중단해야 하는 기간을 초단위로 설정
존에 없는 레코드의 TTL 값	minimum	존에 없는 도메인/레코드 응답 경우, 이 도메인/레코드(부재 도메인/레코드) 부재정보의 캐싱에 적용하는 TTL 값

SOA 필드의 용도 구분을 먼저 보면, 위 표에서 보는 바와 같이 대략 4개로 구분할 수 있습니다.

이 중에서 존 관리자 연락처를 표시하는 rname 필드를 제외한 나머지 필드들은 네임서버에게 알려주어야 할 "이 도메인 존을 어떤 기준으로 관리해야 하는가"에 대한 정보를 담고 있습니다. 캐시DNS서버를 위한 필드인 minimum 필드를 제외한 mname, serial, refresh, retry, expire 필드는 마스터 네임서버와 슬레이브 네임서버가 참조하는 필드입니다.

mname 필드는 이 도메인 존의 마스터 네임서버 도메인 이름을 설정합니다. 한마디로, 도메인 존(zone)이 “어디에 본거지를 두고 있는지”를 표시합니다. 마스터 네임서버가 도메인 존의 마스터 존 데이터를 가지고 있습니다. 이 마스터 네임서버의 도메인 이름을 설정합니다. SOA mname 필드에 설정된 마스터 네임서버 정보를 제외하고는, 외부에서 어떤 도메인의 여러 네임서버 중 어느 것이 마스터인지 어느 것이 슬레이브인지를 구분하는 방법은 따로 없습니다.

mname 필드값은 네임서버의 DNS Notify 처리 절차에서 참조되므로, 도메인 존에 대한 네임서버의 존 전송 관리에 관련되어 있습니다.

티스토리 도메인의 SOA 사례에서 mname은 ‘ns.daumzone.com’으로 설정되어 있습니다. 이상하죠? tistory.com의 네임서버 리스트를 질의해 보면 ‘ns1.daum.net’과 ‘ns2.daum.net’만 네임서버로 설정되어 있습니다. 외부에서 질의하는 네임서버 중에는 마스터 네임서버가 없는 경우입니다. 이것을 “Hidden Master”라고 합니다. tistory.com의 마스터 네임서버 ‘ns.daumzone.com’은 숨겨진 마스터 네임서버(Hidden Master)입니다.

mname 필드에 마스터 네임서버를 지정하여야 하지만, 임의의 네임서버 이름을 설정하는 경우도 적지 않습니다. 다만, mname 필드에 마스터 네임서버가 아닌 서버를 설정했을 때 SOA mname 필드 정보를 이용하는 표준 DNS기능(DNS Notify, DNS Update 등)이 이상하게 동작할 수도 있습니다.

rname 필드는 이 도메인 존을 관리하는 담당자의 연락처를 도메인이름 형식로 설정합니다. 도메인과 관련하여 도메인 관리자에게 전자메일을 보내야 할 경우에 사용할 수 있는 담당자 전자메일 계정정보가 기재됩니다.

rname 필드 값의 형식은 도메인이름입니다. 전자메일 계정정보는 해당하는 도메인이름 형식으로 변환하여 rname 필드에 설정하도록 되어 있습니다. 예를 들어 admin@example.com이 담당자 전자메일 계정이라면 ‘admin.example.com’으로 설정합니다. 규칙을 단순하게 말하자면, ‘@’문자를 ‘.’으로 대체하는 방식입니다.

만약 설정하고자 하는 전자메일 계정이 ‘dns.admin@example.com’이라면? 도메인 존 파일에 메일계정 사용자 아이디에 포함된 ‘.’을 문자 그대로 해석하도록 escape문자 ‘\’을 사용해서 ‘dns\.admin.example.com’이라고 표기해야 합니다. rname에 설정한 도메인 이름의 첫번째 레이블 ‘dns\.admin’은 전자메일 계정의 사용자 아이디로 설정하도록 약속되어 있습니다.

만약 rname 필드를 비워두고 싶다면? 곧, 전자메일 계정정보를 설정하고 싶지 않다면? 그냥 루트 도메인이름(‘.’)을 설정하면 됩니다. ‘.’으로 설정하면 전자메일 계정정보가 없다는 것을 의미합니다.

tistory.com의 SOA 레코드에 설정된 rname 값은 “hostmaster.daum.net”이므로 이 경우 담당자의 전자메일 주소는 “hostmaster@daum.net”이 됩니다.

rname 필드는 사람(관리자)이 참조하는 필드입니다. DNS 표준기능 중에는 이 rname 필드를 참조하여 동작하는 기능은 없는 것으로 보입니다.

serial, refresh, retry, expire 필드는 슬레이브 네임서버에게 아주 중요한 정보를 제공하는 필드입니다. 이 도메인 존의 주기적인 데이터 동기화 관리를 어떤 기준으로 해야 하는지를 표시합니다.

serial 필드는 도메인 존의 버전번호를 표시합니다. 도메인 존은 그 영역 내부에 설정된 DNS 레코드 값이 변동될 때마다 serial 버전번호를 “증가”시킵니다. serial 번호는 최신 도메인 존 정보여부를 확인하는 용도로 사용됩니다. 도메인 존 데이터 동기화 절차(존 전송절차)에서 마스터 네임서버의 도메인 존 데이터가 갱신된 최신 데이터인지 여부를 판별하는 “유일한 기준”입니다.

serial 필드에 설정하는 값은 그냥 10진수의 정수값입니다. 여기에 어떤 포맷으로 설정해야 한다는 규정은 없습니다.

다만, 관리운영상의 편의를 위해 주로 많이 사용하고 있는 통상적인 형식은 ‘YYYYMMDDnn’입니다. 관리자가 이해하기 쉬운 형식의 표현입니다. ‘YYYY’는 4자리의 연도, ‘MM’은 2자리로 표현한 월, ‘DD’는 2자리의 일자, ‘nn’은 해당일자에 이루어진 수정버전 일련번호를 2자리 숫자로 표현한 것입니다. 물론 이 형식으로 설정한 값은 그저 10진수 값이고 네임서버는 단순한 10진수 정수값으로 해석합니다. (serial 번호 관리 편이성를 위해 BIND DNS는 특정한 경우에 한해 이 serial 번호를 몇 가지 특정한 포맷으로 네임서버가 해석하여 관리하도록 하는 옵션을 제공하고 있기도 합니다.)

tistory.com의 SOA 예시에서 tistory.com 도메인 존의 serial 값은 2015090300으로 설정되어 있습니다. 이 설정은 ‘YYYYMMDDnn’ 형식에 해당합니다. 2015년 09월 03일에 첫번째(00)로 변경한 버전이라는 것으로 해석할 수 있습니다. 이 형식을 사용하면 이 도메인 존의 데이터가 언제 최종 갱신되었는지를 관리자가 쉽게 파악할 수 있는 이점이 있습니다.

종종 도메인 데이터를 수정한 관리자가 SOA serial 번호 수정 처리를 깜박해서 낭패를 겪는 경우가 발생합니다. 도메인 존의 레코드 데이터가 갱신되었지만 존의 SOA serial 번호가 증가되지 않으면, 슬레이브 네임서버들은 자신이 보유한 존 데이터의 버전과 동일하다고 보고 도메인 존 전송 요청을 하지 않는 일이 발생합니다. 관리자는 존 데이터를 수정 갱신하여 네임서버에 반영했다고 믿고 있지만 정작 슬레이브 네임서버들은 이전 버전의 존 데이터를 그대로 유지하는 상태에 놓여있게 됩니다. 슬레이브 네임서버는 도메인 갱신여부 체크에 있어 도메인 존의 레코드를 일일이 비교 검사하는 것이 아니라, 단순하게 SOA serial 번호의 증가 여부만 체크하여 판단합니다.

refresh, retry, expire 필드는 도메인 존의 “정기적인” 데이터 갱신주기에 대한 기준 값입니다. 각 필드 값은 초단위로 설정합니다. 슬레이브 네임서버는 이 3개 필드에 지정된 시간 값을 적용하여 도메인 존의 데이터 갱신 동기화 관리를 합니다.

refresh는 도메인 존의 데이터 변경여부를 어떤 주기로 체크할 것인지를 표시합니다. retry는 refresh에 지정된 주기로 체크하다가 장애 등으로 인해 도메인 존 변경여부를 확인하지 못한 경우에 다시 시도하는 재시도 주기를 표시합니다. 따라서 retry 값은 그 목적상 refresh 시간보다는 짧은 시간이어야 하겠죠. expire는 존 데이터 동기화 절차에 장애가 발생하여 retry를 수차례 반복하는 가운데 결국 존 데이터의 갱신시도를 최종적으로 포기하고 이 도메인 존을 폐기하여 서비스 중단처리하는 최대 기한을 표시합니다. expire 필드는 데이터 동기화 유지에 실패하고 있는 도메인 존을 그 상태 그대로 무한정 유지할 수는 없으므로, 동기화 실패상태 지속의 최대 시한으로 한정하는 데에 사용합니다.

그러면, refresh, retry, expire 필드 값을 어떤 값으로 설정하면 될까요? 설정 기준 값이 제시된 것이 있을까요? 꼭 이렇게 설정해야 한다는 규정은 없지만, 여러 가지 테스트 결과와 운영경험을 토대로 권고하고 있는 설정 기준값은 제시되어 있습니다. 이를 요약하여 정리하면 다음과 같습니다.

필드 구분	고려가능 기준값	비고 / 고려사항
refresh	3600 (1시간)	- RFC1912는 refresh 값으로 20분~2시간(고속 네트워크), 2시간~12시간(저속 네트워크) 설정 권고 - 현재 국내 네트워크 여건을 고려하면 1시간 정도가 무난 (RFC1912의 고속 네트워크 환경에 해당)
retry	900 (15분)	- RFC1912 : retry 값의 정수배가 refresh 값이 되도록 설정 권고 - 900 (retry) x 4 = 3600 (refresh)
expire	604800 (1주) 에서 2419200 (4주) 사이	- RFC1912 : 2주~4주 설정 권고 - 하지만 RFC1912 작성된 1997년보다 현재 네트워크 상황이 안정화 향상된 점 고려, 1주~4주 설정도 무난 - 서비스 환경, 시스템 관리운영 여건 등을 고려하여 설정 - 최악의 상황 고려하여 설정 (마스터 네임서버 장애가 방치된 상황에서 서비스 유지에 필요한 최소 시간 등)

구체적으로 위에 제시된 tistory.com의 사례를 보겠습니다.

tistory.com 도메인의 refresh는 2700초로 설정되어 45분 간격으로 마스터 도메인 존이 최신 정보로 변경되었는지를 확인하도록 되어 있습니다. retry는 900초로써 serial 번호확인이나 존 전송에 문제가 발생한 시점부터 15분 간격으로 재시도 하도록 되어 있습니다. expire는 604800초로 설정되어, 최신버전 확인 및 갱신처리가 실패한 시점부터 장애 지속상태가 1주일이 경과하면 슬레이브 네임서버가 tistory.com 도메인 존에 대한 DNS 서비스를 중단하도록 되어 있습니다.

이 설정은 도메인 존의 안정적인 관리운영을 기대할 수 있는 설정으로 통상적으로 권고하고 있는 기준범위에 적합한 설정이라 할 수 있습니다. retry 900초와 refresh 2700초 설정은 900 x 3 = 2700초로 refresh 시간이 retry 시간의 정수배가 되도록 설정하라는 권고 기준을 따르고 있습니다. expire는 1주를 설정하고 있는데 이는 체계적이고 상시적인 시스템 관리운영이 이루어지는 운영여건에서 볼 때는 문제를 인지하고 조치하는 데에 충분하고도 남아도는 시간설정이라 할 수 있습니다.

refresh, retry, expire 필드 값에 의한 “주기적인 도메인 존 데이터 동기화 처리” 기능은 사실 도메인 존 데이터 동기화 유지에 있어 “최후의 보루” 역할을 합니다. 실제로는 이 기능에 의한 동기화보다는 DNS Notify에 의해 데이터 변경이 발생할 때마다 그떄 그때 즉각 처리하는 존 데이터 동기화 방식이 먼저 적용되고 있기 때문입니다. 하지만 마스터 네임서버에 어떤 장애가 발생해서 DNS Norify에 의한 존 데이터 동기화가 작동하지 않게 되면, SOA refresh, retry, expire 필드에 의존하는 전통적인 “주기적인 도메인 존 데이터 동기화 처리” 기능에 의해 도메인 존의 운영관리가 유지됩니다.

이를 고려하면 SOA refresh, retry, expire 필드 값을 설정할 때는, 최악의 경우 곧 마스터 네임서버에 장애가 발생하고 이 장애가 일정시간 방치되는 등 최악의 경우를 상정하고 이에 적절한 값을 산정하여 설정하는 것이 필요하다고 볼 수 있습니다.

minimum 필드는 캐시DNS서버가 이 도메인에 설정되지 않은 도메인(부재 도메인) 또는 설정되지 않은 레코드(부재 레코드)를 에러응답으로 응답받았을 때 이 정보를 일정시간 동안 캐싱(caching) 처리해야 할 때 “얼마의 기간동안 캐싱해야 하는지”에 대한 시간정보를 제공합니다. 곧 캐시DNS서버에게 부재 도메인/부재 레코드에 대한 캐싱 시간을 도메인 관리자가 정해 주는 역할을 합니다. 따라서 이 minimum 필드를 참조하는 사용하는 주체는 캐시DNS서버입니다.

그러면, minimum 필드의 설정값은 어떻게 설정해야 할까요? 여기에도 역시 정답은 없습니다. 이 도메인을 사용하는 인터넷 서비스 특성을 감안하여 정하는 것이 필요합니다. minimum 필드값은 사이트 특성에 가장 영향을 많이 받을 수 있는 값이라 할 수 있습니다.

만약 이 도메인 내부의 레코드 추가가 자주 일어나는 편이라면, minimum 필드 값은 비교적 작은 값으로 설정하는 것이 좋습니다.

예를 들면 example.com 도메인에 원래 www.example.com의 A 레코드가 없는 상태였고 example.com의 SOA minumum 필드값이 1주(604800초)로 설정되어 있었다고 가정해 봅니다. 상당히 많은 이용자가 www.example.com으로 접속하려고 시도했다면, 이 사용자의 캐시DNS서버는 www.example.com 의 A 레코드 질의를 하고 그 응답으로 없는 도메인이름(NXDOMAIN)이라는 에러 응답을 받게 됩니다. 캐시DNS서버는 이 에러응답 정보를 캐싱합니다. 이를 네거티브 캐싱(Negative Caching)이라 합니다. 이때 example.com의 SOA minimum 필드 값을 보니 그 값이 1주(604800초)이기 때문에 이 에러응답 정보를 1주일간 캐싱하도록 처리합니다.

그런데 얼마 지나지 않아 example.com에서 www.example.com 웹 사이트가 마련되고 DNS 도메인 존에 www.example.com의 A 레코드를 추가 설정했을 때 문제는 발생 할 수 있습니다. 분명히 도메인 존에 www.example.com A 정보를 반영했는데도 인터넷에서는 접속이 되지 않습니다. 이유는 이 www.example.com은 존재하지 않는 도메인이름이라는 정보가 네거티브 캐싱에 의해 캐시DNS서버에 1주일 동안이나 박혀 있기 때문입니다. 캐시DNS서버는 www.example.com에 대한 A 레코드 질의가 있을 때마다 캐싱 메모리에서 이 부재도메인 정보를 찾아내어 인터넷 이용자에게 www.example.com은 인터넷 상에 없는 도메인 이름이라고 계속 응답해 주기 때문입니다.

이 상황은 최대 1주일 동안 지속될 것이고 www.example.com 웹 사이트는 1주일 후에나 정상적으로 접속이 가능하게 될 것입니다. 네거티브 캐싱으로 캐싱된 정보가 캐시DNS서버에서 모두 사라지는 그 시점부터 웹 서비스는 원활하게 접속되기 시작합니다.

이를 감안한다면, SOA minimum 필드 값을 정할 때 “이 도메인 존에서 얼마나 자주 레코드 추가가 일어날 것인가”를 먼저 고려하는 것이 중요하다는 것을 알 수 있습니다. 만일 신속한 서비스 추가가 중요시 되는 사이트라면, 특히 갑작스레 서비스를 시작해야 하니 도메인이름과 레코드 하나 추가해서 “즉시” 반영해 달라는 요청이 심심치 않게 발생하는 그런 사이트라면 SOA minimum 값을 되도록 작은 값으로 미리 설정해 두는 것이 필요합니다. 이 경우 대략 10분에서 20분 정도 사이 값이면 문제가 없지 않을까요?

만일, 그렇지 않다면 SOA mininum 값을 좀 더 크게 잡는 것이 좋습니다. SOA minimum 값을 크게 잡으면 쓸데 없는 질의가 계속 들어오는 것을 방지할 수 있기 때문입니다. 예를 들어 www.example.com 이라는 도메인 이름이 설정되어 있지도 않은데, SOA minimum 값이 5초로 설정되어 있으면 이 이름에 대한 질의가 5초마다 유입될 수도 있습니다. 캐시DNS서버에서 www.example.com에 대한 부재도메인(NXDOMAIN) 에러응답 정보가 5초마다 사라지기 때문에 캐시DNS서버가 다시 질의해 오게 되니까요. 불필요한 DNS질의 트래픽 유입을 초래하는 원인이 되고, 캐시 DNS서버 입장에서도 불필요한 DNS질의응답 처리건이 늘어나는 부담을 안게 됩니다.

그런데 필드 이름이 왜 minimum 일까요? minimum 필드의 이름이 그 용도와 맞지 않아 혼동을 일으킬 수 있는데, 왜 이름을 이렇게 지었을까요? 원래 초기 DNS 표준에서는 SOA minimum 필드 값은 도메인 존의 모든 레코드에 적용하는 최소 TTL 값으로 정의되어 있어 “minimum TTL 값”이라는 의미를 가지고 있었습니다. 필드 명칭과 용도가 일치했었습니다. 그런데 이후에 네임서버의 DNS 질의응답 레코드 처리절차를 보다 명확하게 표준 정의하면서, SOA minimum 값의 용도를 보다 축소된 구체적인 용도의 필드로 개정했습니다. “네거티브 캐싱(negative caching)용 TTL 값”을 지정하는 용도로 한정하였습니다. 설정이 안된 없는 도메인 이름과 레코드는 TTL 정보도 설정된 것이 없으니, 캐시DNS서버는 도메인 존의 최소 TTL값(minimum TTL)을 캐싱 시간으로 적용한다는 의미로 아직 SOA minimum 필드 명칭을 그대로 사용하고 있습니다. 하지만 용도를 변경하면서 표준 명칭도 SOA ncaching 등으로 용도를 알기 쉬운 명칭으로 그때 바꾸었으면 좋았지 않았을까 생각합니다.

tistory.com의 경우는 SOA minimum 값으로 3600초(1시간)을 설정하고 있습니다. 티스토리 서비스는 새로운 DNS 레코드가 추가되더라도 최대 1시간 정도의 지연시간으로 인터넷에 반영 되기만 하면 문제가 없다고 판단해서 1시간으로 설정하고 있는 것 같습니다.

Q. 루트 힌트 파일은 꼭 설정해야 할까? 사설IP주소의 인버스 도메인은?

승홍 — Wed, 9 Dec 2015 15:40:39 +0900

Q. 루트 힌트(root hint) 파일은 꼭 설정해야 하나요?

A. 최신 BIND DNS 버전으로 캐시DNS서버 용도로 사용하고 있다면, 굳이 따로 설정하지 않아도 됩니다.

캐시DNS서버 경우 루트 힌트 파일은 반드시 필요한 정보이기는 하지만, BIND DNS는 필요한 루트 네임서버 내역을 모두 실행 코드 자체에 내장하고 있기 때문에 따로 설정하는 수고를 하지 않아도 됩니다.

설정하지 않아도 된다는 말만 듣고 그냥 믿기에는 좀 그렇습니다. 또 혹시 지금 사용 중인 BIND DNS 버전은 루트 힌트 내용이 하드 코딩되어 있지 않을 수 있지 않을까 싶은 경우에는 직접 확인이 필요하겠지요.

지금 시스템에서 구동하고 있는 named의 프로세스가 /usr/local/sbin/named 실행파일이 구동된 프로세스라면, 아래와 같이 strings 유틸을 사용하여 하드 코딩된 루트 힌트 존 내역을 직접 확인할 수 있습니다. named 프로세스를 실행하기 전에 아래와 같이 확인해 보면 되겠지요.

※ strings 유틸은 바이너리 파일 내용 중 ASCII 문자열 부분만 추려내여 화면에 출력해 주는 유틸리티입니다.

$ strings /usr/local/sbin/named | grep -P '^(\.|[A-M]).+IN\W+(NS|A|AAAA)' 
.                       518400  IN      NS      A.ROOT-SERVERS.NET. 
.                       518400  IN      NS      B.ROOT-SERVERS.NET. 
.                       518400  IN      NS      C.ROOT-SERVERS.NET. 
.                       518400  IN      NS      D.ROOT-SERVERS.NET. 
.                       518400  IN      NS      E.ROOT-SERVERS.NET. 
.                       518400  IN      NS      F.ROOT-SERVERS.NET. 
.                       518400  IN      NS      G.ROOT-SERVERS.NET. 
.                       518400  IN      NS      H.ROOT-SERVERS.NET. 
.                       518400  IN      NS      I.ROOT-SERVERS.NET. 
.                       518400  IN      NS      J.ROOT-SERVERS.NET. 
.                       518400  IN      NS      K.ROOT-SERVERS.NET. 
.                       518400  IN      NS      L.ROOT-SERVERS.NET. 
.                       518400  IN      NS      M.ROOT-SERVERS.NET. 
A.ROOT-SERVERS.NET.     3600000 IN      A       198.41.0.4 
A.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:503:BA3E::2:30 
B.ROOT-SERVERS.NET.     3600000 IN      A       192.228.79.201 
C.ROOT-SERVERS.NET.     3600000 IN      A       192.33.4.12 
C.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:500:2::c 
D.ROOT-SERVERS.NET.     3600000 IN      A       199.7.91.13 
D.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:500:2d::d 
E.ROOT-SERVERS.NET.     3600000 IN      A       192.203.230.10 
F.ROOT-SERVERS.NET.     3600000 IN      A       192.5.5.241 
F.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:500:2F::F 
G.ROOT-SERVERS.NET.     3600000 IN      A       192.112.36.4 
H.ROOT-SERVERS.NET.     3600000 IN      A       128.63.2.53 
H.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:500:1::803F:235 
I.ROOT-SERVERS.NET.     3600000 IN      A       192.36.148.17 
I.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:7fe::53 
J.ROOT-SERVERS.NET.     3600000 IN      A       192.58.128.30 
J.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:503:C27::2:30 
K.ROOT-SERVERS.NET.     3600000 IN      A       193.0.14.129 
K.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:7FD::1 
L.ROOT-SERVERS.NET.     3600000 IN      A       199.7.83.42 
L.ROOT-SERVERS.NET.     604800  IN      AAAA    2001:500:3::42 
M.ROOT-SERVERS.NET.     3600000 IN      A       202.12.27.33 
M.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:DC3::35

루트 힌트 내용이 하드 코딩되어 있는 소스 파일은 lib/dns/rootns.c 입니다.

그러면, 루트 힌트 파일을 일부러 작성해서 반영해야 하는 경우는 어떻게 해야 할까요? 이전처럼 루트 힌트 파일을 작성해서 named.conf에 설정해 주면 됩니다. named는 내장된 루트 네임서버 내역 대신 관리자가 작성해서 알려준 루트 힌트 파일의 정보를 반영합니다.

테스트베드망을 구성하는 특수한 경우, 내부망에 시험망 내에 구축한 루트 네임서버를 사용해야 한다면 직접 루트 힌트 파일의 설정이 필요합니다. 인터넷의 루트 네임서버 대신 시험망 환경에 있는 시험용 루트 네임서버를 이용해야 하니까요.

인터넷의 루트 네임서버 IP주소가 바뀌면 루트 힌트 파일 설정이 필요할 수 있습니다. 하지만 13개의 루트 네임서버 IP주소 전부가 한꺼번에 바뀌는 일은 없을 것이므로 루트 네임서버 하나의 IP주소가 바뀌었다 하더라도 굳이 루트 힌트 파일을 작성해 주지 않아도 됩니다. 13개 루트 네임서버 IP주소 중에 하나라도 정확한 것이 있으면 루트 네임서버를 이용하는데 문제는 없습니다. 이번 12월 1일에 H 루트 네임서버의 IP주소가 변경되었지만 13개 중에서 하나의 루트 네임서버 IP주소만 바뀌었기 때문에 내장된 루트 네임서버 정보를 사용해도 무방합니다.

Q. '127.0.0.1/8'의 인버스도메인 존은?

A. 최신 BIND DNS 버전을 사용하고 있다면, 루프백 주소(127.0.0.1/8)와 사설 IP주소, 기타 공중 인터넷에서 사용할 수 없는 주소에 대한 인버스도메인도 따로 설정하지 않아도 됩니다.

BIND DNS는 인터넷 표준으로 지정되어 있는 루프백(loopback) 주소, 사설 IPv4/IPv6 주소, 기타 공중 인터넷에서 사용하지 않는 주소 들에 대한 인버스도메인 내역 역시 하드 코딩하여 실행파일 코드에 내장해 두고 있습니다. 그래서 별도의 설정이 없으면 하드코딩된 내역을 적용하여 동작합니다.

역시 동일한 방법을 사용해서 하드코딩된 인버스도메인 내역을 확인해 볼 수 있습니다.

$ strings /usr/local/sbin/named | grep -P '(IN-ADDR|IP6).ARPA$' 
10.IN-ADDR.ARPA
16.172.IN-ADDR.ARPA
17.172.IN-ADDR.ARPA
18.172.IN-ADDR.ARPA
19.172.IN-ADDR.ARPA
20.172.IN-ADDR.ARPA
21.172.IN-ADDR.ARPA
22.172.IN-ADDR.ARPA
23.172.IN-ADDR.ARPA
24.172.IN-ADDR.ARPA
25.172.IN-ADDR.ARPA
26.172.IN-ADDR.ARPA
27.172.IN-ADDR.ARPA
28.172.IN-ADDR.ARPA
29.172.IN-ADDR.ARPA
30.172.IN-ADDR.ARPA
31.172.IN-ADDR.ARPA
168.192.IN-ADDR.ARPA
64.100.IN-ADDR.ARPA
65.100.IN-ADDR.ARPA
66.100.IN-ADDR.ARPA
67.100.IN-ADDR.ARPA
68.100.IN-ADDR.ARPA
69.100.IN-ADDR.ARPA
70.100.IN-ADDR.ARPA
71.100.IN-ADDR.ARPA
72.100.IN-ADDR.ARPA
73.100.IN-ADDR.ARPA
74.100.IN-ADDR.ARPA
75.100.IN-ADDR.ARPA
76.100.IN-ADDR.ARPA
77.100.IN-ADDR.ARPA
78.100.IN-ADDR.ARPA
79.100.IN-ADDR.ARPA
80.100.IN-ADDR.ARPA
82.100.IN-ADDR.ARPA
83.100.IN-ADDR.ARPA
84.100.IN-ADDR.ARPA
85.100.IN-ADDR.ARPA
86.100.IN-ADDR.ARPA
87.100.IN-ADDR.ARPA
88.100.IN-ADDR.ARPA
89.100.IN-ADDR.ARPA
90.100.IN-ADDR.ARPA
91.100.IN-ADDR.ARPA
92.100.IN-ADDR.ARPA
93.100.IN-ADDR.ARPA
94.100.IN-ADDR.ARPA
95.100.IN-ADDR.ARPA
96.100.IN-ADDR.ARPA
97.100.IN-ADDR.ARPA
98.100.IN-ADDR.ARPA
99.100.IN-ADDR.ARPA
100.100.IN-ADDR.ARPA
101.100.IN-ADDR.ARPA
102.100.IN-ADDR.ARPA
103.100.IN-ADDR.ARPA
104.100.IN-ADDR.ARPA
105.100.IN-ADDR.ARPA
106.100.IN-ADDR.ARPA
107.100.IN-ADDR.ARPA
108.100.IN-ADDR.ARPA
109.100.IN-ADDR.ARPA
110.100.IN-ADDR.ARPA
111.100.IN-ADDR.ARPA
112.100.IN-ADDR.ARPA
113.100.IN-ADDR.ARPA
114.100.IN-ADDR.ARPA
115.100.IN-ADDR.ARPA
116.100.IN-ADDR.ARPA
117.100.IN-ADDR.ARPA
118.100.IN-ADDR.ARPA
119.100.IN-ADDR.ARPA
120.100.IN-ADDR.ARPA
121.100.IN-ADDR.ARPA
122.100.IN-ADDR.ARPA
123.100.IN-ADDR.ARPA
124.100.IN-ADDR.ARPA
125.100.IN-ADDR.ARPA
126.100.IN-ADDR.ARPA
127.100.IN-ADDR.ARPA
0.IN-ADDR.ARPA
127.IN-ADDR.ARPA
254.169.IN-ADDR.ARPA
2.0.192.IN-ADDR.ARPA
100.51.198.IN-ADDR.ARPA
113.0.203.IN-ADDR.ARPA
255.255.255.255.IN-ADDR.ARPA
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
D.F.IP6.ARPA
8.E.F.IP6.ARPA
9.E.F.IP6.ARPA
A.E.F.IP6.ARPA
B.E.F.IP6.ARPA
8.B.D.0.1.0.0.2.IP6.ARPA

인버스도메인 존 내역이 하드 코딩되어 있는 소스 파일은 bin/named/server.c 입니다.

설정내역이 상당히 많습니다. 이 많은 걸 일일이 수작업으로 설정하는 것 보다는 BIND DNS가 내장된 설정을 사용하도록, 아무 설정도 하지 않는 것이 바람직 할 것입니다.

다만, 하드 코딩된 인버스도메인 내역을 활용하려면, named.conf의 options 영역에 'empty-zones-enable no' 설정을 하지 않아야 합니다.

'empty-zones-enable no' 설정을 하는 경우, 위 내장된 인버스도메인 존 내역은 자동 설정되지 않으며, 관리자가 수작업으로 설정하여야 합니다.

설정을 하지 않는 경우 'empty-zones-enable yes' 가 디폴트 설정입니다.

named는 'empty-zones-enable' 옵션 값을 검사해서 이 값이 'yes'인 경우(디폴트 값이 yes)에 한하여 위의 내장된 인버스도메인 존을 생성합니다. 만약 위 리스트 중에 관리자가 따로 인버스도메인으로 named.conf에 설정한 인버스도메인 존이 있으면 이 존은 관리자가 지정한 존으로 반영처리하고 나머지 내장 인버스도메인 존을 생성합니다. 만일 named.conf 파일의 options 영역에 'disable-empty-zone' 옵션으로 특정한 인버스도메인이 지정되어 있다면 이 인버스도메인은 생성하지 않고 다음 리스트의 인버스도메인 존을 생성합니다.

empty-zones-enable yes|no : [디폴트 yes] 내장된 사설 및 특수 IP주소의 인버스도메인 리스트에 대해 비어있는 인버스도메인 존을 자동 생성하여 반영

disable-empty-zone zone_name : [디폴트 ""] 내장된 사설 및 특수 IP주소의 인버스도메인 리스트 중에서 자동생성하지 않아야 할 인버스도메인 존을 지정. 존마다 여러번 지정할 수 있음.

empty-zone에 관련된 기타 옵션들은 BIND 매뉴얼 참조

이 기능은 BIND 9.6이상에서 제공하기 시작했습니다. BIND 9.9 버전부터는 'empty-zones-enable yes'가 디폴트 설정으로 전환되었으므로, 관리자가 일부러 'empty-zones-enable no' 설정을 하는 경우가 아니라면 내장된 인버스도메인 리스트이 존이 자동으로 생성되어 사용됩니다.

※ 앞서 "최신 BIND DNS 버전을 사용하고 있다면"이라는 단서를 달았지만, 사실은 BIND9 초기 버전 시절부터 이미 루트 힌트 내역을 코드에 내장하고 있었던 것으로 보입니다. 정확히 어느 버전부터 적용되고 있었는지는 확실하게 언급할 수 없지만 적어도 BIND 9.2부터는 루트 힌트 내역을 코드에 내장하고 있다고 말할 수 있을 것 같습니다.