Summary

  • RFC 8005's HIP resource record publishes a public Host Identity, its HIT and optional rendezvous-server names. The record is a discovery input, not a live proof of private-key use or endpoint reachability.
  • DNSSEC validation and an unexpired TTL are valuable, bounded facts: they protect the DNS data under the validation chain and govern cache reuse. They do not certify the zone publisher, the RVS registration or the later packet path.
  • A defensible operational verdict joins the selected RR, DNSSEC and cache receipts to current RVS registration, I1 relay, HI-based HIP authentication, association completion and application outcome.

The hour that stayed green

At 09:00 a resolver retrieves a HIP RR for a mobile responder. The answer carries the expected HI, its HIT and the name of a rendezvous server. Its DNSSEC chain validates. Its TTL is one hour. An assurance console records all three facts and paints one field green: verified and reachable.

At 09:12 the responder moves to a new network. Its attempt to tell the RVS about the new address fails. DNS does not change; it does not need to. The published RVS name is still correct, the signed RRset is still valid and the cache timer still has 48 minutes to run. At 09:20 an initiator sends I1 to the RVS. The RVS finds the old locator and relays the packet into silence.

This is a constructed scenario, not a report of a deployment or incident. The important point is that the DNS evidence never became false. It continued to answer its own question: what HI, HIT and rendezvous names were published for this owner, and may this cached response still be used? The console silently substituted a larger question: can this endpoint demonstrate its key and receive traffic now?

The failure did not come from weak cryptography. It came from promoting one bounded receipt through several unobserved layers.

RFC 8005 publishes public material, not current possession

RFC 5205 introduced the HIP DNS extension in 2008 as an Experimental RFC. RFC 8005 replaced it in 2016 on the Standards Track. The HIP RR, type 55, can contain the Host Identity, the Host Identity Tag derived from it, and optional domain names of rendezvous servers.

The HI in the record is the public component of a public-private key pair. Publishing it helps an initiator avoid an opportunistic exchange in which the responder's identity was not obtained in advance. The HIT is a compact hash-based identifier for that HI. Both are useful inputs to the later HIP exchange.

Neither is a fresh proof that the endpoint still controls or can use the private key. The DNS response contains public data. Present key use is shown later, when the peer performs HI-based authentication in the protocol exchange. Even that result belongs to a particular exchange and time. It does not retroactively turn the DNS transaction into a possession proof.

RFC 8005 makes one boundary unusually explicit: a HIP end node should not authenticate peers solely from a HIT retrieved from DNS; it should use HI-based authentication. A dashboard that labels a DNS-retrieved HIT as an authenticated live peer discards the very step the RFC tells the endpoint to perform.

DNSSEC protects an answer without enlarging it

The security section recommends obtaining HIP RRs through a secure channel that provides data integrity and authenticity and identifies DNSSEC as the mechanism for that job. This is not faint praise. If an attacker can rewrite an insecure HIP RR, the attacker can substitute public-key material or redirect the initiator toward another address.

But RFC 8005 immediately states the scope. DNSSEC gives integrity and authenticity to the channel between the DNS server publishing the zone and the HIP node. It does not ensure that the entity publishing the zone is trusted. The RRSIG over the HIP RRset must not be interpreted as a certificate binding the HI or HIT to the owner name.

This distinction survives successful validation. secure in a resolver result is evidence about DNS data under a validation chain, trust anchor, time and policy. It is not evidence that the named endpoint is powered on, that the private key remains available, that an RVS holds a current registration, or that a packet crossed the path.

Cryptographic strength and semantic scope are independent. A flawless signature can protect a narrow statement flawlessly. It cannot add a verb that the statement never contained.

A TTL governs reuse of publication state

RFC 8005 clarifies the TTL rule that changed from RFC 5205. When elapsed time since retrieval exceeds the HIP RR's TTL, the retriever must consider the record invalid, delete it and make a new query if it needs the information to initiate communication.

That rule supplies a precise cache boundary. Before expiry, the resolver may reuse the record. After expiry, it must reacquire it. Neither side of the boundary is an endpoint-health measurement.

A one-hour TTL does not ask the responder to keep a key online for an hour. It does not lease an RVS table entry, reserve a locator, freeze routing or promise that an application will answer. Conversely, a re-query at minute 61 can return an identical, freshly validated record while the runtime registration remains broken. DNS freshness is necessary for a fresh DNS claim; it is insufficient for a fresh path claim.

This matters in automation because TTLs are easy to count. A controller can compute an expiry without speaking to the endpoint. That convenience encourages a status model in which cacheAge < ttl becomes serviceHealthy=true. The arithmetic is correct and the inference is not.

