BadCompressFwPtr1 - Forward and Double Pointer in Name Field (Variant 1)

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 Name field is compressed using a forward pointer (in violation of DNS specifications) that points to the CNAME field at the end, which also uses compression. This results in double compression, further violating DNS specifications.

In this case, the CNAME field contains the alias name abc.badcompressfwptr1.yourdomain.com. This alias is constructed using standard compression. The field includes only the abc string, followed by a compression pointer that points back to the original domain name located in the QUERY section. Note that this CNAME field is located at the end of the CNAME record.

The Name field (located at the beginning of the CNAME record) consists solely of a compression pointer that points forward to the CNAME field at the end of the packet. This arrangement forces the parser to first jump forward (to the abc string) and then jump backward to complete the interpretation. However, neither forward nor double pointers are permitted in DNS.

In the DNS protocol, compression is achieved by using single backward pointers only, not forward pointers. Compression pointers are permitted to point only to previous positions in the message, because forward pointers require the parser to jump ahead in the message, increasing processing complexity and processing time.

Category: Bad compression

RFCs: RFC1035

Format

badcompressfwptr1.yourdomain.com

This module has no parameters.

Examples

The following query demonstrates the module’s functionality. It returns a CNAME record compressed in a way that violates DNS specifications — specifically by using forward and double compression pointers. We can see that the client (dig) is unable to parse such a response:

# dig badcompressfwptr1.yourdomain.com @127.0.0.1

;; Got bad packet: bad compression pointer
68 bytes
4a 4b 84 00 00 01 00 01 00 00 00 00 11 62 61 64          JK...........bad
63 6f 6d 70 72 65 73 73 66 77 70 74 72 31 0a 79          compressfwptr1.y
6f 75 72 64 6f 6d 61 69 6e 03 63 6f 6d 00 00 01          ourdomain.com...
00 01 c0 3e 00 05 00 01 00 00 00 3c 00 06 03 61          ...>.......<...a
62 63 c0 0c                                              bc..

Download PCAP File

However, by examining the PCAP file in Wireshark, we can see that it parses the response without any issues. This demonstrates Wireshark's superior parsing capabilities, as it is able to handle both forward and double compression pointers despite violating DNS specifications.

This also shows that different DNS resolvers and clients may handle such malformed responses differently, 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 badcompressfwptr1${RANDOM}.yourdomain.com @10.211.55.2

;; Got bad packet: bad compression pointer
73 bytes
27 3c 84 00 00 01 00 01 00 00 00 00 16 62 61 64          '<...........bad
63 6f 6d 70 72 65 73 73 66 77 70 74 72 31 32 33          compressfwptr123
38 38 38 0a 79 6f 75 72 64 6f 6d 61 69 6e 03 63          888.yourdomain.c
6f 6d 00 00 01 00 01 c0 43 00 05 00 01 00 00 00          om......C.......
3c 00 06 03 61 62 63 c0 0c                               <...abc..

Download PCAP File

From the same category

Go back to catalogue.