Summary

  • Roy Arends was one of five co-authors of the 2005 DNSSEC core; his lasting contribution is collective protocol design and operational stewardship, not sole invention or control of the DNS root
  • NSEC3, Extended DNS Errors and DNS Error Reporting show a career focused on making cryptographic failure and negative answers more diagnosable without treating optional signals as complete evidence
  • The planned 2026 root KSK rollover turns a global security transition into local work for independent resolver operators, where a reassuring readiness percentage still cannot represent every installation
  • Current work around delegation extensions and dry-run DNSSEC applies the same principle to future change: publish early, observe behaviour, preserve fallback and make failure recoverable before enforcement becomes irreversible

Key tag 38696 turned a global change into local work

In late July 2026, Roy Arends published a number that many network administrators would never normally need to know: 38696. It is the key tag for KSK-2024, the new key-signing key prepared for the root of the Domain Name System. ICANN planned to begin signing the root using only that key on 11 October 2026. For most users, the change was intended to be invisible. For a validating resolver that had failed to learn the new trust anchor, the outcome could be very visible: signed names might stop resolving even though the websites, mail servers and networks behind them were working normally.

The practical instruction was straightforward. Resolver operators should check that key tag 38696 was present in their trust-anchor configuration and confirm that automatic update mechanisms could write to the relevant files. The simplicity of that check concealed the structure of the problem. There is no global inventory of every recursive resolver, no administrator who can force all of them to upgrade, and no single telemetry feed that reports every broken configuration. A key prepared through centrally coordinated ceremonies becomes dependable only after large numbers of independently operated systems have accepted it.

Arends reported that more than 95 per cent of reporting resolvers had recognised KSK-2024. The denominator matters as much as the percentage. These were resolvers that emitted a usable readiness signal, not a census of every validating installation on the Internet. Machines that had stopped reporting, were configured differently, had spent long periods offline or could not update a read-only trust-anchor file could be missing from the evidence. The figure supported confidence; it did not turn a distributed system into a controlled one.

That distinction captures the thread running through Arends' public career. He has worked on rules that let DNS data be authenticated, mechanisms that make negative answers and failures more intelligible, and research intended to reduce the risk of changing a system with no universal maintenance window. His name appears on seven published RFCs in the IETF Datatracker at the source cutoff, including the three documents that established the modern DNSSEC architecture, NSEC3, Extended DNS Errors and DNS Error Reporting. It also appeared on active work concerning delegation extensions and dry-run DNSSEC.

The record is substantial, but it is easily distorted by the mythology that gathers around Internet infrastructure. Arends did not invent DNSSEC alone. He does not personally operate the root zone, command the root-server system or decide what every resolver trusts. His influence comes from shared specifications, institutional research, measurements, review and operational explanation. The more useful question is therefore not who controls DNS security, but how a standards engineer helps change critical infrastructure when the people who must implement the change remain independent.

The root's authority is deliberately divided

The root of the DNS is often described as though it were a single machine or one institution. Operationally, it is a chain of separated responsibilities. ICANN coordinates unique identifiers and related policy and technical work. Public Technical Identifiers performs the IANA functions. Verisign carries out Root Zone Maintainer duties under defined arrangements. Twelve organisations operate the thirteen named root-server identities through distributed infrastructure. Recursive resolver operators decide what software to run, whether to validate DNSSEC and how to maintain their local trust anchors.

Arends works inside one part of that chain. His ICANN biography says he joined the organisation in July 2015 and describes him as a Principal Research Scientist responsible for research design, data collection, analysis and project delivery. The same profile displays the label Distinguished Technologist. Those descriptions establish a technical and institutional role; they do not create executive authority over the organisations and operators surrounding the root.

The distinction is more than an exercise in accurate job titles. Distributed authority is one reason the DNS can survive the failure or disagreement of an individual actor. It is also why change takes time. A root-zone plan can be meticulously prepared and still encounter old resolver software, disabled update logic, inaccurate clocks, restrictive file permissions or local policies that no central team can inspect. Coordination has to work through published rules, long lead times, testable identifiers and evidence that enough of the installed base is ready.

Standards work is divided in a similar way. An RFC carries the names of its authors, but the document emerges from working-group discussion, implementation experience, objections, revisions and wider IETF review. The Datatracker listed no active formal IETF role for Arends at the source cutoff. That does not diminish his authorship; it clarifies the source of his authority. He can propose, explain and persuade. Consensus and deployment belong to a larger community.

