Iroh DNS 1.3.0: Release Scope and Upgrade Tests

First identify which component was released

The public v1.3.0 tag is titled “chore: Release iroh-dns version 1.3.0.” That is narrower than an Iroh endpoint release. The Iroh v1.2.0 release record, dated September 9, lists the related changes in the broader project: an auth-denied reason on RelayStatus, deprecated nameserver builders, configurable fallback nameservers, mapped-address cleanup, and an upgrade to noq 1.3.0. Separate the component tag from the project release when writing a dependency record.

Resolver configuration is an operational input

Fallback nameservers are not a decorative setting. They can affect reachability, privacy exposure, failure behavior, and the time required to diagnose an outage. Record which resolver path the application uses, when fallback is activated, and what metadata a resolver can observe. Test a normal response, a primary resolver failure, a malformed response, and a recovery. Do this with the actual platform resolver behavior rather than assuming desktop and mobile stacks fail the same way.

Deprecation needs a code search and a runtime test

The release notes say old nameserver builders were deprecated. Deprecation is a warning about future compatibility, not evidence that the old API is already broken. Search the code and lockfiles for the old builder names, update one controlled path, and compile or run the example. Then test the resulting resolver configuration. A clean build can still hide a runtime fallback that never activates in the network conditions the application cares about.

Relay authorization signals help diagnosis

The broader 1.2 release adds RelayStatus::auth_denied_reason and an example. An operator can use a structured reason to distinguish a relay authorization problem from a DNS, firewall, or endpoint problem. Preserve that distinction in logs and dashboards. Do not expose sensitive connection details to users unnecessarily, but do retain enough context to determine whether a failed path is policy, configuration, or reachability.

The transport dependency is not a performance promise

The release upgrades noq, noq-proto, and noq-udp to 1.3.0 and includes a non-yanked chacha20 dependency update. These are useful dependency facts for a lockfile review. They do not establish a latency, throughput, battery, or connection-success improvement for your application. Run a fixture that measures the behavior you need, under the network conditions you actually support, and retain the old result for comparison.

A component-aware rollout

Pin iroh and iroh-dns versions separately when the build system allows it, document the source tag, and capture the resolver configuration. Stage the change with unit tests, an integration resolver test, relay-auth failure handling, and an upgrade from the prior lockfile. If a regression appears, roll back the component and the configuration together. The safest release note is the one that says exactly which component changed and which paths were tested.

Evidence to retain after the change

Keep a short record of the artifact you installed, the source release or package metadata, the date of the change, the configuration values that affect the tested path, and the exact fixture used. Record both the expected result and the observed result. For a networked service, include the client version, the route taken, the identity used for the test, and the relevant log event. For a data or AI workflow, include the asset class, permission decision, model or job identifier, output destination, and retention decision without copying sensitive payloads into the report. If the test fails, preserve the failure state long enough to explain it, then restore the known-good version or isolated copy. This record makes a later upgrade comparable and gives another operator a way to reproduce the acceptance check. It also prevents a release note from becoming an unsupported promise about availability, privacy, or performance.

Implementation notes for a repeatable review

Use a clean fixture and a written acceptance record for the next run. Name the source artifact, package or image, configuration revision, client version, identity, test data class, expected result, and observed result. Include at least one negative case: a wrong version, denied identity, unavailable peer, malformed input, failed migration, or revoked permission, depending on the subject. Preserve the prior known-good environment until the fixture passes. For a networked system, inspect the route, proxy, resolver, relay, and relevant logs. For a data workflow, inspect the owner boundary, output release, retention, and backup treatment. This is deliberately more specific than saying that an upgrade was successful. It leaves a trace that can be compared after the next release and makes the limitation of the article visible: the sources describe the software, while only an exercised environment can describe your result.

Limitations

• A release note is not a deployment audit. It does not inspect your operating system, network policy, credentials, storage, backups, or administrative process.
• Version numbers and documentation change. Pin the exact artifacts you test, record the date, and re-check upstream material before a production change.
• A feature that exists in a package or command does not automatically fit your threat model. Authentication, authorization, logging, patching, recovery, and abuse controls remain operator responsibilities.
• This article contains no benchmark, uptime promise, adoption statistic, cost saving, or client result. Measure those claims in the environment that matters to you.

Related infrastructure context

For the physical layer around a systems deployment, TismTek provides fiber and network infrastructure work near Aurora. The team also documents on-premises compute and private AI systems. For a site discussion, call (720) 694-1976. See the 3-2-1 backup guide for recovery planning and the private AI systems overview for the broader on-premises context.