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.
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.
From the same category
- BadCompress1 - Custom Offset in Name Field
- BadCompress2 - Custom Offset in CNAME Field
- BadCompressFwPtr1 - Forward and Double Pointer in Name Field (Variant 1)
- BadCompressFwPtr2 - Forward and Double Pointer in Name Field (Variant 2)
- BadCompressLoop1 - Pointer Loop in Name Field (Variant 1)
- BadCompressLoop2 - Pointer Loop in Name Field (Variant 2)
- BadCompressLoop3 - Double Pointer Loop
- BadCompressLoop4 - Pointer Loop in CNAME Field (Variant 1)
- BadCompressLoop5 - Pointer Loop in CNAME Field (Variant 2)