In brief

  • Roy Arends was one of five co-authors of the core 2005 DNSSEC specifications; his lasting contribution is collaborative protocol design, not sole invention or control of the root.
  • NSEC3, Extended DNS Errors and DNS Error Reporting show a career focused on diagnosing cryptographic failures without treating optional signals as exhaustive proof.
  • The 2026 KSK rollover, DELEG and dry-run DNSSEC place his current work at the boundary between necessary maintenance and the risk of disrupting independent resolvers.

Key tag 38696 turned a global change into a local task

In late July 2026, Roy Arends published a number that most network administrators would not normally need to know: 38696. It is the key tag for KSK-2024, the new key-signing key prepared for the Domain Name System root. ICANN planned to sign the root zone only with this key from 11 October 2026. The change should have been invisible to most people. For a validating resolver that had not acquired the new trust anchor, however, the effect could be abrupt: signed names could stop resolving even though the websites, mail servers and networks behind them remained operational.

The practical instruction was simple. Resolver operators should check that tag 38696 appeared in their trust-anchor configuration and confirm that the automatic update mechanism could write to the required files. That simplicity concealed the structure of the problem. There is no global registry of all recursive resolvers, no administrator able to compel them to update and no single telemetry stream showing every broken configuration. A key prepared through centralised ceremonies becomes dependable only after thousands of independent systems accept it.

Arends reported that more than 95% of resolvers sending the relevant signal recognised KSK-2024. The denominator matters as much as the percentage. These were resolvers producing an analysable readiness signal, not a census of every validating installation on the Internet. Systems that had stopped reporting, were configured differently, had remained offline for a long time or could not update a read-only trust-anchor file might be absent. The figure supported confidence, but did not turn a distributed system into one controlled from the centre.

This distinction runs through Arends’s public career. He has worked on rules for authenticating DNS data, mechanisms that make negative answers and failures easier to understand, and research intended to reduce the risk of changing a system with no shared maintenance window. At the research date, IETF Datatracker listed his name on seven published RFCs, including three documents underlying modern DNSSEC, as well as NSEC3, Extended DNS Errors and DNS Error Reporting. He was also involved in active work on expanded delegation and dry-run DNSSEC.

The record is substantial, but easily distorted by the mythology surrounding Internet infrastructure. Arends did not invent DNSSEC alone. He does not personally run the root zone, command the root-server system or decide what every resolver must trust. His influence rests on shared specifications, institutional research, measurement, expert review and explanations of operational consequences. The central question is therefore less flattering but more useful: how does a standards engineer help change critical infrastructure when those responsible for implementing the change remain independent?

Authority around the root zone is deliberately divided

The DNS root is often described as if it were one machine or one organisation. In practice, it is a chain of divided responsibilities. ICANN coordinates unique identifiers and the associated policy and technical work. Public Technical Identifiers performs the IANA functions. Verisign fulfils the Root Zone Maintainer role under defined agreements. Twelve organisations operate thirteen named root-server identifiers through distributed infrastructure. Recursive-resolver operators choose their own software, decide whether to validate DNSSEC and maintain local trust anchors.

Arends works within one link in this chain. His ICANN biography says that he joined the organisation in July 2015 and serves as Principal Research Scientist, with responsibility for designing studies, collecting and analysing data, and carrying out projects. The page also gives the title Distinguished Technologist. These descriptions establish a technical and institutional role, but do not give him executive authority over the organisations and operators surrounding the root.

This distinction matters for more than job-title accuracy. Distributed authority is one reason DNS can survive one entity’s error or disagreement. It also explains why changes take time. A root-zone plan may be meticulously prepared yet still encounter old resolver software, disabled update logic, inaccurate clocks, restricted file permissions or local policies invisible to the central team. Coordination must rely on published rules, long lead times, verifiable identifiers and evidence that enough of the installed base is ready.

Standards work is similarly divided. RFCs name authors, but documents emerge from working-group discussion, implementation experience, objections, revisions and broader IETF review. At the research date, Datatracker showed no active formal IETF role for Arends. That does not diminish his authorship; it clarifies the source of his influence. He could propose, explain and persuade, while consensus and deployment belonged to the wider community.

