Iroh 1.2: Relay Auth and DNS Changes to Test

Read the release as several separate changes

The official release record groups features, bug fixes, refactors, and dependency updates. That matters because the acceptance test for a resolver change is different from the test for relay authorization or mapped-address construction. Put each item in the runbook with an observable result. A single successful peer connection is not enough to validate all of the release’s paths.

Relay denial should be diagnosable

Iroh 1.2 adds RelayStatus::auth_denied_reason and an example. That gives an application a more useful signal when a relay refuses authorization. Map the reason into an operator-facing diagnostic without copying sensitive identifiers into a public error. Test an authorized relay, a deliberately denied relay, an unavailable relay, and a recovered relay. Confirm the application distinguishes policy denial from connection timeout and DNS failure.

Fallback nameservers change the failure model

The release says fallback nameservers became configurable through n0-dns-resolver. This can improve resilience when the primary resolver path fails, but it also creates another dependency and another possible metadata path. Define whether fallback is allowed, which resolver is trusted for the threat model, how long a failure is cached, and how an operator knows fallback was used. Test the configuration under controlled resolver failures.

Mapped addresses should be treated as implementation details

The release includes cleanup of mapped-address construction. Applications should avoid depending on an within the service formatting detail unless the public API promises it. Instead, test the public behavior: address parsing, endpoint selection, relay connection, direct-path upgrade where applicable, and error reporting. Record the version because a change in representation can surface in logs, caches, or persisted tickets even when the application-level connection still works.

Dependency updates need lockfile evidence

Iroh 1.2 updates noq, noq-proto, and noq-udp to 1.3.0 and upgrades a chacha20 dependency away from a yanked version. Capture the lockfile diff and the source release records. Rebuild from a clean environment, run the integration fixture, and inspect the final dependency graph. This is particularly important for Rust projects where a transitive change can affect platform support or feature flags without a visible application-code edit.

Limit the claim

The release indicates active maintenance and targeted improvements. It does not prove a specific direct-connect rate, relay privacy property, latency, or support outcome. Iroh remains a networking component whose application still defines authorization, data semantics, persistence, and operational policy. Use the release to improve evidence in those areas rather than using a version number as a substitute for testing.

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.