> For the complete documentation index, see [llms.txt](https://lance-kenji.gitbook.io/me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://lance-kenji.gitbook.io/me/nullcon-hackim-ctf-goa-2026-writeups/misc/dragonflies.md).

# DragoNflieS

**Category:** DNS / Network Security

**Difficulty:** Medium

#### 1. Challenge Overview

The challenge provided a DNS server at `52.59.124.14:5053`. The hint stated that "latest and greatest DNS features" now allow internal networks to resolve names without VPNs or Firewalls. This was a clear pointer toward **EDNS Client Subnet (ECS)** or **DNS over QUIC (DoQ)**.

#### 2. Vulnerability Analysis

**Step 1: Protocol Reconnaissance**

I first checked the standard `TXT` record for the domain.

```bash
dig @52.59.124.14 -p 5053 TXT flag.ctf.nullcon.net
```

**Result:** `ENO{Zzzzt_Zzzzt_FAKEFLAG_Zzzzt}`

The server responded, but with a "troll" flag. The "Zzzzt" sound (a bug) confirmed I was hitting the right service but lacked the "internal" authorization.

**Step 2: Protocol Identification (The QUIC Rabbit Hole)**

The challenge title **DragoNflieS** (DNS over QUIC/Dragonfly) and the "latest and greatest" hint led me to test modern transports:

* **DNS over TLS (DoT):** Failed with `Connection refused`.
* **DNS over HTTPS (DoH):** Failed with `Connection refused`.
* **DNS over QUIC (DoQ):** Using `doggo`, the connection timed out (`deadline exceeded`), suggesting the server was either not using standard QUIC ALPNs or was strictly validating client metadata.

**Step 3: Probing "Internal" logic with ECS**

The hint about "internal networks" is the classic use case for **EDNS Client Subnet (ECS)**. I attempted to spoof the client's origin IP to bypass the "internal only" restriction.

* **Attempt 1 (Localhost):** `+subnet=127.0.0.1` -> Result: `FAKEFLAG`.
* **Attempt 2 (Private Range):** `+subnet=10.0.0.1` -> Result: `FAKEFLAG`.

#### 3. Developing the Exploit

Reflecting on the previous challenge in the same CTF infrastructure, I noticed a specific "Leet" IP address (`10.13.37.1`) had appeared in the zone serial history. I hypothesized that the "internal network" for this CTF environment was defined by this specific `10.13.37.x` subnet.

#### 4. The Solution

I crafted a DNS query that explicitly defined the client's subnet as the "Leet" internal IP.

```bash
dig @52.59.124.14 -p 5053 TXT flag.ctf.nullcon.net +subnet=10.13.37.1
```

#### 5. The Winning Payload

The server accepted the spoofed subnet as a trusted internal requester and returned the actual flag:

```plaintext
;; ANSWER SECTION:
flag.ctf.nullcon.net. 300 IN TXT "ENO{Whirr_do_not_send_private_data_for_wrong_IP_Whirr}"
```

#### 6. Result

* **Flag:** `ENO{Whirr_do_not_send_private_data_for_wrong_IP_Whirr}`
* **Lessons Learned:** 1. **ECS Spoofing:** DNS servers that rely on ECS for "security" or "internal views" are vulnerable to IP spoofing because the client (or a malicious resolver) can claim any origin IP.

  1\. **Context Matters:** In a CTF, hints from one challenge (like the `10.13.37.1` IP from the previous DNS task) often provide the keys to the next.

  2\. **Whirr vs Zzzzt:** The change in the "bug sound" from the fake flag (Zzzzt) to the real flag (Whirr) was a clever thematic indicator of success.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://lance-kenji.gitbook.io/me/nullcon-hackim-ctf-goa-2026-writeups/misc/dragonflies.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.