A profile calling him the person who controls DNS security would miss the point. The work matters precisely because control is dispersed. The engineering task is to make independent decisions converge on interoperable behaviour without pretending that they have become one decision.

Separation also limits the damage from one mistake, but makes responsibility harder to explain during an incident. A bad child-zone signature belongs to one operator; an obsolete trust anchor to another; and a root-publication problem would involve a different institutional chain. In all three cases, the user sees the same symptom: a name does not resolve. A good protocol must preserve those boundaries while giving outsiders enough data to locate the failure.

Five authors set the modern operating rules for DNSSEC

The ordinary Domain Name System maps names to records used by applications and networks. Its original design gave resolvers no cryptographic way to prove that an answer had not been substituted. An attacker able to feed false data to a resolver could try to redirect or hide a name, or poison its cache. DNS Security Extensions addresses this weakness: zones sign record sets, and resolvers verify 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 record formats, including DNSKEY, RRSIG, NSEC and DS. RFC 4035 describes changes to authoritative-server and validating-resolver behaviour. Roy Arends co-authored all three with Робом Остейном, Мэттом Ларсоном, Дэном Мэсси and Скоттом Роузом. The five names matter: the protocol was collaborative work built on earlier DNSSEC efforts, not one person’s sudden invention.

Signing a zone creates digital signatures for resource-record sets, or RRsets. Public keys used to verify them are published in DNSKEY records, while RRSIG records contain the signatures. A parent zone may publish a DS record referring to a child-zone key. Starting from a trusted key, a validator follows this relationship from parent to child and determines whether an answer is secure, insecure or erroneous under the protocol.

A query along this chain crosses several independently managed zones. A validator may begin with a configured root trust anchor, verify signed root data, use a parent’s DS record to authenticate the child’s key and continue to the requested name. No zone signs data for every other zone. Each administrator manages local keys and records, while the shared protocol lets the resolver verify transitions between them. One broken delegation can sever the chain even when the zones above and below otherwise work correctly.

The key word isauthenticate. DNSSEC can confirm that signed DNS data is authorised by the chain of trust and has not been silently altered. It does not encrypt the query or answer. It does not prove that a service named in a record is honest, current or available. A correctly signed record can lead to a malicious resource, and a secure answer can lead to an application connection that fails for reasons outside DNS.

This narrowness is an advantage when properly understood. The protocol solves a specific integrity problem without turning DNS into a central directory of approved services. Independently managed zones can participate in a common verification chain. The same narrowness demands operational discipline: every link must be correctly created, published, updated and timed, while the validator needs a usable trust anchor and supported algorithms.

The 2005 documents also had to coexist with unsigned DNS. Deployment could not depend on every zone adopting DNSSEC simultaneously. A validating resolver therefore distinguishes an unsigned delegation from a signed chain that fails validation. The difference is fundamental. An insecure answer may be accepted because the chain explicitly ends; a bogus answer is rejected because cryptographic proof was expected but failed. Gradual deployment therefore did not make the absence of DNSSEC an automatic failure, while broken signed chains still failed closed.

This semantics turned DNSSEC from a cryptographic idea into an interoperable operational system. It also established the failure mode behind much of Arends’s later work. A security mechanism designed to block false answers must sometimes decline to return any answer. After that safe refusal, an operator must identify whether the problem lies in a signature, delegation, algorithm, clock, trust anchor or path to an authoritative server.

The documents became infrastructure because different teams could implement the same wire records and validation states. Implementations did not become identical. Supported algorithms, cache behaviour, logging, time handling and user-visible errors still affect operations. Shared rules narrow disagreement to testable behaviours; they do not remove the engineering required to make a particular resolver or authoritative service reliable.

Cryptographic trust can appear as lost availability

For users, a DNSSEC failure rarely arrives labelled as a cryptographic problem. A website may appear unavailable, mail may not be delivered, or an application may report that it cannot find a host. The authoritative servers may be online and the address reachable. The resolver has refused the DNS answer because its proof did not match the expected chain of trust.