A profile that calls him the man who controls DNS security would miss the important part of the story. The work matters precisely because control is dispersed. The engineering challenge is to make independent decisions converge without pretending they have become one decision.

That separation also limits the damage one mistake can cause, while making responsibility harder to explain during an incident. A faulty child-zone signature belongs to one operator; a stale trust anchor belongs to another; a root publication problem would involve a different institutional chain. Users experience all three as a name that does not resolve. Good protocol design therefore has to preserve these boundaries internally while producing enough evidence for people outside them to find the fault.

Five authors gave modern DNSSEC its operating rules

The ordinary Domain Name System maps names to records used by applications and networks. Its original design did not give a resolver a cryptographic way to prove that an answer had not been substituted. An attacker able to feed a resolver false information could try to redirect a name, suppress it or corrupt the resolver's cache. DNS Security Extensions address that weakness by allowing zones to sign sets of records and resolvers to validate those signatures through a chain of trust.

The architecture used today was set out in three RFCs published in March 2005. RFC 4033 explains the model and requirements. RFC 4034 defines the record formats, including DNSKEY, RRSIG, NSEC and DS. RFC 4035 describes the changes required of authoritative servers and validating resolvers. Roy Arends shared authorship of all three with Rob Austein, Matt Larson, Dan Massey and Scott Rose. The five names matter because the protocol was collective work built on earlier DNSSEC efforts, not a sudden invention by one individual.

A zone-signing process produces digital signatures over resource-record sets, or RRsets. The public keys needed to check those signatures are published in DNSKEY records. RRSIG records carry the signatures. A parent zone can publish a DS record that identifies a key used by a child zone. A validator beginning with a trusted key can then follow the relationship from parent to child and decide whether the answer is secure, insecure or bogus under the protocol's rules.

A lookup through that chain involves several independently operated zones. The validator may begin from its configured root trust anchor, validate the signed root data, use the parent's DS record to authenticate a child key and continue until it reaches the requested name. No single zone signs on behalf of all the others. Each administrator controls its own keys and records, while the common protocol lets the resolver test whether the hand-offs fit together. A failure at one delegation can interrupt the chain even when the zones above and below it are otherwise healthy.

The important word is authenticate. DNSSEC can provide evidence that signed DNS data is the data authorised through the chain of trust and that it has not been altered undetectably. It does not encrypt the query or response. It does not establish that the service named by a record is honest, patched or available. A correctly signed record can point to a harmful destination, and a secure DNS answer can lead to an application connection that fails for reasons outside DNS.

That narrowness is a strength when it is understood. The protocol solves a defined integrity problem without turning DNS into a central directory of approved services. It lets independently administered zones participate in a shared validation chain. The same narrowness creates operational discipline: every link has to be generated, published, refreshed and timed correctly, while validators need a usable trust anchor and support for the algorithms involved.

The 2005 documents also had to coexist with unsigned DNS. Deployment could not depend on every zone becoming secure at once. A validating resolver therefore distinguishes an unsigned delegation from a signed chain that fails validation. The difference is essential. An insecure answer may be accepted because the chain explicitly ends; a bogus answer is rejected because cryptographic evidence was expected and did not validate. This allows incremental deployment without treating the absence of DNSSEC as an automatic outage.

Those semantics moved DNSSEC from a cryptographic idea towards an interoperable operational system. They also established the failure mode that shaped much of Arends' later work. A security mechanism designed to prevent false answers sometimes has to refuse to return an answer at all. Once the resolver fails closed, an operator needs to know whether the fault lies in a signature, a delegation, an algorithm, a clock, a trust anchor or the path to an authoritative server.

The documents became infrastructure because different software teams could implement the same wire records and validation states. That did not make implementations identical. Choices about supported algorithms, cache behaviour, logging, time handling and user-facing errors still affect operations. Common rules narrow disagreement to a set of testable behaviours; they do not remove the engineering required to make those behaviours dependable in a particular resolver or authoritative service.

Cryptographic trust can fail as a loss of reachability

For a user, a DNSSEC fault rarely arrives labelled as a cryptographic problem. A site may appear unavailable, mail may fail to reach its destination, or an application may report that it cannot find a host. The authoritative servers can be online and the underlying address can still be reachable. The resolver has refused to use the DNS answer because the proof attached to it did not meet the expected chain of trust.

Several routine mistakes can produce that outcome. A parent can publish a DS record that no longer matches the child's active key. A signature can expire. A zone can be signed with an algorithm the validator does not support. A server or validator with an inaccurate clock can judge a valid signature to be outside its permitted period. A trust-anchor file can be stale. Each failure is local in origin but potentially broad in effect because applications depend on name resolution before attempting a connection.

