openthread_border_router: Fix upstream DNS resolution for Thread devices - #4794
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe OpenThread Border Router add-on disables upstream DNS socket binding to the infrastructure interface. The add-on version changes to ChangesOpenThread DNS update
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The PR restores upstream DNS resolution by changing the resolver interface-binding configuration. No actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1b94201 to
4f92bec
Compare
Since add-on 2.12.0 (OTBR bump to b041fa52, which pulled in OpenThread d88b63d19 / openthread/openthread#10864) the upstream DNS resolver binds its UDP sockets to the infrastructure interface via SO_BINDTODEVICE. The add-on runs with host networking, and the nameserver in /etc/resolv.conf is the Supervisor DNS (172.30.32.3), which is only reachable through the hassio bridge. With the socket bound, the kernel routes the query out the physical interface via the default route instead, where it goes unanswered: upstream DNS queries from Thread devices, and with them NAT64/DNS64 name resolution (device cloud connectivity, MQTT broker hostnames, ...), time out. Disable the binding via OPENTHREAD_POSIX_CONFIG_UPSTREAM_DNS_BIND_TO_INFRA_NETIF in the project config header so upstream queries follow the host routing table again, as they did before 2.12.0. A behavioral fix has been proposed upstream (openthread/openthread#13545); this define can be dropped once it is merged and picked up. Notes from debugging, for future reference: - Networks whose router advertises RDNSS in router advertisements are NOT affected on recent add-on versions: since OpenThread #11342 (March 2025) the resolver also queries RDNSS-discovered servers, which are on-link on the infrastructure interface and work despite the binding. This masked the regression and made it appear environment-dependent. IPv4-only networks (no RDNSS) are always affected. - `ot-ctl dns resolve4` on the border router itself is not a valid test for this path: in our testing such queries never reached the BR's own DNS-SD server, independent of this bug. Test from an actual Thread device (or a TREL-connected OpenThread CLI node). Fixes home-assistant#3947
4f92bec to
ddf92e9
Compare
There was a problem hiding this comment.
Pull request overview
Fixes Thread-device upstream DNS/DNS64 resolution by allowing DNS queries to follow host routing to Supervisor DNS.
Changes:
- Disables binding upstream DNS sockets to the infrastructure interface.
- Bumps the add-on version to 3.1.2.
- Documents the regression fix.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
openthread_border_router/openthread-core-ha-config-posix.h |
Adds the DNS socket binding override. |
openthread_border_router/config.yaml |
Bumps the release version. |
openthread_border_router/CHANGELOG.md |
Adds 3.1.2 release notes. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
sairon
left a comment
sairon
left a comment
There was a problem hiding this comment.
Other than the comments that are too chatty to my taste, LGTM!
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
Summary
Fixes upstream DNS resolution (and with it NAT64/DNS64 name resolution) for Thread devices, broken since add-on 2.12.0. Fixes #3947.
Root cause
The 2.12.0 OTBR bump (
ff7227ea→b041fa52) pulled in OpenThread commitd88b63d19(openthread/openthread#10864), which binds the upstream DNS resolver's UDP sockets to the infrastructure interface viaSO_BINDTODEVICE. The add-on runs with host networking, and its/etc/resolv.confpoints at the Supervisor DNS (172.30.32.3) — reachable only through thehassiobridge, not through the infra interface (end0/eth0). With the socket bound, the kernel routes the query out the physical interface via the default route, where it goes unanswered. Result:DnssdServer: Upstream query transaction N closed: ResponseTimeout.for every upstream query from a Thread device.Fix
Set
OPENTHREAD_POSIX_CONFIG_UPSTREAM_DNS_BIND_TO_INFRA_NETIF 0in the project config header, restoring the pre-2.12.0 behavior (queries follow the host routing table and reach the Supervisor DNS on the bridge). A behavioral fix has been proposed upstream in openthread/openthread#13545 (bind only RDNSS-discovered on-link servers, never host-scoped resolv.conf servers); once merged and picked up, this define can be dropped.Verified on a Home Assistant Yellow: a Thread client resolving
example.comvia the border router now gets DNS64-synthesized answers again; the query and response are visible on thehassiobridge toward172.30.32.3.Wrinkles worth knowing (why this was hard to reproduce)
ot-ctl br rdnsstable), upstream DNS appears healthy even unpatched. IPv4-only networks (no RDNSS) are always affected, which matches the reporters in OTBR: Default DNS not able to resolve IPv4 addresses since 2.12.0 #3947.ot-ctl dns resolve4on the border router itself never reached the BR's own DNS-SD server in our testing, independent of this bug (it failed the same way on known-good 2.11.x, see https://github.com/orgs/openthread/discussions/9782). Only queries from an actual Thread device (or a TREL-connected OT CLI node) exercise the fixed path.🤖 Generated with Claude Code
Summary by CodeRabbit
Summary by CodeRabbit
Bug Fixes
Chores