QueryBack4 - Query Reflection (Random, to Port 53)

QueryBack4 - Query Reflection (Random, to Port 53)

This module is an enhanced variant of the queryback3 module.

Similar to the queryback3 module, instead of sending a DNS response with an answer, this module resends the original query back to the sender on UDP port 53. The original query is never actually answered; the connection is simply abandoned, resulting in a timeout.

⚠BEWARE⚠ This behavior is intentionally designed to create a loop between the client/resolver and the PolarDNS server. For instance, if the client is a recursive resolver using the same IP address for both receiving queries and sending queries during resolution, it could result in an infinite loop of queries being sent back and forth indefinitely.

The difference from the queryback3 module is that a random number is appended to the query (to the “queryback4” feature name). This is to avoid receiving cached responses from the target recursive resolver.

This could potentially increase the likelihood of ending up in a loop, leading to a Denial of Service (DoS) situation.

Category: Empty responses

Format 

queryback4.yourdomain.com

This module has no parameters.

Examples

In this example, we run the query directly against PolarDNS server. We see that the client (dig) does not actually receive any response, and the query results in a timeout three times in a row:

# dig queryback4.yourdomain.com @10.211.55.2

;; communications error to 10.211.55.2#53: timed out
;; communications error to 10.211.55.2#53: timed out
;; communications error to 10.211.55.2#53: timed out

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

In the PCAP file below, we can see that the original query was sent back to us (reflected) to UDP port 53, each time with a random number appended to the query. As mentioned in the description above, this is an enhancement to circumvent caching. Here is an example of a query that PolarDNS sent back to us:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 921
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;queryback455521668906494812114.yourdomain.com. IN      A

Download PCAP File

Keep in mind that this query was sent back to us, to our UDP port 53. Since we do not run any DNS server on our system, nothing significant occured. However, if the initial query had been run through a recursive resolver (instead of directly to PolarDNS), it would be sent back (reflected) to the recursive resolver, potentially resulting in an infinite loop.


In the following example, we also use the newid modifier, which generates a new Transaction ID for each response. The query once again results in a timeout three times in a row:

# dig queryback4.newid.yourdomain.com @10.211.55.2

;; communications error to 10.211.55.2#53: timed out
;; communications error to 10.211.55.2#53: timed out
;; communications error to 10.211.55.2#53: timed out

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

Download PCAP File

In the PCAP file, we can see again that the original query was sent back to us (reflected) to UDP port 53, each time with a random number appended to it. However, the newid modifier also causes the Transaction ID to vary each time, which could potentially increase the likelihood of ending up in a loop compared to the previous example.


In the last example, we append a random number to the feature name. This still maintains the same functionality, as any string or text can be appended after the feature name to avoid receiving cached records. Using a random number from the start should further increase the chances of creating a loop on the target recursive resolver:

# dig queryback4${RANDOM}.newid.yourdomain.com @10.211.55.2

;; communications error to 10.211.55.2#53: timed out
;; communications error to 10.211.55.2#53: timed out
;; communications error to 10.211.55.2#53: timed out

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

Download PCAP File

Using this form should maximize the chances of creating a loop on the target recursive resolver, as everything is unique — the original domain name (with a random number), the subsequent domain names (with random numbers), and the Transaction IDs. The target resolver is unlikely to have any cached records for these.


From the same category


Go back to catalogue.