The same property that blocks forged data therefore raises the cost of operational error. Unsigned DNS often returns an answer even when the operator's security practice is weak. A broken DNSSEC chain is meant to stop. That protects users from accepting data that cannot be authenticated, yet it can make a correctly operated service unreachable after a key-management or delegation mistake.

The 2005 architecture anticipated that validation status would need to shape resolver behaviour, but early user-facing diagnostics remained limited. Applications commonly saw a broad DNS failure rather than a detailed account of which proof had failed. The engineer responsible for a signed zone might see healthy authoritative servers while remote validating users saw nothing. The evidence needed to diagnose the fault sat at the resolver, often in another organisation and sometimes on another continent.

This is where protocol correctness and operational usability separate. A standard can specify exactly how a validator reaches a decision while leaving the people involved with an opaque incident. A resolver may log rich detail locally, but that does not automatically reach the authoritative operator, the help desk or the application. As DNSSEC moved from controlled tests into ordinary infrastructure, failure needed a language that could travel.

Arends' later RFC work can be read as an effort to make that language more precise. The question is no longer only whether an answer validates. It is whether the system can explain a refusal well enough for the right operator to repair it without weakening the protection that caused the refusal.

NSEC3 made non-existence provable without publishing names in order

Positive DNSSEC answers carry signed records. A negative answer has a different burden. When a resolver asks for a name that does not exist, an attacker could simply suppress the real answer and claim that the name is absent. A validating resolver needs cryptographic evidence of non-existence, not only signed statements about records that are present.

The original 2005 record set included NSEC. NSEC records link existing names in canonical order, creating a signed chain that can prove there is no name between two points. The mechanism is elegant, but it also allows a questioner to walk the chain and discover the sequence of names in a zone. DNS data is public when queried, yet many operators did not want the complete set of names made easy to enumerate in order.

NSEC3, standardised in RFC 5155 in March 2008, changes the representation. Owner names are hashed, and the signed chain covers those hashed values. A resolver can reproduce the relevant hash and validate that the requested name falls into a proven gap. The zone no longer publishes its names directly in lexical order through the denial chain. Arends co-authored the specification with Ben Laurie, Geoff Sisson and David Blacka.

Hashing does not turn the zone into a confidential database. An attacker can still make guesses, hash likely names and compare them with published values. The cost depends on the names, parameters and attacker's resources. A zone full of predictable labels may remain comparatively easy to analyse. NSEC3 reduces straightforward enumeration; it does not promise secrecy.

The specification also includes an opt-out mechanism. Large delegation-centric zones can omit certain unsigned delegations from the NSEC3 chain, reducing the signing and response burden. That choice changes the proof and security properties around those delegations. It helps DNSSEC coexist with a world in which many child zones are unsigned, but it creates additional reasoning for validators and operators.

NSEC3 parameters carry performance consequences as well. More hashing work can increase CPU cost for authoritative servers, signers, validators and attackers. Negative answers can become larger. Operators therefore need values that fit their threat model and service capacity rather than treating a larger iteration count as automatically safer. The mechanism is a compromise among authenticated denial, exposure, scale and operational cost.

Arends had also co-authored RFC 4956, an experimental document on DNSSEC Opt-In published in 2007. That work belongs to an earlier attempt to make signed parent zones manageable when many delegations remained unsigned. NSEC3's opt-out design became the more durable standards-track answer, but the sequence is useful: deployment pressure did not arrive after the architecture was finished. It shaped the mechanisms used to carry DNSSEC into large, mixed environments.

This is revealing because it deals with a problem created by making the first security mechanism deployable. Once DNSSEC could prove non-existence, the proof itself exposed information. NSEC3 did not eliminate that tension; it changed the balance and documented the costs. That is typical of infrastructure standards. A useful protocol rarely removes every trade-off. It makes the trade-off explicit enough that independent implementations can reach compatible results.

SERVFAIL gave operators too little to work with

A resolver that cannot provide an answer may return SERVFAIL. The code is useful because it tells an application that the name was not simply absent. It is also frustratingly broad. A DNSSEC validation error, an unreachable authoritative server, an unsupported algorithm, a network timeout, stale data or a local policy decision can end at the same visible result.

