BadCompressMid1 - Compression in the Middle of CNAME

The DNS protocol supports compressing domain names to save space by reducing redundancy for repeated domain names within DNS messages. This compression scheme can be applied to various record (resource) types, such as A, CNAME, MX, or PTR records.

This module is designed to respond with a single answer containing a CNAME record (alias) where the CNAME field (located at the end of the record) is compressed in a manner that violates DNS specifications.

In this case, the CNAME field contains the alias name abc.badcompressmid1.yourdomain.com.hello. This alias is constructed using compression, with the compression pointer placed in the middle of the alias name. Specifically, the CNAME field consists of the string abc, followed by a compression pointer that points back to the original domain name located in the QUERY section (badcompressmid1.yourdomain.com), and then followed by the string hello.

Placing the compression pointer in the middle in this case is achieved by deliberately setting the Data length value (in the CNAME record) to indicate that the hello string should still be included as part of the alias name.

This arrangement directly violates DNS specifications, as the compression pointer is placed in the middle of the compressed string. According to the DNS protocol, a compression pointer must always be the last part of the compressed string.

Category: Bad compression

RFCs: RFC1035

Format

badcompressmid1.yourdomain.com

This module has no parameters.

Examples

In this example, we can see that the client (dig) is unable to process the response because of the compression pointer being placed in the middle of the domain name (alias name):

# dig badcompressmid1.yourdomain.com @127.0.0.1

;; Got bad packet: extra input data
73 bytes
4e 10 84 00 00 01 00 01 00 00 00 00 0f 62 61 64          N............bad
63 6f 6d 70 72 65 73 73 6d 69 64 31 0a 79 6f 75          compressmid1.you
72 64 6f 6d 61 69 6e 03 63 6f 6d 00 00 01 00 01          rdomain.com.....
c0 0c 00 05 00 01 00 00 00 3c 00 0d 03 61 62 63          .........<...abc
c0 0c 05 68 65 6c 6c 6f 00                               ...hello.

Download PCAP File

By examining the PCAP file in Wireshark, we can see that Wireshark parses the response without any issues, ignoring the appended hello string. However, different DNS resolvers and clients may handle such malformed responses in vastly different ways, making this an intriguing use case for testing.

Like other features, you can append anything to the feature name to avoid receiving cached responses from the target DNS resolver. This forces the target resolver to actively communicate with our PolarDNS server instead of responding with cached answers. Using a random number is the most effective strategy:

# dig badcompressmid1${RANDOM}.yourdomain.com @10.211.55.2

;; Got bad packet: extra input data
78 bytes
1f fc 84 00 00 01 00 01 00 00 00 00 14 62 61 64          .............bad
63 6f 6d 70 72 65 73 73 6d 69 64 31 31 38 39 37          compressmid11897
37 0a 79 6f 75 72 64 6f 6d 61 69 6e 03 63 6f 6d          7.yourdomain.com
00 00 01 00 01 c0 0c 00 05 00 01 00 00 00 3c 00          ..............<.
0d 03 61 62 63 c0 0c 05 68 65 6c 6c 6f 00                ..abc...hello.

Download PCAP File

From the same category

Go back to catalogue.