An SSH client has to decide whether the host key presented by a server belongs to the intended host. A previously stored key can provide that reference on later connections, but the first connection needs another basis for authentication. SSHFP places a fingerprint of an SSH host public key in DNS so a client can compare the server key with independently retrieved data.
The DNS record alone is not a trust anchor. RFC 4255 ties trusted SSHFP verification to authenticated DNS data. DNSSEC protects the lookup path and lets a validating client distinguish signed data from an unauthenticated DNS answer. The useful security property comes from that combination: SSH supplies the host key, SSHFP carries its fingerprint, and DNSSEC authenticates the DNS record used for comparison.
The record identifies both key and digest algorithms
SSHFP is DNS resource-record type 44. Its RDATA has three fields: an SSH public-key algorithm number, a fingerprint type, and the fingerprint bytes.
The presentation format is compact:
host.example. IN SSHFP <algorithm> <fp-type> <fingerprint>The algorithm field identifies the SSH public-key algorithm whose key was fingerprinted. The fingerprint type identifies the digest applied to the SSH public-key blob. A client does not compare the hexadecimal fingerprint in isolation; the key algorithm and fingerprint type determine what that value represents.
RFC 4255 originally assigned RSA and DSA key algorithm numbers and SHA-1 fingerprint type 1. RFC 6594 later assigned ECDSA algorithm number 3 and SHA-256 fingerprint type 2. RFC 7479 assigned algorithm number 4 to Ed25519. Current deployments therefore need to treat the numeric fields as protocol identifiers rather than infer their meaning from fingerprint length.
For an Ed25519 key with a SHA-256 fingerprint, the record has this shape:
host.example. IN SSHFP 4 2 <SHA-256 fingerprint in hexadecimal>The fingerprint is computed from the SSH public-key blob, not from the textual line commonly stored in an authorized_keys or public-key file.
A matching fingerprint is useful only with authenticated DNS
A network attacker who can replace an SSH host key may also be able to alter ordinary DNS traffic. If the attacker can substitute both values, an unsigned SSHFP record merely moves the same trust problem into DNS.
RFC 4255 therefore states that a public key verified through SSHFP must not be trusted when the SSHFP record used for verification lacks trusted DNS authentication. A client that performs DNSSEC validation locally can apply the normal DNSSEC chain-of-trust checks. If validation is delegated to another component, the path between the SSH client and that validator also becomes part of the security boundary.
This distinction prevents a common configuration error: publishing SSHFP records in an unsigned zone does not by itself create authenticated first-contact SSH verification. The records remain useful metadata, but their integrity has not been established through DNSSEC.
Verification compares the server key with the DNS record
During connection setup, the server presents an SSH host public key. An SSHFP-aware verification path can retrieve the SSHFP RRset for the target host and select records compatible with that key algorithm.
For each compatible record, the client computes the digest indicated by the fingerprint type over the received public-key blob. The result must match the fingerprint carried by an authenticated SSHFP record.
Conceptually, the path is:
server public key ----> digest ----+
|
+--> equal?
|
DNSSEC-validated SSHFP ------------+A mismatch does not prove that the server is malicious. It can also indicate stale DNS data, incomplete host-key rotation, a connection to an unexpected address, or an administrative error. It does mean that the DNS-published assertion and the key presented by the SSH endpoint do not agree, so the SSHFP check cannot authenticate that key.
Multiple SSHFP records can coexist. This is useful when a server offers several host-key algorithms or during a controlled key transition. Each published fingerprint remains bound to its algorithm and digest identifiers.
SHA-256 separates fingerprint strength from the host-key algorithm
The SSH key algorithm and the fingerprint digest serve different roles. RSA, ECDSA, or Ed25519 identifies the form of the host public key. SHA-256 in an SSHFP record is the digest used to derive a compact fingerprint from that public key.
RFC 6594 added SHA-256 as fingerprint type 2 and says SSHFP-aware SSH implementations should support it. The same RFC notes that SHA-256 fingerprints should be preferred over SHA-1 when both are available.
That preference does not transform the underlying host key. An RSA host key fingerprinted with SHA-256 remains an RSA key; only the digest used for the DNS fingerprint changes. Treating these fields separately also permits protocol registries to add key algorithms and fingerprint types without redesigning the SSHFP record format.
DNS names and resolver policy remain part of the boundary
SSHFP associates a fingerprint with a DNS owner name. The name selected for lookup therefore matters. RFC 4255 calls out clients that connect using unqualified host names: a manipulated DNS search path could cause a lookup for a different fully qualified name than the operator intended.
Local host-key databases and SSHFP can also coexist. Client policy determines the order and conditions under which those mechanisms are consulted. SSHFP does not erase existing trust decisions in known_hosts, nor does the specification require every client to prioritize DNS-based verification over local state.
This makes deployment policy as important as record publication. Operators need a stable mapping among the name users connect to, the SSH endpoint serving the key, the SSHFP RRset, and the DNSSEC-signed zone containing that RRset.
Key rotation requires DNS and SSH state to move together
A host-key change creates two pieces of state: the key served by SSH and the fingerprint published in DNS. Updating only one side creates a temporary mismatch.
A transition can publish fingerprints for keys that need to be accepted during the migration window, then remove obsolete records after the old key is no longer served. Exact sequencing depends on client behavior, DNS caching, TTLs, and the server’s host-key configuration. SSHFP itself does not provide an atomic transaction across DNS and the SSH service.
Removing a fingerprint can also participate in revocation policy when clients are configured to require SSHFP, but that behavior depends on client policy and authenticated DNS state. It is not equivalent to a universal SSH revocation mechanism.
The operational boundary is narrow and useful. SSHFP gives DNS a standard representation for SSH host-key fingerprints; DNSSEC gives that representation authenticated provenance. Neither replaces the SSH handshake or the server’s possession of its private key. Together they provide a protocol-defined reference that a client can use when deciding whether a presented host key matches the identity published for a DNS name.