RFC 8914, published in October 2020, introduced Extended DNS Errors. Arends co-authored it with Warren Kumari, Evan Hunt, Mark Andrews and Wesley Hardaker. The mechanism adds an option in EDNS carrying a numeric information code and, where appropriate, explanatory text. The ordinary response code remains in place, while the extended code can say more about the condition that produced it.

The practical improvement is immediate. A resolver can distinguish a DNSSEC signature that has expired from a condition in which no reachable authoritative server responded. It can identify that a response was filtered, that an answer is stale or that policy affected resolution. Operators and applications no longer have to infer every cause from the same broad failure.

The extension is evidence, not omniscience. A resolver generates the code from what it observed and understood. The original cause may sit further upstream. An intermediary may discard the option. An implementation may support only part of the code set or attach text that is incomplete. A message saying a signature expired can be a strong diagnostic clue without proving that no other fault occurred.

The optional text creates another boundary. Human-readable detail can make support faster, but it can also disclose internal policy, filtering decisions, topology or implementation information. An operator has to consider what is revealed to whom. Numeric codes provide structure; free text introduces local judgement and potentially sensitive context.

Extended DNS Errors show how standards can improve operations without changing the fundamental validation decision. A bogus answer remains bogus. The resolver is not asked to relax security so the user can reach the destination. It receives a way to explain why it refused. That separation protects the security property while making remediation more practical.

The RFC also illustrates the kind of authority Arends exercises. A shared vocabulary can be defined in a standard, but no RFC can require every resolver, application, middlebox or support system to preserve and display it. Usefulness grows through implementation, careful propagation and operator practice. Publication begins that work; it does not prove that the work has been completed.

The human path remains uneven. A resolver may generate a precise code while an operating system, browser or application replaces it with a generic connection message. A support team may see the user's symptom but lack access to resolver logs. The standard improves the information available at one layer; products and operating procedures determine whether it reaches the person who can use it.

Error reports make remote failures visible and create new risks

Extended errors improve the answer seen near a resolver. They do not automatically inform the operator of the authoritative zone whose data failed validation. That operator may have no direct relationship with the affected resolver and may not know that users elsewhere are receiving errors. DNS Error Reporting, published as RFC 9567 in April 2024, addresses that gap. Arends co-authored the RFC with Shumon Huque.

The mechanism allows a domain to indicate a designated reporting agent. A participating resolver that encounters selected errors can send a structured report to that destination, subject to implementation rules, rate controls and local policy. The aim is to give the people responsible for a zone evidence that would otherwise remain trapped in remote resolver logs.

That feedback can shorten incidents. A child zone with a mismatched DS record may look healthy to its own monitoring if the tests do not validate from enough external vantage points. Reports from resolvers can show that failures are distributed across networks, software versions or locations. They can also reveal intermittent compatibility problems that a single test system misses.

The same information can be sensitive. A report may expose that a resolver attempted to reach a name, the type of error it observed, timing and aspects of local behaviour. A badly designed reporting destination could attract excessive traffic. An attacker could try to manufacture errors or abuse the mechanism for amplification, reconnaissance or operational noise. RFC 9567 therefore treats reporting as voluntary and includes privacy and rate considerations rather than defining a universal stream of resolver events.

The resulting dataset will always have a denominator problem. Some resolvers will report; others will not. Some domains will publish reporting instructions; others will not. Operators may sample or suppress events. A burst of reports can establish that a problem exists, but a quiet dashboard cannot establish that every resolver is healthy. The mechanism extends visibility without creating a global census.

This boundary is central to Arends' work. Better error signals are valuable because DNS responsibility is distributed. They are incomplete for the same reason. Each organisation decides whether to send, receive, retain and act on the information. The protocol can define the hand-off; governance, privacy practice and operational trust determine whether it becomes useful.

By the time DNS Error Reporting became an RFC, the shape of Arends' contribution was clearer. The 2005 documents defined how validation works. NSEC3 refined how absence is proved. Extended errors explained a failed decision. Error reporting tried to move the evidence to someone able to repair the underlying zone. The progression is from cryptographic correctness towards an operational feedback loop.

ICANN moved Arends closer to operational evidence

Arends joined ICANN staff in July 2015. The move placed a long-standing standards contributor inside an institution that coordinates the Internet's unique identifiers and supports research around the DNS root. His published remit covers research design, data collection, analysis and project delivery. It does not provide a public account of every internal assignment, budget or reporting line.

The institutional setting changed the scale of the questions available to him. An IETF document can specify what a resolver or authoritative server should do. ICANN-related research can examine how root operations, trust-anchor distribution and resolver behaviour look across a diverse installed base. The two forms of work are complementary: standards need operational evidence, while measurements need protocol concepts that explain what is being observed.

