IPSECKEY record
Publishes an IPsec public key and the gateway through which a tunnel should reach a host, network, or application.
Written and maintained by Ben Ennis
Last reviewed July 27, 2026 · How we verify this
Zone-file example
vpn.example.com. 3600 IN IPSECKEY 10 1 2 192.0.2.10 AQOue...Typical uses
- Publishing a gateway and public key for an IPsec peer
- Selecting among direct or indirect gateways during key rollover
- Associating a key with an address found through forward or reverse DNS
- Describing per-host or per-application tunnel endpoints
When it breaks, check
- Lower precedence values are attempted first; equal values are not an ordered failover list
- Gateway type 0 uses a literal dot, while types 1, 2, and 3 require IPv4, IPv6, or an uncompressed domain name
- The public key is algorithm-specific Base64 and must be checked against the configured IPsec implementation
- Use DNSSEC or another authenticated channel before trusting a key or gateway from DNS
What the IPSECKEY record does
IPSECKEY connects DNS naming with IPsec peer discovery. A client first determines the DNS name for the remote host or network, then reads the record to learn both the public key and whether the tunnel should terminate at the named entity or pass through a gateway. Multiple records are valid: the client tries lower precedence values first and may select among equal-precedence records without assuming their order.
The record can be queried through a forward name or a reverse-mapping tree when the application starts with an IP address. It is not an address record, a certificate, or a replacement for the IPsec policy that decides which traffic may use the tunnel. The DNS answer only supplies discovery material; the peer still needs a compatible algorithm, identity policy, and authenticated key exchange.
Zone-file and wire format
IPSECKEY RDATA is precedence gateway-type algorithm gateway public-key. Gateway type 0 means no gateway and uses ., type 1 carries an IPv4 address, type 2 carries an IPv6 address, and type 3 carries an uncompressed domain name. The public key is algorithm-specific and is shown as Base64 in presentation format. The example below uses illustrative values rather than a usable key.
vpn.example.com. 3600 IN IPSECKEY 10 1 2 192.0.2.10 AQOue...Common uses
Use IPSECKEY where an operator wants DNS-based discovery for managed IPsec gateways, planned key rollover, or a service that has a stable name but several tunnel entry points. Publish the complete RRset during a transition and keep the old key available until all clients have refreshed it. Protect the zone and validate its answers; a syntactically correct record can still direct a client to the wrong gateway.
Troubleshooting
When a client selects an unexpected gateway, compare every record at the name and sort by precedence before checking the local selection algorithm. Verify the gateway type matches the presentation value, the algorithm is supported, and the Base64 key decodes to the format expected by the IPsec implementation. Query the authoritative server directly to rule out cached data. For a tunnel that fails after a DNS change, inspect DNSSEC validation, key-exchange identity checks, and the IPsec policy separately; fixing one does not prove the others are correct.
dig vpn.example.com IPSECKEY +dnssec +noall +answer
# Check a reverse-mapping name when the input is an IP address.
dig 10.2.0.192.in-addr.arpa IPSECKEY +dnssec +noall +answerThe defining RFC
IPSECKEY is defined by RFC 4025, including gateway types, precedence, presentation format, and the recommendation to authenticate the RRset. See the IANA DNS Parameters registry for the assigned type.
Reference and tooling
Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.