Several ordinary mistakes can cause this result. A parent may publish a DS record that no longer matches the child’s active key. A signature may expire. A zone may use an algorithm unsupported by the validator. A server or validator with an incorrect clock may treat a valid signature as outside its permitted period. A trust-anchor file may be obsolete. Each cause is local, but the consequences can be broad because applications depend on name resolution before connecting.

The security property that blocks forged data therefore raises the cost of operational error. Unsigned DNS will often return an answer despite weak security practice. A broken DNSSEC chain must stop. That protects users from unauthenticated data, but a key-management or delegation mistake can make an otherwise healthy service unavailable.

The 2005 architecture required validation state to affect resolver behaviour, but early end-user diagnosis remained limited. Applications usually saw a generic DNS failure rather than an explanation of which proof failed. A signed-zone engineer could see healthy authoritative servers while remote validating users received nothing. The diagnostic data sat with the resolver, often in another organisation and sometimes on another continent.

Here protocol correctness separates from operational usability. A standard can define exactly how a validator decides while leaving entities with an opaque incident. A resolver may keep detailed local logs, but that information does not automatically reach the authoritative-zone operator, support team or application. As DNSSEC moved into ordinary infrastructure, failures needed a language able to cross organisational boundaries.

Arends’s later RFCs can be read as attempts to make that language more precise. The question is no longer only whether an answer validates, but whether the system can explain a refusal clearly enough for the right operator to fix it without weakening the protection that caused the refusal.

NSEC3 proved a name absent without publishing the zone in order

Positive DNSSEC answers contain signed records. A negative answer has a different task. When a resolver asks for a nonexistent name, an attacker might suppress the real answer and claim that the name does not exist. A validating resolver needs cryptographic proof of absence, not merely signed claims about records that do exist.

The original 2005 record set included NSEC. NSEC records link existing names in canonical order, forming a signed chain that proves a name is absent between two points. The mechanism is elegant, but lets a querying party walk the chain and discover the sequence of names in a zone. DNS data is available when queried, yet many operators did not want the complete set to be easily enumerated in order.

NSEC3, standardised in RFC 5155 in March 2008, changes the representation. Owner names are hashed and the signed chain covers the resulting hashes. A resolver can reproduce the required hash and verify that the requested name falls within a proven interval. The negative-answer chain no longer publishes names directly in lexicographic order. Arends wrote the specification with Беном Лори, Джеффом Сиссоном and Дэвидом Блэка.

Hashing does not make a zone confidential. An attacker can still guess likely names, hash them and compare the results with published values. The cost depends on the names, parameters and attacker’s resources. A zone with predictable labels may remain relatively easy to analyse. NSEC3 reduces direct enumeration but does not promise secrecy.

The specification also includes opt-out. Large delegation-centred zones may omit some unsigned delegations from the NSEC3 chain, reducing signing work and answer size. This alters proof and security properties around those delegations. It helps DNSSEC coexist with many unsigned child zones, but adds complexity for validators and operators.

NSEC3 parameters also affect performance. Extra hashing consumes processor time on authoritative servers, signing systems, validators and attackers, while negative answers may grow. Operators must choose values for their threat model and service capacity rather than assuming that more iterations are automatically safer. The mechanism balances authenticated denial of existence, information exposure, scale and operational cost.

Arends also co-authored RFC 4956, a 2007 experimental document on DNSSEC Opt-In. It was an earlier attempt to make signed parent zones manageable when they contained many unsigned delegations. NSEC3 opt-out became the more durable Standards Track answer. The sequence is revealing: deployment pressure did not arise after the architecture was complete; it shaped the mechanisms used to take DNSSEC into large mixed environments.

This contribution typifies Arends’s work. It addresses a problem created by deploying the original security mechanism. Once DNSSEC could prove that a name was absent, the proof itself exposed information. NSEC3 did not remove the tension; it changed the balance and described the costs. Infrastructure standards often work this way: a useful protocol rarely eliminates every trade-off, but makes them explicit enough for independent implementations to reach compatible results.