Arends' public ICANN work includes analysis of hyperlocal root service, participation in a root-zone algorithm rollover study and operator communication around the 2026 KSK change. He also used ICANN's technical platform to explain active IETF work on delegation. These activities do not make ICANN the owner of the IETF process or Arends the operator of each system being studied. They show an institutional bridge between research, standards and operations.

The people and organisations around that bridge have different responsibilities. IETF participants debate protocol text. ICANN research teams can study identifier-system behaviour and communicate findings. PTI and Verisign perform defined root-zone functions. Root-server operators deliver the published zone through their own systems. Resolver developers turn standards into software, and network administrators decide when and how to deploy it. Arends can move among several of these conversations, but the authority to act remains with the party operating each layer.

That bridge can be influential because ICANN has access to root-related planning, communities and data. It also requires restraint. Measurements collected near the root can appear more complete than they are. A percentage derived from reporting resolvers has to keep that population in its label. A study of a possible algorithm rollover cannot be reported as a decision to execute one. A draft discussed in an ICANN blog remains an IETF work item whose text and status can change.

Arends' authority in this setting is mostly technical and reputational. The public record does not establish a unilateral budget, command over root-server operators or a veto over standards. His work can shape what operators monitor and how institutions frame a transition. The act of changing keys, software or local policy remains distributed.

The delayed 2018 rollover changed the playbook

The first rollover of the root zone's key-signing key was completed in October 2018. It supplied a practical lesson that the protocol alone could not provide. A trust anchor can be generated and published correctly while uncertainty about resolver readiness still justifies delay, more measurement and more outreach.

RFC 5011 defines an automated way for a validating resolver to learn a new DNSSEC trust anchor. A new key is published while the old one remains trusted. The resolver observes the new key for a defined period before accepting it, reducing the risk that a short-lived or maliciously introduced key becomes trusted immediately. The process assumes the resolver runs during the observation window, receives the relevant data and can persist the update.

That observation period is a security control. It prevents a resolver from trusting a newly seen key immediately, giving the operator time to detect an unexpected change. It is also an availability dependency. A resolver that misses enough of the overlap cannot simply infer that the replacement key is legitimate. The caution that protects the trust anchor can leave a neglected installation unable to validate after the old key is retired.

Those assumptions are ordinary until one fails. A resolver can spend too long offline. Software can disable the update feature. The process can run under an account that lacks permission to write the trust-anchor file. An appliance may have unusual maintenance practices. A manually configured installation may never adopt a key unless an operator intervenes. None of these conditions can be repaired by publishing the correct root data more loudly.

The 2018 experience encouraged a more explicit readiness programme for the next rollover. The new key would be published well before activation. Resolver signals would be studied. Operators would receive a concrete key tag to check. Outreach would focus on the local conditions that break automatic updates rather than assuming that standards compliance guarantees a successful transition.

The lesson was not that delay always makes change safe. Waiting carries its own costs, including continued dependence on an older key and the possibility that attention fades. The lesson was that a calendar date should follow evidence rather than substitute for it. In a system with unknown installations, the decision to proceed has to combine telemetry, testing, support experience and judgement about the population that cannot be seen.

Arends' July 2026 guidance reflects that history. It translated an institutional rollover into an operator task: find the new tag, check the file, verify the update path. The message did not promise that every resolver was ready. It offered a way for each administrator to turn a global plan into local evidence.

A 95 per cent signal still leaves unknown resolvers

The second rollover programme began in 2024. KSK-2024 entered the root zone on 11 January 2025, giving validating resolvers a long period in which to observe the key before the planned October 2026 activation. By July 2026, ICANN's reporting indicated that more than 95 per cent of the resolvers visible through the relevant signal had recognised the new key.

The sequence illustrates staged change. Publication is not activation. Recognition is not the same as successful operation after the old key stops being used. A resolver can possess the new trust anchor and still fail because of software defects, local policy, clock problems or another part of the validation path. The long overlap reduces risk; it does not remove every failure mode.

Readiness is therefore a bundle of conditions rather than one bit. The key must be visible and accepted. The resolver must retain it across restarts. Software must use it when signatures change. Monitoring must distinguish validation failure from ordinary reachability problems. The organisation running the resolver must know who can change the configuration under incident pressure. A successful pre-publication signal confirms one part of that chain, not the entire operating response.

