DNS Lab.

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

BIND DNS

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

승홍 2021. 9. 24. 08:10

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 로그 카테고리를 추가로 사용하여 에러응답 경우에 대한 로그를 기록한다면 네임서버 질의응답 상황 관리에 도움이 될 수 있습니다.

 

참고 할 수 있는 자료

 

참고 : 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 질의의 분류/처리 동작이 가능합니다.

 

저작자표시 비영리 동일조건
'BIND DNS' Related Articles more
Comments