DNS Lab.

DNS 메시지 압축 (Message Compression) 본문

DNS 표준/DNS 용어

DNS 메시지 압축 (Message Compression)

승홍 2020. 1. 12. 17:05

'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 응답메시지의 해석이 복잡한 처리를 필요로 하는 경우가 많습니다.

 

Comments