The RVS name and the RVS registration live in different stores

The HIP DNS extension addresses mobility by letting a node publish stable rendezvous-server names while separately keeping the RVS up to date with its current IP addresses. RFC 8005 says both things. RFC 8004 describes the runtime registration the RVS consults before it relays an I1.

The DNS record can therefore be completely current while the RVS mapping is absent, expired or wrong. The RVS name may resolve correctly. The server may be reachable. The requested HIT may no longer have a current registration. Or the RVS may relay to an address that was current before a mobility event.

Those are not contradictions. They are different authorities. The zone is authoritative for its published RRset. The resolver can report validation and cache state. The RVS is authoritative for its own current registrations. The endpoint and packet observations show whether the relay reached the responder.

An operations database may join these facts, but it must not overwrite their origins. A useful chain looks like this:

HIP RR published → DNSSEC validated → TTL current → RVS chosen → RVS registration current → I1 relayed → HI authenticated → association completed → application observed.

Every arrow crosses a boundary. A missing receipt should remain unknown, not inherit green from the previous column.

Multiple records make association part of the evidence

RFC 8005 permits multiple HIP RRs at one owner name. It deliberately leaves selection among them outside scope. Their RVS information may be the same or different, and a host must check that the RVS it uses is associated with the HI it selected.

This is an operational warning against flattening. An inventory that extracts all HIs into one set and all RVS names into another can manufacture combinations that the zone never published. A successful lookup for the owner name is not enough; the receipt must preserve which HIT, HI and RVS values came from the same RR and why one record was selected.

During rotation or migration, two records may represent different key generations or service paths. The old record can remain within TTL while the new record is also visible. Without record-level provenance, a controller can select a new key with an old RVS, blame the endpoint for a locally invented pairing, and then call the failure a reachability incident.

What a complete operational receipt contains

The minimum record is not enormous, but it follows the claim through each system:

  • owner name, query type, resolver, authoritative source, request and response times, and packet fingerprint;
  • complete HIP RRset, preserving each HI, HIT and RVS association and the record-selection decision;
  • DNSSEC result, trust anchor, algorithms, validation policy and relevant signature times;
  • retrieval time, TTL, cache age, calculated expiry and proof of re-query after expiry;
  • independently resolved A and AAAA records for the chosen RVS, with their own TTL and validation state;
  • current RVS registration identifier, target HIT, locator set, refresh, expiry, cancellation and configuration epoch;
  • I1 send, RVS receive, registration lookup, relay and endpoint receive observations;
  • HIP transcript, selected HI, signature result and association state at both peers;
  • payload-path and application-result evidence recorded separately;
  • explicit unknowns at the first unobserved transition.

This structure keeps DNSSEC valuable. It also keeps it honest. The resolver does not have to pretend it saw an RVS table; the RVS does not have to certify private-key use; the HIP exchange does not have to claim an application outcome.

RFC lineage is not deployment evidence

RFC 8005 added ECDSA Host Identities, clarified TTL re-query, described multiple records and refined encoding and RVS wire format. Those changes matter to implementers. They do not prove that a named build implements them, that a zone migrated its records, or that an operator updated selection logic.

A production receipt should therefore name the implemented HIP version, DNS parser, supported algorithms, deployed build and configuration. A standards reference identifies the intended specification. Packet and state evidence identify the running system.

The same discipline prevents a different error: treating RFC 5205's Experimental status as evidence that every deployment is unsafe. Status is part of document history, not a measurement of a particular instance. The right question is which semantics the running code implements and what happened in this transaction.

Discovery is useful because it does not claim everything

The HIP RR solves a real coordination problem. It lets an initiator obtain public identity material and learn where initial contact may begin. DNSSEC can protect that discovery from important classes of tampering. TTL gives caches a coherent reuse rule. None of these values is diminished by refusing to call them liveness.

The stronger design is to let each layer speak with its own authority. DNS says what was published and validated. The RVS says what it registered and relayed. The HIP endpoint demonstrates current key use. The association state shows protocol completion. Packet and application observations show delivery and effect.

In the constructed outage, the correct console would stay precise: HIP RR secure; TTL current; RVS registration unconfirmed; endpoint reachability unknown. That line is less comforting than one green badge. It is also actionable. It points directly to the missing update instead of sending engineers to rotate DNS keys or rewrite a zone that behaved correctly.

The record was fresh. The path was not. Good evidence architecture allows both sentences to be true at once.

Sources