SERVFAIL gave operators too little information

A resolver that cannot provide an answer may return SERVFAIL. The code usefully tells an application that the name is not merely absent, but it is too broad. A DNSSEC validation failure, unreachable authoritative server, unsupported algorithm, network timeout, stale data or local policy can all produce the same visible result.

RFC 8914, published in October 2020, introduced Extended DNS Errors. Arends wrote it with Уорреном Кумари, Эваном Хантом, Марком Эндрюсом and Уэсли Хардакером. The mechanism adds an option to Extension Mechanisms for DNS, or EDNS, carrying a numeric information code and, where appropriate, explanatory text. The ordinary response code remains, while the extended code describes the underlying condition more precisely.

The practical benefit is clear. A resolver can distinguish an expired DNSSEC signature from a case in which no available authoritative server answered. It can indicate filtered or stale data, or a policy rule affecting resolution. Operators and applications no longer have to infer every cause from one generic failure.

The extension supplies evidence, not omniscience. A resolver creates the code from what it observed and understood. The original cause may lie farther along the chain. An intermediary may remove the option, while an implementation may support only some codes or attach incomplete text. An expired-signature message can be a strong diagnostic clue without proving that no other fault exists.

Optional text creates another boundary. Human-readable detail can speed support but may expose internal policy, filtering decisions, topology or implementation details. An operator must decide what will be visible and to whom. Numeric codes provide structure; free text adds local judgement and potentially sensitive context.

Extended DNS Errors shows how a standard can improve operations without changing the fundamental validation decision. A bogus answer remains bogus. The resolver is not told to weaken security so the user can reach the destination; it is given a way to explain the refusal. This preserves the security property while making repair easier.

The document also illustrates the limits of Arends’s authority. An RFC can define a common vocabulary but cannot force every resolver, application, intermediary or support system to preserve and display it. The vocabulary becomes more useful as adoption, accurate transmission and operator practice grow. Publication begins that work; it does not prove completion.

The path to a person is also uneven. A resolver may produce an exact code that an operating system, browser or application replaces with a generic connection message. Support staff may see the user’s symptom but lack access to resolver logs. The standard improves data at one layer; products and procedures decide whether it reaches someone able to act. Adoption therefore cannot be measured only by the number of implementations that parse the option.

Error reports expose remote failures and create new risks

Extended errors improve the answer available near a resolver. They do not automatically notify the authoritative-zone operator whose data failed validation. That operator may have no direct relationship with the affected resolver and may not know that users on other networks are receiving errors. DNS Error Reporting, published as RFC 9567 in April 2024, addresses this gap. Arends co-authored it with Шумоном Хуком.

The mechanism lets a domain specify a designated reporting agent. A participating resolver encountering defined errors may send a structured report there, subject to implementation rules, rate limits and local policy. The aim is to deliver data to those responsible for the zone that would otherwise remain in remote resolver logs.

Such feedback can shorten an incident. A child zone with a mismatched DS record may look healthy to its own monitoring if tests do not validate it from enough external locations. Resolver reports can show that failure is distributed across networks, software versions or places. They may also reveal intermittent incompatibility missed by one test system.

The same information can be sensitive. A report may show that a resolver tried to reach a name, the error type, the event time and aspects of local behaviour. A poorly designed receiver may attract excessive traffic. An attacker may try to create errors or use the mechanism for amplification, reconnaissance or operational noise. RFC 9567 therefore makes reporting voluntary and includes privacy and rate requirements rather than defining a universal event stream from every resolver.

The resulting data always has a denominator problem. Some resolvers report and others do not; some domains publish reporting instructions and others do not. Operators may selectively send or suppress events. A spike proves that a problem exists, but a quiet dashboard does not prove every resolver is healthy. The mechanism broadens visibility without creating a global census.

This boundary is central to Arends’s work. More precise error signals are valuable because responsibility for DNS is distributed; for the same reason, they remain incomplete. Each organisation decides whether to send, receive, retain and use the information. The protocol defines transmission, while governance, privacy practice and operational trust determine whether it becomes useful.

