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

Download PCAP File

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

Download PCAP File

From the same category

Go back to catalogue.