[GH-ISSUE #3331] Resolving `.onion` addresses is instantly rejected with NxDomain, even in environments where it's valid #1169

New issue

Closed

opened 2026-03-16 01:48:01 +03:00 by kerem · 3 comments

kerem commented

2026-03-16 01:48:01 +03:00

Owner

Originally created by @nabijaczleweli on GitHub (Oct 25, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3331

Describe the bug
hickory-dns rejects resolving onion addresses.

To Reproduce
Steps to reproduce the behavior: try to do that.

Expected behavior
Should work when DNS can resolve onion addresses.

System:

OS: any I suppose, but reproed this when porting to Whonix
Architecture: amd64
Version 12 (bookworm)
rustc version: 1.88.0 (6b00bc388 2025-06-23)

Version:
Crate: resolver (for matching .onion in inner_lookup), proto (for having the broken ONION definition)
Version: aef1fcc1f0, 0.24.4

Additional context
The easiest way to get to an environment where the recursor resolves .onion addresses is running tor DNSPort 53 AutomapHostsOnResolve 1 with a resolv.conf of nameserver 127.0.0.1.

(The regular way to do this is torsocks, but that only patches the libc resolver.)

Originally created by @nabijaczleweli on GitHub (Oct 25, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3331 **Describe the bug** hickory-dns rejects resolving onion addresses. **To Reproduce** Steps to reproduce the behavior: try to do that. <img width="1040" height="848" alt="Image" src="https://github.com/user-attachments/assets/8f7a0667-5543-4ea3-98b3-b515a4d126ae" /> **Expected behavior** Should work when DNS can resolve onion addresses. <img width="1040" height="848" alt="Image" src="https://github.com/user-attachments/assets/fbb66d4d-64f0-4552-ae3e-c27771eb2dba" /> **System:** - OS: any I suppose, but reproed this when porting to Whonix - Architecture: amd64 - Version 12 (bookworm) - rustc version: 1.88.0 (6b00bc388 2025-06-23) **Version:** Crate: resolver (for matching .onion in inner_lookup), proto (for having the broken ONION definition) Version: aef1fcc1f018b0efd258c6b45cbfe1de0a62ece7, 0.24.4 **Additional context** The easiest way to get to an environment where the recursor resolves `.onion` addresses is running `tor DNSPort 53 AutomapHostsOnResolve 1` with a resolv.conf of `nameserver 127.0.0.1`. (The regular way to do this is torsocks, but that only patches the libc resolver.)

kerem closed this issue

2026-03-16 01:48:06 +03:00

kerem commented

2026-03-16 01:48:12 +03:00

Author

Owner

@djc commented on GitHub (Oct 26, 2025):

I'm open to reviewing a PR for this. Not sure how you mean that proto has a broken .onion definition. (We won't be releasing any 0.24.x versions, but if you want to backport to release/0.25 we can release that, too.)

@djc commented on GitHub (Oct 26, 2025): I'm open to reviewing a PR for this. Not sure how you mean that proto has a broken .onion definition. (We won't be releasing any 0.24.x versions, but if you want to backport to `release/0.25` we can release that, too.)

kerem commented

2026-03-16 01:48:17 +03:00

Author

Owner

@cpu commented on GitHub (Oct 26, 2025):

Hmm, RFC 7686 is fairly clear about how resolvers should respond to lookup requests for the special purpose .onion TLD:

Name Resolution APIs and Libraries: Resolvers MUST either respond to requests for .onion names by resolving them according to [tor-rendezvous] or by responding with NXDOMAIN [RFC1035].

A quick read makes it sound like NXDOMAIN is the correct response since I don't think we would want to implement the tor-rendezvous protocol in this crate?

The guidance is similar for caching and authoritative servers.

@cpu commented on GitHub (Oct 26, 2025): Hmm, [RFC 7686](https://datatracker.ietf.org/doc/html/rfc7686) is fairly clear about [how resolvers should respond to lookup requests](https://datatracker.ietf.org/doc/html/rfc7686#section-2) for the special purpose `.onion` TLD: > Name Resolution APIs and Libraries: Resolvers MUST either respond to requests for .onion names by resolving them according to [[tor-rendezvous](https://datatracker.ietf.org/doc/html/rfc7686#ref-tor-rendezvous)] or by responding with NXDOMAIN [[RFC1035](https://datatracker.ietf.org/doc/html/rfc1035)]. A quick read makes it sound like NXDOMAIN is the correct response since I don't think we would want to implement the tor-rendezvous protocol in this crate? The guidance is similar for caching and authoritative servers.

kerem commented

2026-03-16 01:48:22 +03:00

Author

Owner

@marcus0x62 commented on GitHub (Oct 27, 2025):

A quick read makes it sound like NXDOMAIN is the correct response since I don't think we would want to implement the tor-rendezvous protocol in this crate?

Yes. This was done intentionally in #1479 (see discussion in #1382.)

@marcus0x62 commented on GitHub (Oct 27, 2025): > A quick read makes it sound like NXDOMAIN is the correct response since I don't think we would want to implement the tor-rendezvous protocol in this crate? Yes. This was done intentionally in #1479 (see discussion in #1382.)

kerem referenced this issue

2026-03-16 04:58:05 +03:00

[PR #1169] [MERGED] Bump js-sys from 0.3.41 to 0.3.42 #2040