starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #3350] AAAA queries return 0 answers from public resolvers #1174

New issue

Closed

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

kerem commented

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

Owner

Originally created by @TheTechromancer on GitHub (Nov 15, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3350

I've been running into this strange bug with hickory's DNS client, but only when making AAAA queries.

Environment

hickory-client: 0.25
OS: Linux 6.17.5-arch1-1
Rust: 1.83.0

Reproduction

[dependencies]
hickory-client = "0.25"
tokio = { version = "1", features = ["full"] }

use hickory_client::client::{Client, ClientHandle};
use hickory_client::proto::runtime::TokioRuntimeProvider;
use hickory_client::proto::rr::{DNSClass, Name, RecordType};
use hickory_client::proto::udp::UdpClientStream;
use std::net::SocketAddr;
use std::str::FromStr;

#[tokio::main]
async fn main() {
    let addr: SocketAddr = "8.8.8.8:53".parse().unwrap();
    let conn = UdpClientStream::builder(addr, TokioRuntimeProvider::default()).build();
    let (mut client, bg) = Client::connect(conn).await.unwrap();
    tokio::spawn(bg);

    let name = Name::from_str("google.com").unwrap();
    let response = client.query(name, DNSClass::IN, RecordType::AAAA).await.unwrap();
    println!("AAAA answers: {}", response.answers().len());  // 0 answers
}

Output:

AAAA answers: 0

Comparison with dig

$ dig @8.8.8.8 -t aaaa google.com +short
2404:6800:4006:814::200e

dig successfully retrieves AAAA records.

tcpdump capture

hickory AAAA query

10.37.153.67.8909 > 8.8.8.8.53: 10860+ [1au] AAAA? google.com. (39)
	0x0000:  4500 0043 c3e6 4000 4011 c34b 0a25 9943
	0x0010:  0808 0808 22cd 0035 002f b3b8 2a6c 0100
	0x0020:  0001 0000 0000 0001 0667 6f6f 676c 6503
	0x0030:  636f 6d00 001c 0001 0000 2904 d000 0000
	0x0040:  0000 00

8.8.8.8.53 > 10.37.153.67.8909: 10860 0/0/0 (28)
	0x0000:  4500 0038 5ccb 0000 3c11 6e72 0808 0808
	0x0010:  0a25 9943 0035 22cd 0024 6a6b 2a6c 8180
	0x0020:  0001 0000 0000 0000 0667 6f6f 676c 6503
	0x0030:  636f 6d00 001c 0001

dig AAAA query

10.37.153.67.38422 > 8.8.8.8.53: 18731+ [1au] AAAA? google.com. (51)
	0x0000:  4500 004f 6b82 0000 4011 5ba4 0a25 9943
	0x0010:  0808 0808 b0ac 0035 003b b3c4 6eaf 0120
	0x0020:  0001 0000 0000 0001 0667 6f6f 676c 6503
	0x0030:  636f 6d00 001c 0001 0000 2904 d000 0000
	0x0040:  0000 0c00 0a00 08c1 0b85 48b3 6086 fc

8.8.8.8.53 > 10.37.153.67.38422: 18731 1/0/1 AAAA 2404:6800:4006:814::200e (67)
	0x0000:  4500 005f 70d7 0000 6911 2d3f 0808 0808
	0x0010:  0a25 9943 0035 b0ac 004b b963 6eaf 8180
	0x0020:  0001 0001 0000 0001 0667 6f6f 676c 6503
	0x0030:  636f 6d00 001c 0001 c00c 001c 0001 0000
	0x0040:  012c 0010 2404 6800 4006 0814 0000 0000
	0x0050:  0000 200e 0000 2902 0000 0000 0000 00

Observation

hickory A query: 39 bytes → gets answer
hickory AAAA query: 39 bytes → 0 answers
dig AAAA query: 51 bytes → gets answer

Tested against: 8.8.8.8 and 1.1.1.1 (both exhibit same behavior)

Originally created by @TheTechromancer on GitHub (Nov 15, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3350 I've been running into this strange bug with hickory's DNS client, but only when making `AAAA` queries. ## Environment - hickory-client: 0.25 - OS: Linux 6.17.5-arch1-1 - Rust: 1.83.0 ## Reproduction ```toml [dependencies] hickory-client = "0.25" tokio = { version = "1", features = ["full"] } ``` ```rust use hickory_client::client::{Client, ClientHandle}; use hickory_client::proto::runtime::TokioRuntimeProvider; use hickory_client::proto::rr::{DNSClass, Name, RecordType}; use hickory_client::proto::udp::UdpClientStream; use std::net::SocketAddr; use std::str::FromStr; #[tokio::main] async fn main() { let addr: SocketAddr = "8.8.8.8:53".parse().unwrap(); let conn = UdpClientStream::builder(addr, TokioRuntimeProvider::default()).build(); let (mut client, bg) = Client::connect(conn).await.unwrap(); tokio::spawn(bg); let name = Name::from_str("google.com").unwrap(); let response = client.query(name, DNSClass::IN, RecordType::AAAA).await.unwrap(); println!("AAAA answers: {}", response.answers().len()); // 0 answers } ``` Output: ``` AAAA answers: 0 ``` ## Comparison with dig ``` $ dig @8.8.8.8 -t aaaa google.com +short 2404:6800:4006:814::200e ``` dig successfully retrieves AAAA records. ## tcpdump capture ### hickory AAAA query ``` 10.37.153.67.8909 > 8.8.8.8.53: 10860+ [1au] AAAA? google.com. (39) 0x0000: 4500 0043 c3e6 4000 4011 c34b 0a25 9943 0x0010: 0808 0808 22cd 0035 002f b3b8 2a6c 0100 0x0020: 0001 0000 0000 0001 0667 6f6f 676c 6503 0x0030: 636f 6d00 001c 0001 0000 2904 d000 0000 0x0040: 0000 00 8.8.8.8.53 > 10.37.153.67.8909: 10860 0/0/0 (28) 0x0000: 4500 0038 5ccb 0000 3c11 6e72 0808 0808 0x0010: 0a25 9943 0035 22cd 0024 6a6b 2a6c 8180 0x0020: 0001 0000 0000 0000 0667 6f6f 676c 6503 0x0030: 636f 6d00 001c 0001 ``` ### dig AAAA query ``` 10.37.153.67.38422 > 8.8.8.8.53: 18731+ [1au] AAAA? google.com. (51) 0x0000: 4500 004f 6b82 0000 4011 5ba4 0a25 9943 0x0010: 0808 0808 b0ac 0035 003b b3c4 6eaf 0120 0x0020: 0001 0000 0000 0001 0667 6f6f 676c 6503 0x0030: 636f 6d00 001c 0001 0000 2904 d000 0000 0x0040: 0000 0c00 0a00 08c1 0b85 48b3 6086 fc 8.8.8.8.53 > 10.37.153.67.38422: 18731 1/0/1 AAAA 2404:6800:4006:814::200e (67) 0x0000: 4500 005f 70d7 0000 6911 2d3f 0808 0808 0x0010: 0a25 9943 0035 b0ac 004b b963 6eaf 8180 0x0020: 0001 0001 0000 0001 0667 6f6f 676c 6503 0x0030: 636f 6d00 001c 0001 c00c 001c 0001 0000 0x0040: 012c 0010 2404 6800 4006 0814 0000 0000 0x0050: 0000 200e 0000 2902 0000 0000 0000 00 ``` ## Observation - hickory A query: 39 bytes → gets answer - hickory AAAA query: 39 bytes → 0 answers - dig AAAA query: 51 bytes → gets answer Tested against: 8.8.8.8 and 1.1.1.1 (both exhibit same behavior)

kerem closed this issue

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

kerem commented

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

Author

Owner

@djc commented on GitHub (Nov 15, 2025):

That is strange. Why are you using the client API rather than the resolver API?

@djc commented on GitHub (Nov 15, 2025): That is strange. Why are you using the client API rather than the resolver API?

kerem commented

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

Author

Owner

@TheTechromancer commented on GitHub (Nov 16, 2025):

I need a low level API without the caching / retry logic. Client seemed like the right choice.

I'm pretty new to the library, though. It's possible I'm using it wrong?

@TheTechromancer commented on GitHub (Nov 16, 2025): I need a low level API without the caching / retry logic. Client seemed like the right choice. I'm pretty new to the library, though. It's possible I'm using it wrong?

kerem commented

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

Author

Owner

@marcus0x62 commented on GitHub (Nov 16, 2025):

I can't reproduce this testing on an almost identical system - I get the correct 4 AAAA responses with hickory-0.25.2 compiled with rust 1.83.0.

To troubleshoot this further, we'll need:

Some debug logs. Add tracing and tracing-subscriber to your test project dependencies:

[dependencies]
hickory-client = "0.25"
tokio = { version = "1", features = ["full"] }
tracing = "0.1"
tracing-subscriber = { version = "0.3.20", features = ["env-filter"] }

and a tracing subscriber to your code:

    let subscriber = tracing_subscriber::FmtSubscriber::builder()
        .with_env_filter(tracing_subscriber::EnvFilter::from_default_env())
        .with_test_writer()
        .finish();
    tracing::subscriber::set_global_default(subscriber).unwrap();

run with RUST_LOG=trace cargo run

The hickory-related entries from your Cargo.lock file (version, source, and checksum) for both hickory-proto and hickory-client
A PCAP-/PCAPng-formatted packet capture

@marcus0x62 commented on GitHub (Nov 16, 2025): I can't reproduce this testing on an almost identical system - I get the correct 4 AAAA responses with hickory-0.25.2 compiled with rust 1.83.0. To troubleshoot this further, we'll need: 1. Some debug logs. Add tracing and tracing-subscriber to your test project dependencies: ``` [dependencies] hickory-client = "0.25" tokio = { version = "1", features = ["full"] } tracing = "0.1" tracing-subscriber = { version = "0.3.20", features = ["env-filter"] } ``` and a tracing subscriber to your code: ``` let subscriber = tracing_subscriber::FmtSubscriber::builder() .with_env_filter(tracing_subscriber::EnvFilter::from_default_env()) .with_test_writer() .finish(); tracing::subscriber::set_global_default(subscriber).unwrap(); ``` run with ```RUST_LOG=trace cargo run``` 2. The hickory-related entries from your Cargo.lock file (version, source, and checksum) for both hickory-proto and hickory-client 3. A PCAP-/PCAPng-formatted packet capture

kerem commented

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

Author

Owner

@TheTechromancer commented on GitHub (Nov 21, 2025):

No longer triggering for me either. I first encountered this while on an international flight, on the in-plane Wi-Fi. The network must have been doing some kind of DNS inspection. Why dig worked and hickory didn't may be a mystery for the ages.

@TheTechromancer commented on GitHub (Nov 21, 2025): No longer triggering for me either. I first encountered this while on an international flight, on the in-plane Wi-Fi. The network must have been doing some kind of DNS inspection. Why dig worked and hickory didn't may be a mystery for the ages.