IPSECKEY Lookup
IPsec public keys published in DNS.
Enter a value above to run IPSECKEY Lookup
e.g. example.com
Quick answer
IPSECKEY Lookup shows the IPsec public keys a host has published in DNS, letting devices set up encrypted IPsec connections without exchanging keys in advance. Each record includes the public key, its algorithm, a precedence value for choosing between multiple keys, and an optional gateway address.
The IPSECKEY Lookup queries the DNS IPSECKEY record type (RFC 4025), which publishes IPsec public keys and gateway information directly in DNS. It lets an initiating host discover the key material and gateway needed to set up an IPsec tunnel to a given IP address or hostname, without pre-sharing keys out of band. This tool fetches and decodes any IPSECKEY records for the name you enter, showing the precedence, gateway type, algorithm, and public key. It is mainly useful for operators experimenting with Opportunistic Encryption and IPsec keying via DNS.
How it works
You enter a domain name or a reverse-DNS name (for example an in-addr.arpa or ip6.arpa name derived from an IP). The tool sends a DNS query for the IPSECKEY type and parses the response. Each record contains four fields: a precedence value, a gateway type (none, IPv4, IPv6, or domain name), the public-key algorithm (typically 1 for DSA or 2 for RSA), and the Base64-encoded public key itself. Multiple records may be returned for one name.
How to read the results
Read the precedence first: lower numbers are preferred, so a client tries the lowest-precedence gateway before higher ones. The gateway field tells the peer where to send IPsec traffic; a value of "." or type 0 means no gateway is specified and the queried host is the endpoint. The algorithm number identifies how to interpret the key, and the Base64 blob is the raw public key. If nothing is returned, no IPSECKEY exists for that name.
Why it matters
IPSECKEY is the DNS building block for Opportunistic Encryption: it lets two hosts negotiate IPsec using keys advertised in DNS rather than manual configuration. Because the record is only trustworthy when the zone is signed, IPSECKEY is strongly tied to DNSSEC. Checking these records helps operators confirm that keys and gateways are published correctly before relying on them for automated tunnel setup, and helps diagnose why an expected IPsec association failed to form.
Frequently asked questions
- Is IPSECKEY safe to use without DNSSEC?
- Not really. IPSECKEY publishes a public key that a peer will trust to bootstrap an IPsec tunnel, so an attacker who can spoof or tamper with the DNS answer could substitute their own key. RFC 4025 recommends validating IPSECKEY records with DNSSEC. Without a signed, validated response you cannot be sure the key is authentic, which undermines the whole point.
- Why do I query a reverse-DNS name for an IP address?
- IPSECKEY records are often stored under the reverse-mapping name of the IP you want to reach, such as an in-addr.arpa (IPv4) or ip6.arpa (IPv6) entry. This lets an initiator that only knows a peer's IP address look up its keying material directly. You can also publish IPSECKEY under a normal forward hostname; both forms are valid per the RFC.
- What does the precedence field control?
- Precedence orders multiple IPSECKEY records for the same name, much like MX priority. A client should try the record with the lowest precedence value first, then fall back to higher values if that gateway is unreachable. This lets you publish a primary and one or more backup gateways, or roll out a new key alongside an old one during a transition.