Document UDP DNS tunnels

[alexellis]

Description

Document UDP support in the FAQ and explain that UDP data-plane ports are
published through the existing inlets-pro tcp server and
inlets-pro tcp client mode.

The update includes:

• a UDP-only DNS reverse-proxy example using --udp-port 53
• Pi-hole, CoreDNS, and dnsmasq as representative upstream resolvers
• confirmation that no TCP --port or --ports value is required
• an explanation of datagram framing, source flow tracking, idle cleanup,
  bounded flow state, and server capability checks
• the manual and automated coverage used to validate DNS and UDP forwarding
• guidance for DNS-over-TCP fallback and avoiding an unrestricted public
  recursive resolver

Nearby FAQ descriptions now include UDP alongside HTTP and TCP.

Motivation and context

UDP forwarding shipped in inlets Pro 0.11.13, but the FAQ still described the
product and its data plane primarily in terms of HTTP and TCP. This left the
DNS use case and the intentionally named tcp tunnel mode unclear.

The documentation now shows that a UDP-only tunnel can reverse proxy DNS from
an exit node to a resolver on the client's private network.

User impact

Users can configure UDP DNS forwarding without inferring that a TCP data-plane
port is required. They also get the operational caveats needed for recursive
DNS exposure and TCP-specific DNS behaviour.

Testing

• python3 -m mkdocs build --strict
• checked the commands and limits against inlets Pro 0.11.14
• checked the documented test claims against the UDP prototype findings and
  the framing, flow-table, capability, and end-to-end tests in inlets Pro

[reviewfn]

AI Pull Request Overview

Disclaimer: This review was generated by automated AI and may contain errors. Do not trust its outputs without human verification.

Summary

• Documents UDP support in the existing FAQ and clarifies that tcp tunnel mode can publish UDP ports.
• Adds a UDP DNS reverse-proxy example using --udp-port 53 without requiring TCP data-plane ports.
• Covers operational DNS caveats, including recursive resolver exposure and DNS-over-TCP fallback.
• Explains the implementation at a useful conceptual level: datagram framing, flow tracking, cleanup, limits, and capability checks.
• Updates nearby protocol descriptions from HTTP/TCP-only language to HTTP, TCP, and UDP.

Approval rating (1-10)

9/10. The change is clear, scoped, and publishable; I found no blocking content, rendering, or workflow issues.

Summary per file

Summary per file

File path	Summary
docs/reference/faq.md	Adds UDP DNS tunnel guidance and updates protocol descriptions.

Overall Assessment

This documentation update is well scoped to the FAQ and directly addresses the ambiguity around UDP support in tcp tunnel mode. The DNS example is actionable, the warning about public recursive resolvers is important, and the implementation explanation gives readers enough operational context without turning the FAQ into a low-level design document. I do not see any blocking issues for merge.

Detailed Review

Detailed Review

Content review

No blocking findings.

• The title and body of the changed FAQ section match the likely reader intent: understanding whether inlets uses TCP or UDP and how to publish UDP DNS.
• The opening distinction between the TCP WebSocket control plane and HTTP/TCP/UDP data-plane services reduces potential confusion around the tcp command name.
• The example commands are concise and include the key non-obvious detail that --udp-port 53 does not require --port or --ports.
• The DNS caveats are practical: public recursion is explicitly discouraged, and TCP fallback is separated from the UDP-only example.

AI agent details.

Agent processing time: 1m10.608s
Environment preparation time: 3.203s
Total time from webhook: 1m16.621s