By the publication of DNS Error Reporting, the shape of Arends’s contribution was especially clear. The 2005 documents defined validation. NSEC3 refined proof of absence. Extended errors explained a failed decision. Reporting tried to carry the evidence to someone able to repair the underlying zone. The progression runs from cryptographic correctness to an operational feedback loop.

ICANN brought Arends closer to operational data

Arends joined ICANN in July 2015. The move placed a longstanding standards contributor inside the organisation that coordinates the Internet’s unique identifiers and supports research around the DNS root. His published duties include designing and conducting studies and collecting and analysing data. There is no public description of every internal project, budget or reporting line.

The institutional setting changed the scale of questions available to him. An IETF document can define how a resolver or authoritative server should behave. ICANN-related research can examine root operations, trust-anchor distribution and resolver behaviour across a diverse installed base. The activities complement each other: standards need operational data, while measurements need protocol concepts that explain what is observed.

Arends’s public ICANN work includes analysis of hyperlocal root service, participation in a study of a root-zone algorithm rollover and communication with operators about the 2026 KSK rollover. He has also used ICANN’s technical platform to explain active IETF delegation work. This neither makes ICANN the owner of the IETF process nor Arends the operator of every system studied. It shows an institutional bridge between research, standards and operations.

The people and organisations around that bridge have different duties. IETF contributors debate protocol text. ICANN research teams study identifier-system behaviour and report results. PTI and Verisign perform defined root-zone functions. Root-server operators distribute the published zone through their own systems. Resolver developers turn standards into code, and network administrators decide when and how to deploy it. Arends may join several conversations, but authority to act remains with the party operating the relevant layer.

Such a bridge can be influential because ICANN has access to planning, communities and data associated with the root. It also requires restraint. Measurements near the root may appear more complete than they are. A percentage based on reporting resolvers must retain the name of that sample. Research into a possible algorithm change cannot be presented as a decision to make the change. A draft discussed in an ICANN blog remains an IETF working document whose text and status may change.

Arends’s authority in this setting is mainly technical and reputational. Public information does not establish a unilateral budget, command over root-server operators or a veto over standards. His work may influence what operators measure and how institutions describe a transition. Changes to keys, software or local policy remain distributed.

The 2018 postponement changed the approach to the next rollover

The first root-zone key-signing-key rollover concluded in October 2018. It supplied an operational lesson that protocol alone could not provide. A trust anchor may be correctly created and published, yet uncertainty about resolver readiness can still justify delay, additional measurement and wider outreach.

RFC 5011 describes an automatic way for a validating resolver to learn a new DNSSEC trust anchor. The new key is published while the old one remains trusted. The resolver observes it for a defined period before accepting it, reducing the risk of immediately trusting a briefly or maliciously introduced key. This assumes that the resolver runs during the observation window, receives the necessary data and can save the update.

The observation period is a security control. It prevents immediate trust in a newly seen key and gives an operator time to notice an unexpected change. It is also an availability dependency. A resolver missing enough of the joint-publication period cannot simply conclude that the new key is legitimate. The caution protecting the trust anchor may leave an abandoned installation unable to validate after the old key is withdrawn.

These assumptions look routine until one fails. A resolver may remain offline too long. Automatic updating may be disabled. The process may run under an account unable to write the trust-anchor file. A device may have unusual maintenance arrangements, while a manually configured installation will not accept the key without administrator action. None of these conditions can be repaired merely by publishing correct root data more loudly.

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

The lesson was not that delay always makes a change safe. Waiting also costs time and money: dependence on the old key continues and entity attention may fade. The point was that the calendar should follow evidence rather than replace it. In a system with unknown installations, a decision to proceed must combine telemetry, testing, support experience and an assessment of the population that cannot be seen.

Arends’s July 2026 guidance reflected this history. He translated an institutional rollover into an operator task: find the new tag, inspect the file and confirm that the update path works. The message did not promise that every resolver was ready. It invited each administrator to turn the global plan into local proof.

A 95% 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 observation period before planned activation in October 2026. By July 2026, ICANN data showed that more than 95% of resolvers visible through the relevant signal recognised the new key.

