Summary

  • Hugo Salgado, Mauricio Vergara Ereche and Duane Wessels authored RFC 9660, published in October 2024. Its ZONEVERSION option lets a client ask an authoritative DNS server which version of a zone produced a specific answer.
  • The answer can carry a version token, including for certain negative answers and referrals. Salgado's first-person LACNIC account describes how an operator's idea gained the people and revisions needed for an IETF standard.

The DNS can give two answers that look like a disagreement in the data when the real difference is the copy of the zone behind each server. A serial number in the zone's SOA record was already public. Hugo Salgado wanted a diagnostic tied to the answer being examined: tell me which zone version produced this response. In RFC 9660, that request became ZONEVERSION, EDNS option 19.

The mechanics are small enough to miss the institutional work behind them. A client adds an empty ZONEVERSION option to a query sent to an authoritative server. A server that understands and honours it can reply with a type and version value for the enclosing zone. The standard spells out where this can help: a positive answer, a referral, even certain NXDOMAIN or NODATA replies. The operator comparing inconsistent responses gets a label attached to each observation.

Salgado describes the birth of the idea in a first-person account published by LACNIC. He says he first raised it roughly five years before the 2024 article to solve an operational DNS need. His account makes the standardisation process sound less like a clean march through version numbers and more like what it was: a proposal needed someone in the mailing lists and meeting corridors to make the operator problem legible. Mauricio Vergara Ereche did that work, Salgado says. Duane Wessels joined the author team late and helped bring the document through final editing and IANA review. The 2022 working-group draft names Salgado and Vergara Ereche; the final RFC names all three.

The resulting option is deliberately specific. The VERSION field can be based on the SOA serial or another defined type, but it labels the zone version relevant to a reply. A recursive server cannot simply pass the option on as though it were transparent glass; the standard says it is not transitive. An authoritative server may also choose whether to answer a ZONEVERSION request. Those choices matter when someone tries to use the tool in an incident: first establish that the queried server supports the option and that the response came from the authority being tested.

There is another tempting category error. The version label identifies a copy; RFC 9660 points to ZONEMD for whole-zone integrity checks. When two servers disagree, knowing which version replied can direct the investigation. Deciding whether the version is complete or correct needs other evidence.

The IANA DNS registry now carries code 19 and the associated type registry. Dated queries to named servers, paired with operator deployment reports, would establish how many live authoritative fleets return the option. Salgado's achievement is already concrete: a DNS answer gained a place to identify its source version, after years of persuading people that such a small field was worth standardising.