Domain Name System (DNS)

Overview

The Domain Name System maps names to resource records. Normal DNS queries often use UDP port 53. DNS also uses TCP for truncated responses, large messages, zone transfers, and other cases. A complete private DNS access design can need both transports.

Private DNS can expose internal names and service topology. A Pomerium route controls who can start the selected DNS path while the DNS server keeps its protocol and record controls.

Pomerium controls who can start each selected DNS route. The private DNS server remains responsible for record data, recursion policy, DNSSEC, access control, and service operation.

How it works

Create a separate Pomerium route for each required HTTP, TCP, UDP, or SSH endpoint. Do not send internal cluster, gossip, replication, or control-plane traffic through a user route.

Use a web route for browser traffic and a supported Pomerium client or native access flow for non-HTTP traffic. Keep service-level TLS, authentication, and authorization active.

Create distinct UDP and TCP routes for the required DNS server address. Test truncation fallback, large answers, IPv4, IPv6, search domains, and the expected resolver client behavior.

Example

An administrator uses a local Pomerium UDP route for normal queries and a separate TCP route for fallback and large responses. The private DNS server remains unreachable from the broad network.

Considerations

• A TCP-only route is incomplete for normal DNS use. A UDP-only route is incomplete for responses and operations that require TCP.
• CONNECT-UDP support in every proxy and user-to-Pomerium latency can affect DNS behavior and performance.
• Pomerium checks TCP and WebSocket policy when the connection starts. A later policy change does not terminate an established connection.
• For TCP tunnels, place Pomerium behind an L4 or TCP edge. Any HTTP proxy in front of Pomerium must forward CONNECT traffic.