이번 시간에는 저번시간에 이어서 DNS 응답 메세지에 관한 설명을 하도록 하겠습니다.
이 블로그 Step by step으로 DNS에 대하여 연재합니다. 만약 DNS가 무엇인지 모르시거나, 아래 내용들이 이해가 가지 않으시면 아래 링크를 참조하셔서 확인부탁드립니다.
DNS시작하기 ! – https://jinheeahn.wordpress.com/2015/08/28/1-dns-시작하기
DNS 통신에 대하여! – https://jinheeahn.wordpress.com/2015/09/07/2-dns 통신에 대하여
DNS Header – https://jinheeahn.wordpress.com/2015/09/08/3-dns-message/
DNS 질의 메세지 - https://jinheeahn.wordpress.com/2015/09/21/4-dns-질의 메세지
그리고 Wireshark DNS packet 잡기도 연재하였으니 아래의 링크를 확인해주세요.
Wireshark로 DNS pakcet 잡기 – https://jinheeahn.wordpress.com/2015/09/21/dns-wireshark pakcet 잡기
DNS 응답 메세지 시작하도록 하겠습니다.
- 응답 메시지는 아래의 5개의 Data로 구성
- Header, Question(질의), Answer(응답), Authority(책임), Additional(부가정보)
- Answer, Authority, Additional은 동일한 RR Data Form을 가지며, RR DATA의 내용에 따라 길이는 다양하다.
위 그림은 응답메세지의 전체 구성도입니다. 여기서 Header + Question(질의 메세지)는 앞서 설명드린 Header & 질의메세지와 동일한 포맷으로 구성된 Packet입니다.
그렇다면, 질의 메세지와 응답메세지의 다른점은 Answer(응답), Authority(책임), Additional(부가정보)인데, 이 3가지 영역은 RR(Resource Record)라는 포맷형식으로 구성되어 있습니다.
그렇다면, 먼저 RR(Resource Record)라는 메세지 포맷을 알아본 뒤 Wireshark tool로 Capture하여 확인하는 순서대로 진행하면 될 것 같습니다. (응답, 책임, 부가정보가 어떤 역할을 하는지에 대한 설명은 DNS Message (Header) 부분을 확인해주세요. 아래 링크)
DNS Header – https://jinheeahn.wordpress.com/2015/09/08/3-dns-message/
- RR(Resource Record)
–도메인 이름에 대해 필요한 인터넷 자원 정보를 매핑하는 수단을 제공
–DNS 네임서버 내에 RR의 집합으로 구성되어 있으며, 그 집합으로는 각각의 ‘이름＇과＇값＇으로 바인딩 된다.
–이 정보들이 인터넷 상에서 분산 네임 데이터베이스를 형성하게 된다.
- RR Data Frame
–Name : 가변적, RR의 주체가 되는 객체 Domain name을 의미
–Value : Name에 대한 값
–Type : 2byte, RR Type code를 명시(주요 유형)
–Class : 요청된 Resource Data에 포함되어 있는 Data의 class 명시 (프로토콜 패밀리)
–TTL : RR의 유효 시간, RR을 읽은 장비가(DNS Server) 이 Data를 몇 초 동안이나 캐시에 유지해야 하는지 명시(DNS 캐싱 정보 유지 시간)
–Resource Data Length / Resource Data : 각각 자원 RR(답변, 인증, 추가 정보)의 데이터 길이(byte 단위)와 RR관련 데이터를 담고 있음.
- RR(Resource Record)의 정보 구성 특징
–RR 각 필드들은 스페이스에 의해 구별된다.
–각 레코드는 1 줄로 구성(1 줄이 넘는 경우 ‘;’으로 표시)
–주석문은 세미콜론(;)으로 시작된다.
여기까지, RR Data 포맷에 대한 설명입니다. 다음으로는 Wireshark를 이용하여 DNS 응답 메세지 Packet을 분석해보겠습니다.
이전 설명과 동일하게, Wireshark로 Packet을 캡쳐한 것을 토대로 진행하도록 하겠습니다.(아래 링크 참조)
Wireshark로 DNS pakcet 잡기 – https://jinheeahn.wordpress.com/2015/09/21/dns-wireshark pakcet 잡기
Capture한 응답메세지 Packet은 위 그림과 같습니다. 여기서 각 Packet을 나눠보도록 하겠습니다.
위 그림과 같이 Packet의 각 영역을 나누어 보았습니다.
여기서 문득 생각이 나오는 중요한 부분 !
"어떻게 같은 Packet으로 알 수 있지?" 라는 점입니다.
즉, DNS Client에서 Local DNS Server로 Header + 질의메세지를 보내고, Local DNS Server로 부터 응답메세지가 도착했는데, "과연 이 응답메세지가 DNS Client에서 보낸 메세지의 응답이 맞나?" 라는 문제에 직면하게 됩니다.
이 문제는 Transaction ID라는 ID로 자신의 메세지인지 구분하게 됩니다. 이 메세지는 DHCP에서도 동일하게 사용되는데요. 메세지를 주고 받으면서 통신을 하는 이 두가지의 Application들은 ID를 이용하여 자신이 보낸 질의 메세지에 대한 응답메세지인지 확인하게 됩니다.
부가적인 설명으로는 QR을 확인하여 Response인지도 확인하여 응답 메세지가 맞는지도 확인해야합니다.
자, 이제 가장 먼저 질의 메세지 부분을 분석해볼텐데요.
앞서 설명드린 질의 메세지와는 포맷은 동일하지만 데이터가 다르다는 것을 육안으로도 확인이 됩니다. 그렇다면 다른부분이 왜 다른지에 대한 설명 들어갑니다.
가장 처음으로는 Flags가 다릅니다. 아래의 링크를 보시면 질의 메세지를 보낼 때 Flags를 알 수 있으실텐데요.
DNS 질의 메세지 - https://jinheeahn.wordpress.com/2015/09/21/4-dns-질의 메세지
이 Flags를 보면 왜 0x8180이라는 Flags로 전송되었는지 유추해볼 수 있습니다.
0x8(Response) 1(RD) 8(RA) 가 2진수로 나타내면 알 수 있습니다.
RD와 RA Flags는 재귀적 응답을 할 것이냐 반복적 응답을 할 것이냐에 대한 질의 & 응답 Flags입니다.
DNS Client가 Local DNS Server로 질의 메세지를 보낼 때, RD를 1로 보내는건 재귀적 응답으로 사용하겠다는 것을 의미합니다. (재귀적 응답이 안될 경우 자동 반복적 응답으로 동작)
DNS Client로 부터 질의 메세지를 받은 Local DNS Server는 DNS Server로 동작하면서 반복적 동작을 실행하게 됩니다. (Root DNS -> Com DNS -> etc.. 순서대로 Domain Name IP 검색)
요즘 회사나 혹은 가정용 PC에서 DNS를 사용할 때, DHCP로 부터 할당받은 DNS를 사용하는데, 이 때 KT or LG U+의 DNS Server를 사용하기 때문에, 실제 DNS Client를 제작하고 DNS Server로 질의메세지를 보내게 되면 DNS Server는 자동으로 반복적 동작을 시행하여 Domain Name IP를 검색하고 질의메세지 요청에 대한 응답을 반환하게 됩니다.
그리고 이 때, RD or RA의 Flags를 '1'로 설정하여 보내게 됩니다. (RA는 재귀적 동작에 대한 응답을 하겠다는 의미입니다.)
질의, 응답, 책임, 부가 카운트는 말그대로 RR(Resource Record)개수를 의미합니다. 이 말의 의미가 이해가 안되신다면 응답 Packet을 직접 Capture하여 보시면 되겠습니다.
그 밖에는 아래 그림의 질의 메세지 설명과 동일합니다.
자, 이제 응답, 책임, 부가정보에 대한 각 Packet을 확인해보아야 할텐데요.
여기서 우리는 응답 메세지만 확인하면 됩니다.
이유는, 실제 DNS Client를 이용하여 요청한 질의메세지의 응답은 Answer(응답)영역에서 보내주기 때문입니다. 책임영역과 부가정보영역은 따로 Name Server와 관련된 정보들이기 때문에 이 부분에 대해서는 다른 추가적인 자료를 검토해보시는 것을 추천드립니다.
현재 이 프로젝트의 최종목표는 Domain Name을 검색하면 그에 매핑되어 있는 IP를 알아보는 것이기 때문에 정말 최소한의 필요한 것들만 이용하여 시스템을 구현 & 구성하는 것입니다.
그리고 여기까지 완료된다면, 프로젝트의 목표까지의 이론적인 설명은 끝났습니다.
그런데, 여기서 필자도 연재 하면서 궁금하였던 점이 생겼습니다.
응답 메세지를 Caputre하여 확인을 해보면, "www.google.co.kr"의 Hex code 확인란에 "c0 0c"라는 Hex코드가 보이게 됩니다. 이 Hex 코드의 의미를 알아야 할 것 같습니다.
이유는 어느 Packet을 잡더라도 Domain Name 부분의 Hex code는 0xc0 로 시작되는 것을 확인할 수 있겠는데, 이 코드를 사용하는 이유를 확실하게 짚고 넘어가야할 것 같습니다.
-> 제가 이해한대로 답변을 드립니다.
제가 알아본 결과, 0xC는 이름정보를 직접 표시하지 않고 Query부분에서 사용한 주소 값을 이용하기 위해 compression(압축)을 한 것입니다. 즉, 도메인의 전체 이름 or 일부를 가르키는 Resource의 시작을 0xCXXX 바이트를 사용합니다.
자세한 사항은 'RFC1035' 의 DNS Packet Comression을 참조해주세요.
그리고 0x00C는 Query 질의 메세지에 표시되어 있는 "www.google.co.kr"의 위치를 나타내는 포인터입니다.
(Query에서 "www.google.co.kr" Domain Name을 전송할 때, [ 3/w/w/w/6/g/o/o/g/l/e/2/c/o/2/k/r ] 이러한 순서대로 전송하게 되는데, 그저 0x00C는 포인터로 이 Data의 위치를 가르키는 Offset입니다. (ASCII Code 표를 참조하면 0x77(hex) -> w입니다.)
아래의 그림을 참조해주세요.
더 자세한 정보는 아래 링크 및 RFC1035를 참조해주세요.
http://www.ccs.neu.edu/home/amislove/teaching/cs4700/fall09/handouts/project1-primer.pdf
RFC1035 - http://tools.ietf.org/html/rfc1035
다음은, DNS 구현 (코딩) 으로 넘어가도록 하겠습니다.