The sequence demonstrates staged change. Publication is not activation, and recognition does not equal successful operation after the old key stops being used. A resolver may hold the new trust anchor yet still fail because of a software fault, local policy, timing problems or another part of the validation path. A long overlap reduces risk without eliminating every failure mode.

Readiness is a set of conditions, not one bit. The key must be visible and accepted. The resolver must retain it after restarting. The software must use it after signatures change. Monitoring must distinguish a validation error from ordinary unavailability. The organisation running the resolver must know who may change its configuration under incident pressure. A pre-activation signal confirms one link, not the complete operational response.

The remaining percentage deserves attention, as does the population outside the measurement. The reporting mechanism selects systems that support and transmit the signal. Large public resolvers may sit beside many installations behind network address translation. One signal can represent a very different number of users from another. A retired resolver may continue to distort historical observation, while an active but non-reporting one remains absent.

A responsible readiness statement therefore names the numerator, denominator and time. Saying that “by late July 2026, more than 95% of reporting resolvers recognised KSK-2024” is useful. Saying that “the Internet was 95% ready” is not supported by the data. The first statement preserves the evidence boundary; the second hides the uncertainty that matters most.

This discipline extends beyond one key. Global infrastructure often produces impressive percentages from partial observation. A route collector sees routes from its peers, not every path. An outage detector combines available signals, not every user’s experience. DNS telemetry shows a trend without identifying every system that will fail. Analytical quality depends on keeping the measurement boundary attached to the number.

At the research date, the decisive event was still in the future. The plan for 11 October could be assessed only after activation, through incident reports, support requests, resolver measurements and the presence or absence of sustained resolution failures. Arends’s guidance contributed to that outcome; it did not prove that the outcome had already been achieved.

A local root copy trades distance for responsibility

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

The appeal is clear. A local service may continue answering root queries during some external-connectivity failures. Queries need not leave the operator’s network, potentially reducing latency and disclosure of root-query patterns. Large networks gain the prospect of more predictable operation and less dependence on an external path at the first step of name resolution.

The architecture moves responsibility rather than removing it. The local copy must be obtained, authenticated, updated and served correctly. A stale or damaged copy can give every resolver using it a false view of the root. A configuration error can turn a resilience measure into a common local failure. The operator must decide how the service behaves when updates fail and how divergence from the published root will be detected.

Operational responsibility is especially visible during a root change. A correctly updating local copy distributes new data without relying on every outgoing query path. A broken update process can preserve old state inside a network after the global root has changed. Independent checks of freshness, validation and failover are therefore needed; physical proximity alone is not evidence of correctness.

There is also a measurement consequence. Queries handled locally are no longer visible at public root-server instances. This improves privacy for network users but removes signals used by researchers and operators to estimate demand, configuration errors and anomalies. The system can become more private locally and less observable externally at the same time.

The hyperlocal root report is valuable because it offers no universal prescription. The choice depends on network scale, operational maturity, threat model and willingness to accept local responsibility. An architecture that helps an experienced operator survive an external outage may burden a small team with another critical service requiring updates, monitoring and recovery.

This work continues a recurring theme in Arends’s career. Reliability cannot be reduced to the availability of a central service. It also depends on what happens when functions move closer to the operator. A distributed system gains resilience from independent capability only when that independence is maintained.

An algorithm rollover touches more layers than a key replacement

The 2026 rollover replaces a key within an existing cryptographic scheme. A future root algorithm change would affect more layers. Validators, signing systems, hardware security modules, libraries and operational tools would all need compatible support for the new method. An algorithm may be cryptographically preferable yet operationally dangerous if much of the installed base cannot process it.

The Root Zone Algorithm Rollover Study, published in May 2024, treated the issue as transition design. Arends participated in the collective work. It examined implementation support, hardware capability, message sizes, signing arrangements, dual-signature periods, trust-anchor distribution and test environments. It neither announced nor performed an algorithm change.

