SSHFP Publishes SSH Host Key Fingerprints Through DNSSEC

SSH clients need a trustworthy basis for deciding whether a server’s host key belongs to the intended host. A local known_hosts entry supplies that basis after a key has been accepted, but the first connection still needs a verification path if the key was not provisioned in advance.

SSHFP moves a host-key fingerprint into DNS. RFC 4255 defines the SSHFP resource record so a client can compare the public key presented by an SSH server with a fingerprint published for that hostname. The security property depends on authenticated DNS data: a matching fingerprint from an unauthenticated DNS answer does not provide the trust condition defined for secure SSHFP verification.

An SSHFP record identifies a key algorithm and fingerprint

SSHFP RDATA contains three fields: a public-key algorithm number, a fingerprint type number, and the fingerprint itself.

host.example. IN SSHFP 4 2 <fingerprint>

The numeric fields are protocol identifiers, not free-form labels. The public-key algorithm field identifies the SSH key family represented by the record. The fingerprint type identifies the digest algorithm used to derive the stored fingerprint. RFC 6594 added SHA-256 as an SSHFP fingerprint type and extended the public-key algorithm registry for ECDSA.

Verification requires both the algorithm identifier and computed fingerprint to match the presented host key. A digest that happens to equal a record associated with another key algorithm is not a valid match under the SSHFP processing rules.

DNSSEC supplies authentication for the DNS answer

Publishing an SSHFP record in ordinary unsigned DNS does not by itself create a secure host-key assertion. An attacker able to alter the DNS response could otherwise replace the fingerprint together with the network path to the SSH server.

RFC 4255 therefore ties trust in SSHFP verification to DNSSEC authentication. The client either needs to validate DNSSEC itself or rely on a resolver path whose authenticated result is conveyed securely enough for the client’s trust model.

This separates two operations:

DNSSEC validation -> authenticates the SSHFP DNS data
SSHFP comparison  -> binds that data to the presented SSH host key

Neither operation substitutes for the other. A DNSSEC-valid record containing the wrong fingerprint causes a mismatch. A matching fingerprint obtained without authenticated DNS lacks the secure DNS assertion required for automatic trust.

OpenSSH exposes the policy through VerifyHostKeyDNS

OpenSSH clients provide VerifyHostKeyDNS for SSHFP-based host-key checks. With yes, a key matching a secure DNS fingerprint can be implicitly trusted. With ask, fingerprint information is presented while normal host-key confirmation policy still applies. The documented default is no.

Host server.example
    VerifyHostKeyDNS yes

This setting is a client policy choice. Merely publishing SSHFP records does not force every SSH client to consult them, and clients that do not enable a compatible verification policy continue to use their configured host-key mechanisms.

OpenSSH can also generate SSHFP presentation records from a host public key with ssh-keygen -r. Generation reduces manual digest handling, but the generated record still has to enter the authoritative DNS zone through a trusted administrative path.

Enrollment is part of the security boundary

DNSSEC protects DNS data after it is incorporated into the signed zone and validated by the client. It does not prove that the zone operator received the correct host key before publishing its fingerprint.

The transfer from host-key management into DNS is therefore an enrollment step. If an unauthorized key is inserted into the zone and correctly signed, DNSSEC faithfully authenticates the incorrect administrative state. Automation that publishes SSHFP records needs authenticated input, controlled zone-update authority, and a clear association between hostname and host key.

This boundary resembles other public-key enrollment systems: cryptographic validation can preserve an assertion without establishing that the assertion was correct at creation time.

Rotation requires DNS and server state to overlap deliberately

A host may publish multiple SSHFP records. That property can support key transitions by allowing fingerprints for more than one valid host key during a controlled overlap.

The sequence still matters. Publishing a new fingerprint before clients can encounter the new key avoids a window in which the server presents a key absent from authenticated DNS. Removing the old fingerprint after the old key is no longer served narrows the accepted set again.

DNS caching adds another timing boundary. TTLs and resolver caches can keep an earlier signed RRset visible for a period after an authoritative change. Rotation procedures need to account for that propagation behavior rather than treating an authoritative update as instantaneous at every client.

SSHFP does not replace SSH transport security

SSHFP participates in host authentication; it does not encrypt the DNS query, carry SSH session traffic, or replace the SSH key exchange. Once the host key is accepted, SSH protocol mechanisms still establish and protect the session.

DNSSEC also provides data origin authentication and integrity for signed DNS data, not confidentiality. A deployment that requires DNS query privacy needs a separate mechanism for that property.

The narrow role is useful precisely because it is explicit. SSHFP publishes a fingerprint for a host key, DNSSEC authenticates the DNS assertion, and client policy decides whether a secure match is sufficient for host-key acceptance. Keeping those boundaries separate makes first-contact verification depend on a managed trust path instead of an unverified prompt.