QueryBack3 - Query Reflection (To Port 53)

QueryBack3 - Query Reflection (To Port 53)

Instead of sending a DNS response with an answer, this module resends the original query back to the sender on UDP port 53, exactly as it was received. The original query is never actually answered; the connection is simply abandoned, resulting 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.

This could potentially lead to a Denial of Service (DoS) situation.

This is one of the main reasons why a recursive resolver should always use separate IP addresses for receiving queries and for sending out queries to other DNS servers (during resolution), to prevent potential infinite loops and other security risks.

Category: Empty responses

Format 

queryback3.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 queryback3.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 <<>> queryback3.yourdomain.com @10.211.55.2
;; global options: +cmd
;; no servers could be reached

However, in the PCAP file below, we can see that the original query was sent back to us (reflected) to UDP port 53. This is exactly what PolarDNS sent to our UDP port 53:

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

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

;; ADDITIONAL SECTION:
;; OPT PSEUDOSECTION
; EDNS: version: 0, flags: ; udp: 1232
; EDNS: code: 10; data: 1b5ad7fdde444be4

Download PCAP File

We can see that it is the exact same query that we originally sent. It was sent back to our UDP port 53. Since we do not run any DNS server on our system, nothing significant happened. 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 queryback3.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 <<>> queryback3.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. The only difference is that the Transaction ID varies each time. This could potentially increase the likelihood of ending up in an infinite loop compared to the previous example.


From the same category


Go back to catalogue.