BadCompressLoop3 - Double Pointer Loop
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 particular module is designed to respond with a single answer containing a CNAME record (alias) where the Name field is compressed, and the CNAME field is partially compressed.
The Name field consists solely of a compression pointer that points forward to the CNAME field located at the end of the packet.
The CNAME field contains only the abc
string (a beginning of a domain name) followed by a compression pointer that points back to the Name field.
This arrangement effectively creates a loop, preventing either field from being assembled into a valid domain name.
Category: Bad compression
RFCs: RFC1035
Format
badcompressloop3.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 loop:
# dig badcompressloop3.yourdomain.com @127.0.0.1
;; Got bad packet: bad compression pointer
67 bytes
7a d1 84 00 00 01 00 01 00 00 00 00 10 62 61 64 z............bad
63 6f 6d 70 72 65 73 73 6c 6f 6f 70 33 0a 79 6f compressloop3.yo
75 72 64 6f 6d 61 69 6e 03 63 6f 6d 00 00 01 00 urdomain.com....
01 c0 3d 00 05 00 01 00 00 00 3c 00 06 03 61 62 ..=.......<...ab
63 c0 31 c.1
By examining the PCAP file in Wireshark, we can see that it detects the loops and displays the error message <Name contains a pointer that loops>
while parsing the fields. 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 badcompressloop3${RANDOM}.yourdomain.com @10.211.55.2
;; Got bad packet: bad compression pointer
72 bytes
ab a3 84 00 00 01 00 01 00 00 00 00 15 62 61 64 .............bad
63 6f 6d 70 72 65 73 73 6c 6f 6f 70 33 32 30 33 compressloop3203
30 38 0a 79 6f 75 72 64 6f 6d 61 69 6e 03 63 6f 08.yourdomain.co
6d 00 00 01 00 01 c0 42 00 05 00 01 00 00 00 3c m......B.......<
00 06 03 61 62 63 c0 36 ...abc.6
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)
- BadCompressLoop4 - Pointer Loop in CNAME Field (Variant 1)
- BadCompressLoop5 - Pointer Loop in CNAME Field (Variant 2)
- BadCompressMid1 - Compression in the Middle of CNAME