BIND DNS 네임서버는 수신된 DNS 질의내역을 로그 파일로 기록할 수 있습니다. Show 이 포스팅은 현 시점의 BIND 버전(9.16)을 기준으로, 질의 로그에 실려있는 정보 항목을 될 수 있는 한 상세하게 보여주고자 합니다. 향후 BIDN 버전이 상향되고 또 DNS 관련 질의속성 관련 표준기능이 추가되면 변동될 수도 있습니다. 이번 포스팅의 성격 상, 질의 로그의 각 항목에 대한 개괄적 설명에만 초점을 둡니다. 각 개별 항목과 관련된 DNS 기능 및 동작에 대한 세부 사항은 시간이 될 때 각 사항에 중점을 둔 포스팅에서 다루고자 합니다. named.conf의 질의로그 기록 설정다음은 질의(query) 로그 기록 설정의 한 예시입니다. named.conf 파일에 설정합니다.
이 설정은 카테고리 BIND의 DNS 질의로그 형태단순한 질의형태로 tistory.com의 A 레코드 질의를 했습니다. 이 경우 BIND의 로그 메시지는 어떤 형태로 기록되는지 확인해 보기로 하겠습니다. (여기의 사례는 로컬 시스템에 캐시DNS 서버를 구동하고 로컬 시스템에서 127.0.0.1 주소로 DNS 질의하는 방식을 사용했습니다. 로그가 어떻게 기록되는지 살펴보는 것만 필요하기 때문입니다.)
이 경우에 대한 DNS 질의로그는 다음과 같은 형태로 기록됩니다.
BIND는 로그 카테고리별 특유한 헤더 정보와 각 항목의 상세부분으로 구분되어 있습니다. 질의로그도 헤더부분과 질의내용 부분으로 구분하여 볼 수 있습니다. queries 로그 헤더부분다음은 로그 카테고리
여기까지가 카테고리
queries 로그의 DNS 질의내용 부분질의의 각 질의내용은 그 다음 부분에 아래와 같은 형태로 기록됩니다.
queries 로그의 DNS 질의속성 축약표시, 상세사항질의속성 필드
이에 추가하여 질의속성 필드는 아니지만 부가되어 표시될 수 있는 정보가 하나 더 있습니다. 이 정보는 로그 라인의 맨 끝 필드로 표시될 수 있습니다.
표시가능한 모든 정보가 반영된 질의로그 경우BIND 질의로그에 표시 가능한 정보 모두를 표시하도록 하려면 아래와 같은 DNS 질의를 사용할 수 있습니다.
아래는
질의 로그 파일에는 아래와 같은 내용으로 기록이 남게 됩니다.
이 로그 메시지를 구성요소에 따라 3개 라인으로 분리하면 다음과 같습니다.
첫번째 라인은 로그 시각에 해당하는 첫 2개 필드입니다. 이 로그시각은 모든 로그에서 동일한 형태를 갖습니다. 2번째 라인은 3번째 라인은 질의내용 부분입니다. 질의속성
DNS Cookie는 처음에 질의하는 호스트가 자신의 Clinet Cookie 데이터 8바이트를 설정하여 질의하면, 네임서버는 DNS응답에 Clinet Cookie 8바이트 데이터에 추가하여 네임서버가 생성한 Server Cookie 16바이트 데이터로 응답합니다. 그래서 (참고) DNS Cookies는 소스 IP주소와 소스 port 번호를 spoofing한 공격자의 DNS 질의/응답 패킷을 검출할 수 있는 수단으로 DNS Client Cookie와 DNS Server Cookie 정보를 상호교환 할 수 있도록 하는 메커니즘입니다. 비록 완벽한 수준의 보안인증 수단은 아니지만, 실용적인 측면에서는 DNS응답 spoofing 공격 시도를 어느 정도 감지할 수 있게 하여 공격시도를 방어할 수 있는 수단을 캐시DNS 서버와 권한DNS 서버에 제공합니다. DDoS 공격 시도와 DNS 캐시 포이즈닝 공격 시도에 자동으로 대응할 수 있게 합니다.
여기에서 이 질의에 대한 로그는 다음과 같습니다.
로그에 보이는 바와 같이, 질의속성 필드 표시가 DNS 질의로그 정보의 활용DNS 질의로그는 다양한 목적으로 활용할 수 있습니다. BIND 질의로그는 유용하지만, 한계점도 있습니다. DNS응답 정보는 질의로그에 기록되지 않습니다. 그래서 어떤 질의가 어떻게 응답 처리되었는지는 사실상 확인할 수 없습니다. BIND 로그 카테고리 중에는 참고 할 수 있는 자료
참고 : EDNS Client SubnetEDNS Client Subnet 기능은 질의하는 호스트의 IP주소(Prefix) 정보를 DNS질의에 설정하여 권한DNS로 질의합니다. 이때 권한DNS는 호스트가 네트워크의 어느 위치에 있는지 파악, 가장 근접한 서버의 접속정보를 응답해 주는 것이 가능하게 됩니다. 즉 권한DNS 서버가 질의한 사용자 호스트의 네트워크 위치를 손쉽게 파악하고, 사용자 호스트에 근접한 클라우드 서버 또는 CDN 서버의 IP주소를 선택하여 DNS응답 레코드로 응답해 줄 수 있게 합니다. 클라우드/CDN 서비스 경우에 상당히 유용할 수 있는 기능입니다. 하지만, EDNS Client Subnet은 질의호스트의 IP주소 정보(정확히는 Prefix 정보)를 권한DNS 서버에 알려주는 메커니즘으로써, 이는 사생활 보호(privacy 보호)라는 측면에서 보안 이슈가 있습니다. 이에 따라 인터넷표준화기구 IETF는 EDNS Client Subnet 기능을 모든 네임서버가 구현해야 하는 필수사항이 아닌 참고사항(Informational)으로 처리하였습니다. 인터넷표준화기구 IETF는 향후 EDNS Clinet Subnet 기능에 대해 사생활(privacy) 보호를 고려하여 보다 안전한 대체기능의 표준화를 모색하고 있다고 합니다. BIND DNS 네임서버 경우, EDNS Client Subnet 정보를 기반으로 소재지 기반 DNS 응답처리를 지원하는 |