BadCompress1 - Custom Offset in Name Field

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.

DNS compression works by using pointers to refer back to previously specified domain names within the DNS message. Here are the key aspects of the compression scheme:

Pointers: The compression scheme uses 2-byte pointers that refer to previous occurrences of the same domain name (or a part of the domain name) within the DNS message.
Format: The pointer mechanism is encoded with the first two bits set to 11, followed by a 14-bit offset indicating the location of the domain name in the message.
Offset: The offset specifies the location of the domain name relative to the beginning of the DNS packet, allowing the pointer to reference where the domain name can be found.

This particular module is designed to respond with a single answer containing a CNAME record (alias) where the Name field is compressed.

Typically, the compression pointer points to the offset 12, where the original domain name is located in the QUERY section. This is a common and fixed location in many standard DNS responses, represented by the typical 0xc00c byte value used instead of the domain name.

However, this module allows the compression pointer in the Name field to point to any location within the DNS message by specifying an arbitrary offset.

By specifying various offsets, this will inevitably lead to parsing errors.

Category: Bad compression

RFCs: RFC1035

Format

badcompress1.<OFFSET>.yourdomain.com

Where:

The <OFFSET> parameter specifies the offset location relative to the beginning of the DNS packet.

Note that an offset of 12 is the typical location where the original domain name is located in the QUERY section.

Examples

In this example, we set the pointer to offset 0, which is the beginning of the DNS packet. This location typically contains the Transaction ID (a random number), which is not a domain name. As a result, the parser is unable to interpret this response correctly:

# dig badcompress1.0.yourdomain.com @127.0.0.1

;; Got bad packet: bad label type
87 bytes
a1 98 84 00 00 01 00 01 00 00 00 00 0c 62 61 64          .............bad
63 6f 6d 70 72 65 73 73 31 01 30 0a 79 6f 75 72          compress1.0.your
64 6f 6d 61 69 6e 03 63 6f 6d 00 00 01 00 01 c0          domain.com......
00 00 05 00 01 00 00 00 3c 00 1c 0b 61 6c 77 61          ........<...alwa
79 73 31 37 38 32 36 0a 79 6f 75 72 64 6f 6d 61          ys17826.yourdoma
69 6e 03 63 6f 6d 00                                     in.com.

Download PCAP File

Note that this may result in a different outcome each time you try it, as the Transaction ID is a random number.

In this example, we set the pointer to offset 3, which is the 4th byte of the DNS packet. This location typically contains the Flags field, and in our case, it contains a NULL byte (\000). Although a NULL byte is not a typical domain name, it represents the ROOT domain (the top of the DNS hierarchy). This is why we see a period symbol in the ANSWER section as the domain name we queried:

# dig badcompress1.3.yourdomain.com @127.0.0.1

; <<>> DiG 9.18.10-2-Debian <<>> badcompress1.3.yourdomain.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44216
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;badcompress1.3.yourdomain.com.	IN	A

;; ANSWER SECTION:
.			60	IN	CNAME	always11117.yourdomain.com.

;; Query time: 7 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Nov 12 13:37:14 +04 2024
;; MSG SIZE  rcvd: 87

Download PCAP File

Here, we request the pointer to point to the offset 12 which is the typical location where the original domain name is located in the QUERY section. This results in a completely valid and correct answer:

# dig badcompress1.12.yourdomain.com @127.0.0.1

; <<>> DiG 9.18.10-2-Debian <<>> badcompress1.12.yourdomain.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46658
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;badcompress1.12.yourdomain.com.	IN	A

;; ANSWER SECTION:
badcompress1.12.yourdomain.com.	60 IN	CNAME	always9809.yourdomain.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Nov 12 13:20:39 +04 2024
;; MSG SIZE  rcvd: 87

Download PCAP File

In this example, we set the pointer to offset 100, which is outside the bounds of the DNS packet in this case (the size of this response is only 89 bytes). As a result, the parser detects that the compression pointer is referencing an invalid location and fails to interpret the response entirely:

# dig badcompress1.100.yourdomain.com @127.0.0.1

;; Got bad packet: bad compression pointer
89 bytes
e9 39 84 00 00 01 00 01 00 00 00 00 0c 62 61 64          .9...........bad
63 6f 6d 70 72 65 73 73 31 03 31 30 30 0a 79 6f          compress1.100.yo
75 72 64 6f 6d 61 69 6e 03 63 6f 6d 00 00 01 00          urdomain.com....
01 c0 64 00 05 00 01 00 00 00 3c 00 1c 0b 61 6c          ..d.......<...al
77 61 79 73 38 31 37 37 33 0a 79 6f 75 72 64 6f          ways81773.yourdo
6d 61 69 6e 03 63 6f 6d 00                               main.com.

Download PCAP File

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 badcompress1${RANDOM}.3.yourdomain.com @10.211.55.2

; <<>> DiG 9.18.10-2-Debian <<>> badcompress121705.3.yourdomain.com @10.211.55.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21202
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;badcompress121705.3.yourdomain.com. IN	A

;; ANSWER SECTION:
.			60	IN	CNAME	always95736.yourdomain.com.

;; Query time: 8 msec
;; SERVER: 10.211.55.2#53(10.211.55.2) (UDP)
;; WHEN: Tue Nov 12 13:54:00 +04 2024
;; MSG SIZE  rcvd: 92

Download PCAP File

From the same category

Go back to catalogue.