The remaining percentage deserves attention, but so does the population outside the measurement. Reporting mechanisms select for systems that support and emit them. Large public resolvers may appear alongside many installations behind network address translation. One signal can represent a very different number of users from another. A resolver that has been decommissioned may continue to distort historical observations, while an active resolver that does not report may be absent.

A responsible readiness statement therefore names the numerator, denominator and time. More than 95 per cent of reporting resolvers had recognised KSK-2024 by late July 2026 is useful. The Internet was 95 per cent ready is not supported. The first statement tells operators what the evidence covers; the second hides the uncertainty that matters most.

This discipline has consequences beyond one key. Global infrastructure often produces impressive percentages from partial observation. A routing collector sees routes from its peers, not every path. An outage detector combines available signals, not every user's experience. DNS telemetry can show a trend without identifying all the systems that will fail. The quality of the analysis depends on keeping the measurement boundary attached to the number.

At the article date, the decisive event remained in the future. The 11 October plan could be evaluated only after activation through incident reports, support cases, resolver measurements and the absence or presence of sustained resolution failure. Arends' guidance was an input into that outcome, not evidence that the outcome had already occurred.

A local root copy trades distance for responsibility

A recursive resolver normally sends some queries to the distributed root-server system and follows referrals down the DNS hierarchy. A hyperlocal design places a local copy of root-zone data close to the resolver. Arends co-authored an ICANN Office of the CTO analysis of this model published in August 2021.

The attraction is easy to see. A local service can continue answering root queries during some upstream connectivity failures. Queries do not have to leave the operator's network, which can reduce latency and exposure of root-query patterns. Large networks may gain more predictable performance and less dependence on an external path for the first step of resolution.

The design moves responsibility rather than erasing it. The local copy has to be obtained, authenticated, updated and served correctly. A stale or corrupted copy can give every resolver using it an outdated view of the root. Configuration mistakes can turn a resilience measure into a common local failure. The operator has to decide how the local service behaves when updates fail and how it will detect divergence from the published root.

Operational ownership becomes especially important during a root change. A local copy that refreshes correctly can distribute new data without relying on every outbound query path. A broken refresh process can preserve an old state inside the network after the global root has moved on. The design therefore needs independent checks of freshness, validation and failover rather than confidence derived from proximity alone.

There is also a measurement consequence. Queries answered locally no longer appear at public root-server instances. That can improve privacy for the network's users while removing signals that researchers and operators use to understand demand, misconfiguration and anomalies. A system can become locally more private and externally less observable at the same time.

The hyperlocal analysis is valuable because it does not offer a universal prescription. The right choice depends on network scale, operational maturity, threat model and tolerance for local responsibility. The same architecture that helps an experienced operator during an upstream outage may burden a smaller team with another critical service to patch, monitor and recover.

This work extends Arends' recurring theme. Reliability cannot be reduced to central availability. It also depends on what happens when functions are moved closer to the operator. A distributed system gains resilience through independent capability only when the new independence is maintained.

Changing the algorithm reaches deeper than replacing a key

The 2026 rollover replaces a key within an established cryptographic arrangement. A future change of the algorithm used at the root would reach further. Validators, signing systems, hardware security modules, libraries and operational tools would all need compatible support. A new algorithm can be cryptographically preferable and still be operationally dangerous if too much of the installed base cannot process it.

The Root Zone Algorithm Rollover Study published in May 2024 examined the problem as a design exercise. Arends participated in the collective work. The study considered criteria such as implementation support, hardware capability, message size, signing arrangements, double-signing periods, trust-anchor distribution and test environments. It did not announce or execute an algorithm rollover.

Hardware security modules make the transition more concrete. Root-signing operations depend on controlled hardware and procedures, so a candidate algorithm has to be supported in the relevant devices and operational environment, not only in a software library. Replacement hardware, certification, ceremony design and testing can set the timetable. Cryptographic agility is partly a mathematical question and partly a supply, tooling and operations problem.

The distinction between key and algorithm matters. Replacing a key asks whether systems recognise a new instance of a known type. Changing the algorithm asks whether they understand a different method, can allocate the required resources and behave correctly when old and new signatures coexist. The latter can affect packet sizes, fragmentation exposure, CPU demand and the logic used to select or reject cryptographic material.

A transition may require parallel signatures so older and newer validators can operate during an overlap. That improves compatibility but enlarges responses and increases signing and validation work. The root sits on a path used by every resolver, so small per-response changes can have broad operational effects. Test results therefore need to cover ordinary software as well as appliances, libraries and configurations that are difficult to inventory.

