iroh 1.0.1: Compatibility Fix and the DNS Fallback

A patch release that fills environment gaps

1.0.1 is the first patch over the 1.0.0 stable, and its changes are characteristic of a patch: small, targeted, and aimed at the gaps that surface after a stable release is in use. There is no new feature surface and no breaking change. The items are a compatibility fix, a logging change, a documentation fix, and a DNS fallback. The through-line is that 1.0.0 worked in the environments it was designed for, and 1.0.1 extends it to the environments that were not.

That framing matters when deciding whether to take the patch. If you are on 1.0.0 in the environments the design targets, 1.0.1 is low-risk and worth taking for the compatibility fix. If you are running iroh in a non-JNI environment and the DNS path is failing or degraded, 1.0.1 is specifically the release that addresses that, because it is where the fallback nameservers were added.

The DNS fallback in detail

The iroh-dns component can resolve names through a JNI context, which is the bridge to a Java or Android runtime's DNS. In a plain server or a CLI build, no such context exists. Before 1.0.1, that absence could leave the DNS path without a way to resolve. The change makes iroh-dns use configured fallback nameservers when the JNI context is not initialized, so resolution proceeds against explicit servers rather than stalling on a missing bridge.

The operator takeaway is concrete: if your iroh deployment runs where there is no Java or Android runtime, 1.0.1 is the version where the DNS path is intended to work with explicit fallback servers. If you are on 1.0.0 in such an environment and seeing DNS failures, that is the gap this patch closes, and the fix is to take 1.0.1 and set the fallback nameservers to resolvers you trust in your network.

The compatibility and logging changes

The backwards-compatibility item is the kind of change that is invisible until it is missing. A refactor in the 1.0 line can drop an API surface or a behavior that a dependent built against, and the fix is to restore the missing piece. An operator should treat this as a reason to take the patch: it is the difference between a 1.0.0 that works for you and one that works for you minus a detail a dependency needs.

The logging change is a quality-of-life fix. Capping span levels at info means the tracing output does not carry span-level events above info, which reduces noise. For an operator who reads iroh logs to diagnose connectivity, less noise means the signals that matter, like a failed path or a relay fallback, stand out.

Documentation and build hygiene

1.0.1 also clarifies the documentation for QUIC streams, fixes a broken link to the production config file in iroh-dns-server, adds context to the portmapping configuration docs, and moves license links to HTTPS. These are not operational changes, but they are the kind that reduce friction: clearer QUIC stream docs help an operator understand what the transport is doing, and a correct portmapping config doc helps someone tuning connectivity in a restricted network.

There is also build and CI hygiene: a longer test timeout to avoid flakiness, a semver package list fix, and dependency updates to noq 1.0.1 and net-tools 0.19.1. The dependency bump is worth noting because, as with any dependency-driven codebase, the patch also moves the underlying noq and net-tools versions, so the build you get is not byte-identical to 1.0.0 even where the iroh code is unchanged.

What to verify on upgrade

The upgrade is low-risk, but the verification is environment-specific. If you run in a non-JNI environment, confirm that DNS resolution now works with your fallback nameservers. If you depend on the API surface that the compatibility item restored, confirm your dependent build is clean. And because the patch moves the noq and net-tools dependencies, rebuild and run a representative connection to confirm the stack still forms paths in your topology. For a stable-line patch, that is the whole job.

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 your environment; the release record can only describe what shipped.

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 iroh peer-to-peer networking explained for recovery planning and the private AI systems overview for the broader on-premises context.