Hardware security modules make the transition especially concrete. Root-signing operations rely on controlled equipment and procedures, so a candidate algorithm must work in the relevant devices and operational environment, not just in a software library. Timelines may depend on hardware replacement, certification, ceremony design and testing. Cryptographic agility is partly mathematical and partly a supply, tooling and operations problem.

The distinction between key and algorithm is fundamental. A key replacement tests whether systems recognise a new instance of a known type. An algorithm change tests whether they understand another method, can allocate the required resources and behave correctly while old and new signatures coexist. It may alter packet size, fragmentation risk, processor load and the logic for selecting or rejecting cryptographic data.

A transition may require parallel signatures so old and new validators work during an overlap. That improves compatibility but enlarges answers and increases signing and verification work. The root lies on every resolver’s path, so a small change to one response can have broad operational effects. Testing must cover not only mainstream software but also devices, libraries and configurations that are difficult to inventory.

Pressure from post-quantum cryptography increases the importance of algorithmic agility, but the research package does not establish a selected root algorithm or completed post-quantum transition. The defensible conclusion is narrower: the root needs a way to assess future cryptographic changes before urgency removes the option of moving slowly.

Here too, empirical evidence must precede institutional confidence. A project team can propose criteria and developers can claim support. Only staged testing and observation can show how the combination behaves in real networks. The stronger algorithm is ultimately one the system can adopt without sacrificing the availability for which DNS exists.

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

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 linking it to the DNSSEC chain of trust. The information set is deliberately limited. This simplicity has supported compatibility for decades, but leaves little space to advertise new capabilities before a resolver contacts the child’s authoritative servers.

IETF work on DELEG explores a more extensible delegation mechanism. At the research date, Arends was involved in the active draft and published an ICANN explanation in April 2026. One possible use is to convey information helping a recursive resolver establish an encrypted connection to an authoritative server. Encryption between an application and recursive resolver does not automatically protect the next part of the query path; delegation data could help initialise that link separately.

This distinction is often lost in public discussion of encrypted DNS. A user may send a protected query to a recursive service while that service still contacts an authoritative server over an unencrypted path. DNSSEC can authenticate signed data on either segment without hiding queried names. DELEG matters because it could let a resolver learn transport capabilities before opening the authoritative connection, connecting authenticity and confidentiality more deliberately without confusing them.

The proposal touches a fundamental boundary. A parent zone could carry richer structured information about how to communicate with a child, avoiding a separate record for every future capability. Delegations could, however, become larger, more complex and more dangerous when parent and child data diverge.

Compatibility will determine the idea’s usefulness. Existing resolvers must continue reaching existing zones. New resolvers need clear fallback behaviour when the extension is absent, damaged or unsupported. Designers must also address downgrade cases: an attacker or faulty intermediary should not be able to remove a security feature and make a resolver silently accept a weaker connection contrary to policy.

The operational relationship among registry, registrar, DNS operator and domain owner would also become more important. Additional delegation parameters must be created, checked, transferred and removed through real provisioning systems. A clean wire format does not ensure that registrars expose fields correctly or registries publish changes promptly. When a value is wrong, responsibility for fixing it must be clear if resolvers cannot reach the child zone.

At the research date, DELEG remained an Internet-Draft. Its syntax, security properties and scope could change during working-group review. There was no final RFC or universal deployment. Presenting the proposal as current DNS practice would erase the difference between an engineering direction and an implemented standard.

Arends’s involvement is valuable partly because it connects the new proposal with older lessons. DNSSEC showed that a security relationship between parent and child can support global validation, and that errors at this boundary can make names unavailable. DELEG seeks greater expressiveness at the same junction. Its success depends on whether the added capabilities come with diagnostics, transition rules and clear operational responsibility sufficient to contain new failure modes.

A trial mode could make DNSSEC changes less binary

Many DNSSEC changes are difficult to test across the full resolver population before enforcement. A zone may validate successfully in its own laboratory yet meet software or policies that react differently elsewhere. Once a new configuration becomes authoritative, hidden incompatibility can immediately become a user-visible failure.