Post-quantum pressure makes algorithm agility more consequential, but the source material does not establish a chosen root algorithm or an executed post-quantum transition. The defensible conclusion is narrower: the root needs a method for evaluating future cryptographic change before urgency removes the option to proceed slowly.

Here again, evidence has to precede institutional confidence. A design team can recommend criteria, and implementers can report support. Only staged testing and observation can show how the combination behaves across real networks. The stronger algorithm is not simply the one with the strongest mathematical properties. It is the one the system can adopt without trading away the availability the DNS is meant to provide.

DELEG would add a new contract at the parent-child boundary

A DNS delegation tells a resolver where authority for a child zone begins. In the familiar model, the parent publishes name-server information and, for a signed child, a DS record that connects the child to the DNSSEC chain of trust. The information is intentionally limited. That simplicity has supported decades of interoperability, but it leaves little room to advertise new capabilities before a resolver contacts the child's authoritative servers.

The IETF's DELEG work explores a more extensible delegation mechanism. Arends was participating in the active work at the source cutoff and published an ICANN explanation in April 2026. One possible use is to provide information that helps a recursive resolver establish encrypted communication with an authoritative server. Encryption between an application and recursive resolver does not automatically protect the next leg of the query path; delegation data could help bootstrap that separate relationship.

That separation is often lost in public discussion of encrypted DNS. A user can send a protected query to a recursive service, yet the recursive service may still contact authoritative servers over an unencrypted path. DNSSEC can authenticate signed data on either path without concealing the names being requested. DELEG is relevant because it may allow the resolver to learn transport capabilities before establishing the authoritative connection, joining authenticity and confidentiality more deliberately without treating them as the same property.

The proposal reaches a foundational boundary. A parent zone would be able to carry more structured information about how the child should be contacted. That could avoid defining a new one-off record for every future capability. It could also make delegations larger, more complex and more consequential when parent and child data disagree.

Compatibility will determine whether the idea is useful. Existing resolvers must continue to reach existing zones. New resolvers need clear fallback behaviour when an extension is absent, malformed or unsupported. Designers have to consider downgrade paths: an attacker or failing intermediary should not be able to strip a security capability and make the resolver silently accept a weaker connection without the intended policy.

The operational relationship between registry, registrar, DNS operator and domain holder becomes more important as well. Additional delegation parameters have to be created, validated, transferred and removed through real provisioning systems. A clean wire format does not ensure that registrars expose the fields correctly or that registries publish changes without delay. Responsibility for a wrong value has to be intelligible when the resolver cannot reach the child.

At the source cutoff, DELEG remained an Internet-Draft. Its syntax, security properties and scope could change through working-group review. No final RFC or universal deployment existed. Treating the proposal as current DNS practice would collapse the difference between an engineering direction and an implemented standard.

The value of Arends' participation lies partly in connecting the new proposal to older lessons. DNSSEC showed that a parent-child security relationship can support global validation, and that mistakes at the boundary can make names disappear. DELEG seeks more expressive power at the same boundary. Its success will depend on whether the additional capability arrives with diagnostics, transition rules and operational ownership strong enough to contain the new ways it can fail.

Dry runs could make DNSSEC change less binary

Many DNSSEC changes are difficult to test against the full resolver population before enforcement. A zone can validate under its own laboratory conditions and still encounter software or policies elsewhere that react differently. Once a new configuration becomes authoritative, a previously hidden incompatibility can turn into immediate failure for users behind affected resolvers.

The active dry-run DNSSEC draft considers a way to expose how validators would respond to a planned change without making the simulated failure control production resolution. The precise semantics remained work in progress at the source cutoff. The operating idea is to collect evidence from would-be validation outcomes before the hard cutover.

A useful dry run could reveal that an algorithm is unsupported, a chain is assembled incorrectly or a policy produces unexpected rejection. Operators could compare observations across resolver software and networks while the existing production chain continues to answer. The method would turn part of a binary transition into a rehearsal.

For a large zone or root-related service, that changes the economics of caution. Operators can compare expected and observed behaviour before users become the test population. Software teams can discover differences among implementations while rollback is still straightforward. The evidence can inform whether to proceed, delay or narrow the change. A rehearsal is useful because it creates a decision point before an irreversible production commitment, not because it predicts every live condition.

