Empty2 - Only NULL Bytes

Empty2 - Only NULL Bytes

This module is designed to respond with an empty answer consisting solely of an arbitrary number of NULL bytes (\000).

Note that DNS packets in TCP mode include a length field at the beginning, but this module intentionally disregards this requirement and sends back only the specified number of NULL bytes as the response.

For a variant that provides the length information correctly in TCP mode, refer to the empty3 module.

Category: Empty responses

Format

empty2.<NUMBER>.yourdomain.com

Where:

  • The <NUMBER> parameter defines how many NULL bytes should be generated in the response. By default, a single NULL byte is generated.

Examples

By default, the module generates a single NULL byte as the response. This is insufficient for a valid DNS response, causing the client to make three attempts to resolve the error:

# dig empty2.yourdomain.com @127.0.0.1

;; Warning: short (< header size) message received
;; communications error to 127.0.0.1#53: timed out
;; Warning: short (< header size) message received
;; communications error to 127.0.0.1#53: timed out
;; Warning: short (< header size) message received
;; communications error to 127.0.0.1#53: timed out

; <<>> DiG 9.18.10-2-Debian <<>> empty2.yourdomain.com @127.0.0.1
;; global options: +cmd
;; no servers could be reached

Download PCAP File


In this example, we request 100 NULL bytes as the response. In this case, the parser interprets the Transaction ID in the response as 0 (\000\000) which clearly does not match the Transaction ID from the original query. As a result, the client again makes three attempts to resolve the error:

# dig empty2.100.yourdomain.com @127.0.0.1

;; Warning: ID mismatch: expected ID 53701, got 0
;; Warning: query response not set
;; communications error to 127.0.0.1#53: timed out
;; Warning: ID mismatch: expected ID 53701, got 0
;; Warning: query response not set
;; communications error to 127.0.0.1#53: timed out
;; Warning: ID mismatch: expected ID 53701, got 0
;; Warning: query response not set
;; communications error to 127.0.0.1#53: timed out

; <<>> DiG 9.18.10-2-Debian <<>> empty2.100.yourdomain.com @127.0.0.1
;; global options: +cmd
;; no servers could be reached

Download PCAP File


In this example, we switch to TCP mode and request 100 NULL bytes as the response. Since a DNS packet in TCP mode includes a length field at the beginning, the parser interprets the packet as having zero length. We can also see that in TCP mode, the client does not make any further attempts to resolve the error:

# dig empty2.100.yourdomain.com @127.0.0.1 +tcp

;; ERROR: short (< header size) message

Download PCAP File

For a variant that provides the length information correctly in TCP, look at the empty3 module.


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

;; Warning: ID mismatch: expected ID 16501, got 0
;; Warning: query response not set
;; communications error to 10.211.55.2#53: timed out
;; Warning: ID mismatch: expected ID 16501, got 0
;; Warning: query response not set
;; communications error to 10.211.55.2#53: timed out
;; Warning: ID mismatch: expected ID 16501, got 0
;; Warning: query response not set
;; communications error to 10.211.55.2#53: timed out

; <<>> DiG 9.18.10-2-Debian <<>> empty218231.100.yourdomain.com @10.211.55.2
;; global options: +cmd
;; no servers could be reached

Download PCAP File


From the same category


Go back to catalogue.