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.
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
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
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
- Close - Close the Connection
- Empty1 - Empty Packet
- Empty2 - Only NULL Bytes
- Empty3 - Only NULL Bytes (Suitable for TCP)
- Empty4 - Only Transaction ID and NULL Bytes
- Empty5 - Only DNS Header and NULL Bytes
- Empty6 - ANSWER Section Missing
- Empty7 - ANSWER Section Is NULL Bytes
- QueryBack1 - Query Reflection
- QueryBack2 - Query Reflection (Stripped)
- QueryBack4 - Query Reflection (Random, to Port 53)
- Timeout - Do Not Respond