Rehearsal has limits. It is meaningful only where implementations support the signal and operators observe the result. Early deployments may be concentrated among the systems already best prepared for change, leaving older or obscure resolvers outside the sample. Simulated behaviour may also differ from the code path used during full enforcement. Privacy questions arise if reports reveal resolver characteristics or query activity.

The draft therefore cannot guarantee safe deployment. It offers another layer of evidence, similar in spirit to trust-anchor reporting and error feedback. Its value depends on how clearly the denominator is described and whether operators can act on what they learn.

For Arends, the work completes a long arc without closing it. The 2005 RFCs defined the validation decision. Later documents improved negative proofs and failure signals. Dry-run DNSSEC asks whether the decision can be observed before it is allowed to break service. That is a practical shift from specifying correct behaviour to designing change control for a network no one can fully test.

His influence ends where independent operators begin

The public record supports a clear description of Arends' contribution. He is a principal co-author of the modern DNSSEC core, a co-author of later standards for authenticated denial and error observability, and an ICANN research scientist working on root, algorithm and delegation questions. It does not support a lone-inventor story, a claim of operational command or a private-life narrative built from guesswork.

His career also shows how authority accumulates in open infrastructure without becoming ownership. A standards author can define a durable vocabulary. A researcher inside ICANN can frame measurements, identify readiness signals and explain operational risk. An experienced contributor can connect a new draft to failure modes seen in earlier protocols. None of those roles can make a resolver vendor release code, a registry change its provisioning system or an operator repair a trust-anchor file.

That limit is productive. It forces proposals to survive review by people who will carry different costs. Resolver developers care about compatibility and support burden. Registries and registrars care about provisioning and scale. Authoritative operators care about key management and availability. Privacy advocates care about what reporting reveals. Root-zone partners care about ceremonies, continuity and evidence. A specification that cannot answer those groups may still be elegant on paper and unfit for deployment.

The division of labour also changes what counts as career evidence. A product executive may be judged through revenue or market share; a standards contributor leaves a trail of documents, revisions, implementation choices and operational practices. The influence can be widespread while remaining difficult to attribute numerically to one author. The safe claim is tied to the record: Arends repeatedly helped define mechanisms used to authenticate DNS data and to make the consequences of change more observable.

The distributed model also keeps individual legacy in perspective. DNSSEC, NSEC3, Extended DNS Errors and DNS Error Reporting can continue without their original authors because the documents are public and implementations are maintained by many organisations. Arends' influence is visible in the architecture and questions those documents preserve, not in permanent personal control over them.

The most consequential test of his current work was still ahead on 10 August 2026. If KSK-2024 became the sole root key on 11 October with limited disruption, the result would reflect years of ceremonies, software support, reporting, outreach and local administration across many institutions. If failures emerged, the useful questions would be concrete: which resolvers missed key tag 38696, why the update path failed, whether telemetry had hidden the affected population, and how quickly operators could recover.

DELEG and dry-run DNSSEC face a longer version of the same test. Their progress should be judged through stable text, independent implementations, fallback behaviour, privacy review and evidence that registries, authoritative services and resolvers can operate the new hand-offs. Publication alone will not settle the matter.

Arends' body of work is significant because it does not offer a fantasy of central control. It treats DNS as a system that has to be changed through shared rules, visible evidence and recoverable steps. Key tag 38696 is a small number carrying that larger burden. The measure of success is not whether every operator notices it. It is whether the operators who need to act can discover the problem before users discover it for them.

Why Arends' work matters beyond one rollover

The deepest continuity in Arends' record is not one cryptographic primitive or one standards organisation. It is the problem of making a distributed system change without losing the ability to distinguish security from availability, evidence from census and publication from deployment.

The 2005 DNSSEC documents established a common validation model. NSEC3 refined one of its privacy and deployment trade-offs. Extended DNS Errors made failures more legible. DNS Error Reporting created a path for remote evidence to reach the operator able to act. Hyperlocal-root work examined what happens when resilience is moved closer to local operators. Algorithm-rollover research asks how deeper cryptographic change can be staged. DELEG and dry-run DNSSEC extend the same discipline to future hand-offs.

None of these mechanisms removes independent administration. That is the point. The DNS is resilient partly because no single institution owns every resolver, zone, root instance, registrar system or implementation. The cost is that every major change becomes a coordination problem whose unknown population cannot be fully measured in advance.

Arends' contribution is therefore best understood as infrastructure stewardship through specifications and evidence. The useful question is not whether one engineer can make the DNS safe. It is whether the rules, signals and procedures around a change give independent operators enough information to act before local failures accumulate into a global incident.