The active dry-run DNSSEC draft considers a way to show how validators would react to a planned change without allowing the simulated failure to control production name resolution. Its exact rules remained under development at the research date. The operational idea is to collect evidence about potential validation results before a hard switch.

A useful trial could expose an unsupported algorithm, an incorrectly assembled chain or a policy that unexpectedly rejects the data. Operators could compare observations across resolver software and networks while the current production chain continued answering. Part of a binary transition would become a rehearsal.

For a large zone or root-related service, this changes the economics of caution. Operators can compare expected and observed behaviour before users become the test group. Development teams can find implementation differences while rollback remains easy. Evidence can support a decision to proceed, delay or narrow the transition. A rehearsal is useful because it creates a decision point before a hard-to-reverse production commitment, not because it predicts every live condition.

The rehearsal has limits. It matters only where implementations support the signal and operators observe the result. Early deployment may concentrate among systems already best prepared for change, leaving old or unusual resolvers outside the sample. Simulated behaviour may differ from the code path used under full enforcement. Privacy questions also arise if reports expose resolver characteristics or query activity.

The draft therefore does not guarantee safe deployment. It adds another evidence layer, conceptually close to trust-anchor reporting and error feedback. Its value depends on a clear denominator and on operators’ ability to act on what they observe.

For Arends, this work completes a long arc without closing it. The 2005 RFCs defined the validation decision. Later documents improved negative proof and failure signals. Dry-run DNSSEC asks whether that decision can be observed before it is allowed to disrupt service. It marks a practical shift from describing correct behaviour to designing change management for a network no one can test completely.

His influence ends where independent operators’ decisions begin

Public documents support a precise account of Arends’s contribution. He is one of the principal co-authors of the modern DNSSEC foundation, a co-author of later standards for authenticated denial and error observability, and an ICANN researcher working on root, algorithm and delegation questions. They do not support a lone-inventor story, a claim that he commands operations or a private-life biography built on speculation.

His career also shows how influence accumulates in open infrastructure without becoming ownership. A standards author can define durable vocabulary. An ICANN researcher can frame measurements, identify readiness signals and explain operational risk. An experienced contributor can connect a new draft with older protocol failure modes. None of these roles can force a resolver vendor to ship code, a registry to change provisioning or an operator to repair a trust-anchor file.

That constraint is productive. It forces proposals to withstand scrutiny from groups bearing different costs. Resolver developers care about compatibility and support load. Registries and registrars consider provisioning and scale. Authoritative operators focus on key management and availability. Privacy advocates examine report content. Root-zone partners consider ceremonies, continuity and evidence. A specification that does not answer these groups may be elegant on paper and undeployable in practice.

The division of labour also changes how a career is assessed. A product executive may be judged by revenue or market share; a standards contributor leaves a trail of documents, revisions, implementation choices and operational practices. Influence can be broad but difficult to attribute to one author. The defensible claim stays tied to documents: Arends repeatedly helped define mechanisms for authenticating DNS data and making the consequences of change more observable.

The distributed model also keeps personal legacy in proportion. DNSSEC, NSEC3, Extended DNS Errors and error reporting can continue without their original authors because the documents are open and many organisations maintain implementations. Arends’s influence is visible in the architecture and questions preserved by those documents, not in continuing personal control over them.

As of 10 August 2026, the most important test of his current work had not yet occurred. If KSK-2024 became the sole root key on 11 October with limited disruption, the result would reflect years of ceremonies, software support, reporting, explanation and local administration across many organisations. If failures arose, the useful questions would be specific: which resolvers missed tag 38696, why the update path failed, whether telemetry hid an affected group and how quickly operators recovered.

DELEG and dry-run DNSSEC face a longer version of the same test. Their progress should be judged by text stability, independent implementations, fallback behaviour, privacy analysis and evidence that registries, authoritative services and resolvers can maintain the new transitions. Publication alone is not enough.

Arends’s work matters because it does not offer a fantasy of central control. It treats DNS as a system that must change through shared rules, visible evidence and reversible steps. Key tag 38696 is a small number carrying that large burden. Success is not measured by whether every operator notices it, but by whether those who need to act can find the problem before their users do.