starred/hickory-dns
1
0
Fork 0
mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00
Code Issues 373 Projects Releases 6 Packages Wiki Activity

[GH-ISSUE #2140] Resolver couldn't handle response that have lots of records #900

New issue
Closed
opened 2026-03-16 00:47:58 +03:00 by kerem · 13 comments
kerem commented 2026-03-16 00:47:58 +03:00
Owner
Copy link

Originally created by @zonyitoo on GitHub (Feb 8, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2140

Describe the bug

Bug was originally reported in: shadowsocks/shadowsocks-rust#1425 .

Reporter @qwerttvv was using smartdns to get DNS resolving result from multiple DNS servers, which would result in a large response, > 40 IPs in this reproducible case.

Tokio's builtin resolver could handle this case well, but hickory-dns rejected this response with error: NoRecordsFound.

Here are some releated logs from the original issue:

[shadowsocks_service::server::tcprelay] accepted tcp client connection 127.0.0.1:57150, establishing tunnel to s3.amazonaws.com:443
2024-02-08T11:52:42.269204+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268559059+08:00 DEBUG [hickory_proto::xfer::dns_handle] querying: s3.amazonaws.com A querying: s3.amazonaws.com A
2024-02-08T11:52:42.269265+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268580757+08:00 DEBUG [hickory_resolver::name_server::name_server_pool] sending request: [Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] sending request: [Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }]
2024-02-08T11:52:42.269304+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268594126+08:00 DEBUG [hickory_resolver::name_server::name_server] reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: true, bind_addr: None } reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: true, bind_addr: None }
2024-02-08T11:52:42.269364+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268607124+08:00 DEBUG [hickory_proto::xfer] enqueueing message:QUERY:[Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] enqueueing message:QUERY:[Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }]
2024-02-08T11:52:42.269400+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268620252+08:00 DEBUG [hickory_proto::xfer::dns_exchange] io_stream is done, shutting down io_stream is done, shutting down
2024-02-08T11:52:42.269437+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268650279+08:00 DEBUG [hickory_proto::udp::udp_client_stream] final message: ; header 52342:QUERY:RD:NoError:QUERY:0/0/0
2024-02-08T11:52:42.269466+08:00 JP384 ssserver[393]: ; query
2024-02-08T11:52:42.269492+08:00 JP384 ssserver[393]: ;; s3.amazonaws.com. IN A
2024-02-08T11:52:42.269518+08:00 JP384 ssserver[393]:  final message: ; header 52342:QUERY:RD:NoError:QUERY:0/0/0
2024-02-08T11:52:42.269545+08:00 JP384 ssserver[393]: ; query
2024-02-08T11:52:42.269588+08:00 JP384 ssserver[393]: ;; s3.amazonaws.com. IN A
2024-02-08T11:52:42.269621+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.26867388+08:00 DEBUG [hickory_proto::udp::udp_stream] created socket successfully created socket successfully
2024-02-08T11:52:42.269650+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268843571+08:00 WARN [hickory_proto::udp::udp_client_stream] dropped malformed message waiting for id: 52342 err: rdata length too large for remaining bytes, need: 4 remain: 2 dropped malformed message waiting for id: 52342 err: rdata length too large for remaining bytes, need: 4 remain: 2
2024-02-08T11:52:47.270687+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270044954+08:00 DEBUG [hickory_resolver::name_server::name_server] name_server connection failure: request timed out name_server connection failure: request timed out
2024-02-08T11:52:47.270863+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270112979+08:00 DEBUG [hickory_resolver::name_server::name_server_pool] sending request: [Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] sending request: [Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }]
2024-02-08T11:52:47.270897+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270125776+08:00 DEBUG [hickory_resolver::name_server::name_server] reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: true, bind_addr: None } reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: true, bind_addr: None }
2024-02-08T11:52:47.270959+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.27014698+08:00 DEBUG [hickory_proto::xfer] enqueueing message:QUERY:[Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] enqueueing message:QUERY:[Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }]
2024-02-08T11:52:47.271002+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270161672+08:00 DEBUG [hickory_proto::xfer::dns_exchange] io_stream is done, shutting down io_stream is done, shutting down
2024-02-08T11:52:47.271035+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270174619+08:00 DEBUG [hickory_proto::udp::udp_client_stream] final message: ; header 27171:QUERY:RD:NoError:QUERY:0/0/0
2024-02-08T11:52:47.271059+08:00 JP384 ssserver[393]: ; query
2024-02-08T11:52:47.271080+08:00 JP384 ssserver[393]: ;; s3.amazonaws.com. IN A
2024-02-08T11:52:47.271153+08:00 JP384 ssserver[393]:  final message: ; header 27171:QUERY:RD:NoError:QUERY:0/0/0
2024-02-08T11:52:47.271187+08:00 JP384 ssserver[393]: ; query
2024-02-08T11:52:47.271216+08:00 JP384 ssserver[393]: ;; s3.amazonaws.com. IN A
2024-02-08T11:52:47.271243+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270216238+08:00 DEBUG [hickory_proto::udp::udp_stream] created socket successfully created socket successfully
2024-02-08T11:52:47.271272+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270414678+08:00 WARN [hickory_proto::udp::udp_client_stream] dropped malformed message waiting for id: 27171 err: rdata length too large for remaining bytes, need: 4 remain: 2 dropped malformed message waiting for id: 27171 err: rdata length too large for remaining bytes, need: 4 remain: 2
2024-02-08T11:52:52.271316+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.270680087+08:00 DEBUG [hickory_resolver::name_server::name_server] name_server connection failure: request timed out name_server connection failure: request timed out
2024-02-08T11:52:52.271508+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.270754601+08:00 DEBUG [hickory_resolver::name_server::name_server_pool] sending request: [Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] sending request: [Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }]
2024-02-08T11:52:52.271616+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.270766517+08:00 DEBUG [hickory_resolver::name_server::name_server] reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: true, bind_addr: None } reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: true, bind_addr: None }
2024-02-08T11:52:52.271645+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.27077776+08:00 DEBUG [hickory_proto::xfer] enqueueing message:QUERY:[Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] enqueueing message:QUERY:[Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }]
2024-02-08T11:52:52.271665+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.270785896+08:00 DEBUG [hickory_proto::xfer::dns_exchange] io_stream is done, shutting down io_stream is done, shutting down
2024-02-08T11:52:52.271697+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.270794695+08:00 DEBUG [hickory_proto::udp::udp_client_stream] final message: ; header 51861:QUERY:RD:NoError:QUERY:0/0/0
2024-02-08T11:52:52.271729+08:00 JP384 ssserver[393]: ; query
2024-02-08T11:52:52.271758+08:00 JP384 ssserver[393]: ;; s3.amazonaws.com. IN A
2024-02-08T11:52:52.271785+08:00 JP384 ssserver[393]:  final message: ; header 51861:QUERY:RD:NoError:QUERY:0/0/0
2024-02-08T11:52:52.271812+08:00 JP384 ssserver[393]: ; query
2024-02-08T11:52:52.271843+08:00 JP384 ssserver[393]: ;; s3.amazonaws.com. IN A
2024-02-08T11:52:52.271874+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.270825779+08:00 DEBUG [hickory_proto::udp::udp_stream] created socket successfully created socket successfully
2024-02-08T11:52:52.271908+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.271037648+08:00 WARN [hickory_proto::udp::udp_client_stream] dropped malformed message waiting for id: 51861 err: rdata length too large for remaining bytes, need: 4 remain: 2 dropped malformed message waiting for id: 51861 err: rdata length too large for remaining bytes, need: 4 remain: 2
2024-02-08T11:52:57.272890+08:00 JP384 ssserver[393]: 2024-02-08T11:52:57.272195666+08:00 DEBUG [hickory_resolver::name_server::name_server] name_server connection failure: request timed out name_server connection failure: request timed out
2024-02-08T11:52:57.273044+08:00 JP384 ssserver[393]: 2024-02-08T11:52:57.272257683+08:00 DEBUG [hickory_resolver::lookup_ip] both of ipv4 or ipv6 lookup failed in ipv4_and_ipv6 strategy e1: no record found for Query { name: Name("s3.amazonaws.com."), query_type: AAAA, query_class: IN }, e2: request timed out both of ipv4 or ipv6 lookup failed in ipv4_and_ipv6 strategy e1: no record found for Query { name: Name("s3.amazonaws.com."), query_type: AAAA, query_class: IN }, e2: request timed out
2024-02-08T11:52:57.273072+08:00 JP384 ssserver[393]: 2024-02-08T11:52:57.272283576+08:00 TRACE [393:140006582647608] [shadowsocks::dns_resolver::resolver] DNS resolved s3.amazonaws.com:443 with hickory-dns 15.003744s
2024-02-08T11:52:57.273093+08:00 JP384 ssserver[393]: 2024-02-08T11:52:57.272338748+08:00 ERROR [393:140006582647608] [shadowsocks_service::server::tcprelay] tcp tunnel 127.0.0.1:57150 -> s3.amazonaws.com:443 connect failed, error: dns resolve s3.amazonaws.com:443 error: no record found for Query { name: Name("s3.amazonaws.com."), query_type: AAAA, query_class: IN }
2024-02-08T11:52:57.273112+08:00 JP384 ssserver[393]: 2024-02-08T11:52:57.272571863+08:00 DEBUG [393:140006582647608] [shadowsocks_service::server::tcprelay] tcp server stream aborted with error: dns resolve s3.amazonaws.com:443 error: no record found for Query { name: Name("s3.amazonaws.com."), query_type: AAAA, query_class: IN }

To Reproduce
Steps to reproduce the behavior:

  1. Generate a DNS response message with over 40 records for an A Query.
  2. Run AsyncResolver::lookup_ip.
  3. API returned an Err with type NoRecordsFound.

Expected behavior

hickory-dns should be able to handle these cases.

System:

  • rustc version: 1.75.0

Version:
Crate: resolver
Version: 0.24

Originally created by @zonyitoo on GitHub (Feb 8, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2140 **Describe the bug** Bug was originally reported in: shadowsocks/shadowsocks-rust#1425 . Reporter @qwerttvv was using [smartdns](https://github.com/pymumu/smartdns) to get DNS resolving result from multiple DNS servers, which would result in a large response, > 40 IPs in this reproducible case. Tokio's builtin resolver could handle this case well, but hickory-dns rejected this response with error: `NoRecordsFound`. Here are some releated logs from the original issue: ``` [shadowsocks_service::server::tcprelay] accepted tcp client connection 127.0.0.1:57150, establishing tunnel to s3.amazonaws.com:443 2024-02-08T11:52:42.269204+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268559059+08:00 DEBUG [hickory_proto::xfer::dns_handle] querying: s3.amazonaws.com A querying: s3.amazonaws.com A 2024-02-08T11:52:42.269265+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268580757+08:00 DEBUG [hickory_resolver::name_server::name_server_pool] sending request: [Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] sending request: [Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] 2024-02-08T11:52:42.269304+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268594126+08:00 DEBUG [hickory_resolver::name_server::name_server] reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: true, bind_addr: None } reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: true, bind_addr: None } 2024-02-08T11:52:42.269364+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268607124+08:00 DEBUG [hickory_proto::xfer] enqueueing message:QUERY:[Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] enqueueing message:QUERY:[Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] 2024-02-08T11:52:42.269400+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268620252+08:00 DEBUG [hickory_proto::xfer::dns_exchange] io_stream is done, shutting down io_stream is done, shutting down 2024-02-08T11:52:42.269437+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268650279+08:00 DEBUG [hickory_proto::udp::udp_client_stream] final message: ; header 52342:QUERY:RD:NoError:QUERY:0/0/0 2024-02-08T11:52:42.269466+08:00 JP384 ssserver[393]: ; query 2024-02-08T11:52:42.269492+08:00 JP384 ssserver[393]: ;; s3.amazonaws.com. IN A 2024-02-08T11:52:42.269518+08:00 JP384 ssserver[393]: final message: ; header 52342:QUERY:RD:NoError:QUERY:0/0/0 2024-02-08T11:52:42.269545+08:00 JP384 ssserver[393]: ; query 2024-02-08T11:52:42.269588+08:00 JP384 ssserver[393]: ;; s3.amazonaws.com. IN A 2024-02-08T11:52:42.269621+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.26867388+08:00 DEBUG [hickory_proto::udp::udp_stream] created socket successfully created socket successfully 2024-02-08T11:52:42.269650+08:00 JP384 ssserver[393]: 2024-02-08T11:52:42.268843571+08:00 WARN [hickory_proto::udp::udp_client_stream] dropped malformed message waiting for id: 52342 err: rdata length too large for remaining bytes, need: 4 remain: 2 dropped malformed message waiting for id: 52342 err: rdata length too large for remaining bytes, need: 4 remain: 2 2024-02-08T11:52:47.270687+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270044954+08:00 DEBUG [hickory_resolver::name_server::name_server] name_server connection failure: request timed out name_server connection failure: request timed out 2024-02-08T11:52:47.270863+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270112979+08:00 DEBUG [hickory_resolver::name_server::name_server_pool] sending request: [Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] sending request: [Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] 2024-02-08T11:52:47.270897+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270125776+08:00 DEBUG [hickory_resolver::name_server::name_server] reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: true, bind_addr: None } reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: true, bind_addr: None } 2024-02-08T11:52:47.270959+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.27014698+08:00 DEBUG [hickory_proto::xfer] enqueueing message:QUERY:[Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] enqueueing message:QUERY:[Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] 2024-02-08T11:52:47.271002+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270161672+08:00 DEBUG [hickory_proto::xfer::dns_exchange] io_stream is done, shutting down io_stream is done, shutting down 2024-02-08T11:52:47.271035+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270174619+08:00 DEBUG [hickory_proto::udp::udp_client_stream] final message: ; header 27171:QUERY:RD:NoError:QUERY:0/0/0 2024-02-08T11:52:47.271059+08:00 JP384 ssserver[393]: ; query 2024-02-08T11:52:47.271080+08:00 JP384 ssserver[393]: ;; s3.amazonaws.com. IN A 2024-02-08T11:52:47.271153+08:00 JP384 ssserver[393]: final message: ; header 27171:QUERY:RD:NoError:QUERY:0/0/0 2024-02-08T11:52:47.271187+08:00 JP384 ssserver[393]: ; query 2024-02-08T11:52:47.271216+08:00 JP384 ssserver[393]: ;; s3.amazonaws.com. IN A 2024-02-08T11:52:47.271243+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270216238+08:00 DEBUG [hickory_proto::udp::udp_stream] created socket successfully created socket successfully 2024-02-08T11:52:47.271272+08:00 JP384 ssserver[393]: 2024-02-08T11:52:47.270414678+08:00 WARN [hickory_proto::udp::udp_client_stream] dropped malformed message waiting for id: 27171 err: rdata length too large for remaining bytes, need: 4 remain: 2 dropped malformed message waiting for id: 27171 err: rdata length too large for remaining bytes, need: 4 remain: 2 2024-02-08T11:52:52.271316+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.270680087+08:00 DEBUG [hickory_resolver::name_server::name_server] name_server connection failure: request timed out name_server connection failure: request timed out 2024-02-08T11:52:52.271508+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.270754601+08:00 DEBUG [hickory_resolver::name_server::name_server_pool] sending request: [Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] sending request: [Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] 2024-02-08T11:52:52.271616+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.270766517+08:00 DEBUG [hickory_resolver::name_server::name_server] reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: true, bind_addr: None } reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: true, bind_addr: None } 2024-02-08T11:52:52.271645+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.27077776+08:00 DEBUG [hickory_proto::xfer] enqueueing message:QUERY:[Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] enqueueing message:QUERY:[Query { name: Name("s3.amazonaws.com"), query_type: A, query_class: IN }] 2024-02-08T11:52:52.271665+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.270785896+08:00 DEBUG [hickory_proto::xfer::dns_exchange] io_stream is done, shutting down io_stream is done, shutting down 2024-02-08T11:52:52.271697+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.270794695+08:00 DEBUG [hickory_proto::udp::udp_client_stream] final message: ; header 51861:QUERY:RD:NoError:QUERY:0/0/0 2024-02-08T11:52:52.271729+08:00 JP384 ssserver[393]: ; query 2024-02-08T11:52:52.271758+08:00 JP384 ssserver[393]: ;; s3.amazonaws.com. IN A 2024-02-08T11:52:52.271785+08:00 JP384 ssserver[393]: final message: ; header 51861:QUERY:RD:NoError:QUERY:0/0/0 2024-02-08T11:52:52.271812+08:00 JP384 ssserver[393]: ; query 2024-02-08T11:52:52.271843+08:00 JP384 ssserver[393]: ;; s3.amazonaws.com. IN A 2024-02-08T11:52:52.271874+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.270825779+08:00 DEBUG [hickory_proto::udp::udp_stream] created socket successfully created socket successfully 2024-02-08T11:52:52.271908+08:00 JP384 ssserver[393]: 2024-02-08T11:52:52.271037648+08:00 WARN [hickory_proto::udp::udp_client_stream] dropped malformed message waiting for id: 51861 err: rdata length too large for remaining bytes, need: 4 remain: 2 dropped malformed message waiting for id: 51861 err: rdata length too large for remaining bytes, need: 4 remain: 2 2024-02-08T11:52:57.272890+08:00 JP384 ssserver[393]: 2024-02-08T11:52:57.272195666+08:00 DEBUG [hickory_resolver::name_server::name_server] name_server connection failure: request timed out name_server connection failure: request timed out 2024-02-08T11:52:57.273044+08:00 JP384 ssserver[393]: 2024-02-08T11:52:57.272257683+08:00 DEBUG [hickory_resolver::lookup_ip] both of ipv4 or ipv6 lookup failed in ipv4_and_ipv6 strategy e1: no record found for Query { name: Name("s3.amazonaws.com."), query_type: AAAA, query_class: IN }, e2: request timed out both of ipv4 or ipv6 lookup failed in ipv4_and_ipv6 strategy e1: no record found for Query { name: Name("s3.amazonaws.com."), query_type: AAAA, query_class: IN }, e2: request timed out 2024-02-08T11:52:57.273072+08:00 JP384 ssserver[393]: 2024-02-08T11:52:57.272283576+08:00 TRACE [393:140006582647608] [shadowsocks::dns_resolver::resolver] DNS resolved s3.amazonaws.com:443 with hickory-dns 15.003744s 2024-02-08T11:52:57.273093+08:00 JP384 ssserver[393]: 2024-02-08T11:52:57.272338748+08:00 ERROR [393:140006582647608] [shadowsocks_service::server::tcprelay] tcp tunnel 127.0.0.1:57150 -> s3.amazonaws.com:443 connect failed, error: dns resolve s3.amazonaws.com:443 error: no record found for Query { name: Name("s3.amazonaws.com."), query_type: AAAA, query_class: IN } 2024-02-08T11:52:57.273112+08:00 JP384 ssserver[393]: 2024-02-08T11:52:57.272571863+08:00 DEBUG [393:140006582647608] [shadowsocks_service::server::tcprelay] tcp server stream aborted with error: dns resolve s3.amazonaws.com:443 error: no record found for Query { name: Name("s3.amazonaws.com."), query_type: AAAA, query_class: IN } ``` **To Reproduce** Steps to reproduce the behavior: 1. Generate a DNS response message with over 40 records for an A Query. 2. Run `AsyncResolver::lookup_ip`. 3. API returned an `Err` with type `NoRecordsFound`. **Expected behavior** hickory-dns should be able to handle these cases. **System:** - rustc version: 1.75.0 **Version:** Crate: resolver Version: 0.24
kerem closed this issue 2026-03-16 00:48:04 +03:00
kerem commented 2026-03-16 00:48:10 +03:00
Author
Owner
Copy link

@qwerttvv commented on GitHub (Feb 8, 2024):

I'm sorry my English isn't good. I can read but I'm not good at writing.

Here is my short addition

Please investigate the performance of all kinds of records, not only A records and AAAA records

The example here is the domain s3.amazonaws.com, which has no AAAA

Of course, there are all kinds of other records

<!-- gh-comment-id:1934641979 --> @qwerttvv commented on GitHub (Feb 8, 2024): I'm sorry my English isn't good. I can read but I'm not good at writing. Here is my short addition Please investigate the performance of all kinds of records, not only A records and AAAA records The example here is the domain s3.amazonaws.com, which has no AAAA Of course, there are all kinds of other records
kerem commented 2026-03-16 00:48:15 +03:00
Author
Owner
Copy link

@zonyitoo commented on GitHub (Feb 16, 2024):

Just realized that ResolverOpts::edns0 is default to false.

<!-- gh-comment-id:1947697744 --> @zonyitoo commented on GitHub (Feb 16, 2024): Just realized that `ResolverOpts::edns0` is default to `false`.
kerem commented 2026-03-16 00:48:20 +03:00
Author
Owner
Copy link

@t0m commented on GitHub (Feb 17, 2024):

Hi, would this be considered a breaking change between 0.22.0 and 0.23.0? We have some queries that return slightly over 512 bytes using eDNS that work on 0.22.0, but are rejected on 0.23.0. It looks to be related to the refactor in #1975.

If it helps, we're not using hickory-dns directly, but software we depend on (apollo router) is using it.

<!-- gh-comment-id:1950223854 --> @t0m commented on GitHub (Feb 17, 2024): Hi, would this be considered a breaking change between 0.22.0 and 0.23.0? We have some queries that return slightly over 512 bytes using eDNS that work on 0.22.0, but are rejected on 0.23.0. It looks to be related to the refactor in #1975. If it helps, we're not using hickory-dns directly, but software we depend on (apollo router) is using it.
kerem commented 2026-03-16 00:48:25 +03:00
Author
Owner
Copy link

@djc commented on GitHub (Feb 17, 2024):

I think we usually use "breaking change" to mean an intentional change -- are you asking whether we would consider this a regression?

I'm not quite familiar with the workings of eDNS, but it certainly looks like #1975 helps compliance with the relevant standards rather than reducing it.

<!-- gh-comment-id:1950262094 --> @djc commented on GitHub (Feb 17, 2024): I think we usually use "breaking change" to mean an intentional change -- are you asking whether we would consider this a regression? I'm not quite familiar with the workings of eDNS, but it certainly looks like #1975 helps compliance with the relevant standards rather than reducing it.
kerem commented 2026-03-16 00:48:30 +03:00
Author
Owner
Copy link

@t0m commented on GitHub (Feb 17, 2024):

Certainly unintended, so a regression then.

0.22.0 works with eDNS out of the box, but apparently had truncation issues fixed in #1975
0.23.0 fixes the truncation issues, but apparently changes the default behavior that we were relying on for DNS responses above 512 bytes.

<!-- gh-comment-id:1950266752 --> @t0m commented on GitHub (Feb 17, 2024): Certainly unintended, so a regression then. 0.22.0 works with eDNS out of the box, but apparently had truncation issues fixed in #1975 0.23.0 fixes the truncation issues, but apparently changes the default behavior that we were relying on for DNS responses above 512 bytes.
kerem commented 2026-03-16 00:48:35 +03:00
Author
Owner
Copy link

@t0m commented on GitHub (Feb 17, 2024):

Here's a quick example:

Setup:

$ docker run -it rockylinux/rockylinux:8
[root@bcbad58998ae /]# yum install -y gcc && curl https://sh.rustup.rs -sSf | sh
[root@bcbad58998ae /]# source "$HOME/.cargo/env"

0.22.0 working

[root@bcbad58998ae /]# cargo install trust-dns-util --version 0.22.0
[root@bcbad58998ae /]# resolve --warn --udp --system 512.size.dns.netmeister.org
Querying for 512.size.dns.netmeister.org A from udp:192.168.65.7:53, tcp:192.168.65.7:53
Success for query 512.size.dns.netmeister.org IN A
	512.size.dns.netmeister.org. 377 IN A 127.0.0.20
        ...

0.23.0 timing out

[root@bcbad58998ae /]# cargo install trust-dns-util --version 0.23.0
[root@bcbad58998ae /]# resolve --warn --udp --system 512.size.dns.netmeister.org
Querying for 512.size.dns.netmeister.org A from udp:192.168.65.7:53, tcp:192.168.65.7:53
2024-02-17T19:12:29.767352Z  WARN trust_dns_proto::udp::udp_client_stream: dropped malformed message waiting for id: 21579 err: unexpected end of input reached
2024-02-17T19:12:34.772239Z  WARN trust_dns_proto::udp::udp_client_stream: dropped malformed message waiting for id: 50989 err: unexpected end of input reached
2024-02-17T19:12:39.776387Z  WARN trust_dns_proto::udp::udp_client_stream: dropped malformed message waiting for id: 1358 err: unexpected end of input reached
ResolveError { kind: Timeout }
<!-- gh-comment-id:1950287159 --> @t0m commented on GitHub (Feb 17, 2024): Here's a quick example: Setup: ```bash $ docker run -it rockylinux/rockylinux:8 [root@bcbad58998ae /]# yum install -y gcc && curl https://sh.rustup.rs -sSf | sh [root@bcbad58998ae /]# source "$HOME/.cargo/env" ``` 0.22.0 working ```bash [root@bcbad58998ae /]# cargo install trust-dns-util --version 0.22.0 [root@bcbad58998ae /]# resolve --warn --udp --system 512.size.dns.netmeister.org Querying for 512.size.dns.netmeister.org A from udp:192.168.65.7:53, tcp:192.168.65.7:53 Success for query 512.size.dns.netmeister.org IN A 512.size.dns.netmeister.org. 377 IN A 127.0.0.20 ... ``` 0.23.0 timing out ```bash [root@bcbad58998ae /]# cargo install trust-dns-util --version 0.23.0 [root@bcbad58998ae /]# resolve --warn --udp --system 512.size.dns.netmeister.org Querying for 512.size.dns.netmeister.org A from udp:192.168.65.7:53, tcp:192.168.65.7:53 2024-02-17T19:12:29.767352Z WARN trust_dns_proto::udp::udp_client_stream: dropped malformed message waiting for id: 21579 err: unexpected end of input reached 2024-02-17T19:12:34.772239Z WARN trust_dns_proto::udp::udp_client_stream: dropped malformed message waiting for id: 50989 err: unexpected end of input reached 2024-02-17T19:12:39.776387Z WARN trust_dns_proto::udp::udp_client_stream: dropped malformed message waiting for id: 1358 err: unexpected end of input reached ResolveError { kind: Timeout } ```
kerem commented 2026-03-16 00:48:40 +03:00
Author
Owner
Copy link

@bluejekyll commented on GitHub (Feb 17, 2024):

Is there a reason you need to use UDP in this context? I think google and a few other DNS resolvers out there restrict packet sizes to 512 bytes over UDP to prevent DDOSes. Can you use TCP instead?

<!-- gh-comment-id:1950402159 --> @bluejekyll commented on GitHub (Feb 17, 2024): Is there a reason you need to use UDP in this context? I think google and a few other DNS resolvers out there restrict packet sizes to 512 bytes over UDP to prevent DDOSes. Can you use TCP instead?
kerem commented 2026-03-16 00:48:45 +03:00
Author
Owner
Copy link

@bluejekyll commented on GitHub (Feb 17, 2024):

On another note, it's not obvious to me why that change (which is mostly oriented around the server), would impact the client stream. Do you think it's clear what is causing the issue there?

<!-- gh-comment-id:1950421311 --> @bluejekyll commented on GitHub (Feb 17, 2024): On another note, it's not obvious to me why that change (which is mostly oriented around the server), would impact the client stream. Do you think it's clear what is causing the issue there?
kerem commented 2026-03-16 00:48:50 +03:00
Author
Owner
Copy link

@bluejekyll commented on GitHub (Feb 17, 2024):

Ok, looking at this a little more, if the ends settings are 512, but the packet size returned is something larger, then I could see this as cutting off the response, and that's probably the issue. But isn't that what we want? Is there a reason we'd want to accept an upstream response that is greater than the size we've specified in EDNS?

<!-- gh-comment-id:1950428789 --> @bluejekyll commented on GitHub (Feb 17, 2024): Ok, looking at this a little more, if the ends settings are 512, but the packet size returned is something larger, then I could see this as cutting off the response, and that's probably the issue. But isn't that what we want? Is there a reason we'd want to accept an upstream response that is greater than the size we've specified in EDNS?
kerem commented 2026-03-16 00:48:55 +03:00
Author
Owner
Copy link

@t0m commented on GitHub (Feb 18, 2024):

Is there a reason you need to use UDP in this context? I think google and a few other DNS resolvers out there restrict packet sizes to 512 bytes over UDP to prevent DDOSes. Can you use TCP instead?

I was actually expecting it to fall back to TCP after the UDP path fails, but that does not seem to happen. I can dig in to the apollo-router settings we're using to see if it's forcing UDP somewhere.

On another note, it's not obvious to me why that change (which is mostly oriented around the server), would impact the client stream. Do you think it's clear what is causing the issue there?

I worked backwards from the warn message udp_client_stream: dropped malformed message waiting to udp_client_stream.rs, and noticed the changes around hoisting recv_buf out of the loop in #1975 looked suspicious. I'm not a rust programmer though, so my debugging is not worth much.

Ok, looking at this a little more, if the ends settings are 512, but the packet size returned is something larger, then I could see this as cutting off the response, and that's probably the issue. But isn't that what we want? Is there a reason we'd want to accept an upstream response that is greater than the size we've specified in EDNS?

One of the odd things I noticed when making the test reduction is 512.size.dns.netmeister.org actually returns a response size slightly smaller than 512, and it still triggers the issue.

$ dig 512.size.dns.netmeister.org | grep "EDNS\|MSG SIZE"
; EDNS: version: 0, flags:; udp: 1232
;; MSG SIZE  rcvd: 504
<!-- gh-comment-id:1951287450 --> @t0m commented on GitHub (Feb 18, 2024): > Is there a reason you need to use UDP in this context? I think google and a few other DNS resolvers out there restrict packet sizes to 512 bytes over UDP to prevent DDOSes. Can you use TCP instead? I was actually expecting it to fall back to TCP after the UDP path fails, but that does not seem to happen. I can dig in to the apollo-router settings we're using to see if it's forcing UDP somewhere. > On another note, it's not obvious to me why that change (which is mostly oriented around the server), would impact the client stream. Do you think it's clear what is causing the issue there? I worked backwards from the warn message `udp_client_stream: dropped malformed message waiting` to udp_client_stream.rs, and noticed the changes around hoisting `recv_buf` out of the loop in #1975 looked suspicious. I'm not a rust programmer though, so my debugging is not worth much. > Ok, looking at this a little more, if the ends settings are 512, but the packet size returned is something larger, then I could see this as cutting off the response, and that's probably the issue. But isn't that what we want? Is there a reason we'd want to accept an upstream response that is greater than the size we've specified in EDNS? One of the odd things I noticed when making the test reduction is `512.size.dns.netmeister.org` actually returns a response size slightly smaller than 512, and it still triggers the issue. ``` $ dig 512.size.dns.netmeister.org | grep "EDNS\|MSG SIZE" ; EDNS: version: 0, flags:; udp: 1232 ;; MSG SIZE rcvd: 504 ```
kerem commented 2026-03-16 00:49:00 +03:00
Author
Owner
Copy link

@t0m commented on GitHub (Feb 21, 2024):

I had a chance to dig in a bit more, and I believe what we're seeing is this bug from coredns (we're running within k8s): https://github.com/coredns/coredns/issues/5366.

The bug causes coredns to response with payloads >512 even if the client does not send an OPT RR. The client then fails to parse the response because it only has a buffer of 512 bytes. This explains why we didn't see the client fall back to tcp.

I think the docker embedded dns has a similar problem, which is why I was able to replicate the error in the rockylinux/rockylinux:8 container:

$ dig +noedns 512.size.dns.netmeister.org
...
;; MSG SIZE  rcvd: 1249

tcpdump shows no truncate flag/fallback to tcp as expected:

00:47:39.705836 IP (tos 0x0, ttl 64, id 45631, offset 0, flags [none], proto UDP (17), length 73)
    cd93a13fe924.58638 > 192.168.65.7.domain: 20601+ A? 512.size.dns.netmeister.org. (45)
00:47:39.712791 IP (tos 0x0, ttl 63, id 22724, offset 0, flags [DF], proto UDP (17), length 1277)
    192.168.65.7.domain > cd93a13fe924.58638: 20601 28/0/0 512.size.dns.netmeister.org. A ... (snip) ... (1249)
<!-- gh-comment-id:1955576097 --> @t0m commented on GitHub (Feb 21, 2024): I had a chance to dig in a bit more, and I believe what we're seeing is this bug from coredns (we're running within k8s): https://github.com/coredns/coredns/issues/5366. The bug causes coredns to response with payloads >512 even if the client does not send an OPT RR. The client then fails to parse the response because it only has a buffer of 512 bytes. This explains why we didn't see the client fall back to tcp. I think the docker embedded dns has a similar problem, which is why I was able to replicate the error in the `rockylinux/rockylinux:8` container: ``` $ dig +noedns 512.size.dns.netmeister.org ... ;; MSG SIZE rcvd: 1249 ``` tcpdump shows no truncate flag/fallback to tcp as expected: ``` 00:47:39.705836 IP (tos 0x0, ttl 64, id 45631, offset 0, flags [none], proto UDP (17), length 73) cd93a13fe924.58638 > 192.168.65.7.domain: 20601+ A? 512.size.dns.netmeister.org. (45) 00:47:39.712791 IP (tos 0x0, ttl 63, id 22724, offset 0, flags [DF], proto UDP (17), length 1277) 192.168.65.7.domain > cd93a13fe924.58638: 20601 28/0/0 512.size.dns.netmeister.org. A ... (snip) ... (1249) ```
kerem commented 2026-03-16 00:49:06 +03:00
Author
Owner
Copy link

@bluejekyll commented on GitHub (Feb 21, 2024):

Thanks for digging into that. I'm open to solutions here, which I suppose could be to not enforce the limit, but that feels wrong to me.

<!-- gh-comment-id:1955584670 --> @bluejekyll commented on GitHub (Feb 21, 2024): Thanks for digging into that. I'm open to solutions here, which I suppose could be to not enforce the limit, but that feels wrong to me.
kerem commented 2026-03-16 00:49:11 +03:00
Author
Owner
Copy link

@t0m commented on GitHub (Feb 27, 2024):

Thanks for your help. For what it's worth, I think you're right to continue enforcing the limit and stick to the spec.

<!-- gh-comment-id:1967086287 --> @t0m commented on GitHub (Feb 27, 2024): Thanks for your help. For what it's worth, I think you're right to continue enforcing the limit and stick to the spec.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
release/0.26
david/conformance-dnssec-negative-tests
query-api
opt-types
cname-nsec
no-cname-recursion
conformance-min-ttl
dname-base
drop-message-request
no-error-queries
cpu-sig0-rm-message-sig_dev
cpu-tsig-test-update_dev
windows-config
dnssec-net
release/0.25
opp-enc-persist
integration-test
cpu-tidying-recursor-opts_dev
happy-eyeballs
david/authoritative-zone-storage-trait
dnssec-ad
no-authority
release/0.24
pvdrz/remove-top-file
pvdrz/h3-handshake-timeout
pvdrz/quic-handshake-timeout
nxdomain-for-recursor
ja-test-merque-queue
ja-fix-ci-again
sz-add-ede-tests
sz-test-tc-bit-with-large-response
sz-fix-tokio-dependency
gh-2275-test-rrsig-signature
refactor-sign-zone-file
fix-1.79-cleanliness
update-nightly-hash
release/0.23
gh-pages
use-just-for-server-toml
release/0.22
revert-1874-cpu-zone-parse-default-class
disable-bind-compatibility-tests
disable-test_tls_client_stream_ipv4
update-native-tls-0.2.11
recursor-tests
fix-clippy-self
release/0.20
saethlin-fix-rdata-zero
release/0.19
flat_name
drop_unused_futures
release/0.18
release-r0.12-cs0.17
release/r0.12-cs0.17
trust-dns-book
r0.10
test-connections-not-dropped
fix_exec_status_on_rs_files
release-0.9
add-mutex-to-integration-tests
0.8_release
bfry/dns-crypt
v0.26.0
v0.26.0-beta.4
v0.26.0-beta.3
v0.26.0-beta.2
v0.26.0-beta.1
v0.26.0-alpha.1
v0.25.2
v0.25.1
v0.25.0
v0.24.4
v0.24.3
v0.25.0-alpha.5
v0.24.2
v0.25.0-alpha.4
v0.25.0-alpha.3
v0.25.0-alpha.2
v0.25.0-alpha.1
v0.24.1
v0.23.2
v0.24.0
v0.23.1
v0.23.0
v0.23.0-alpha.5
v0.23.0-alpha.4
v0.23.0-alpha.3
v0.22.1
v0.23.0-alpha.2
v0.23.0-alpha.1
v0.22.0
v0.21.2
v0.21.1
v0.21.0
v0.21.0-alpha.5
v0.20.4
v0.21.0-alpha.4
v0.21.0-alpha.3
v0.21.0-alpha.2
v0.21.0-alpha.1
v0.20.3
v0.20.2
v0.20.1
v0.19.7
v0.20.0
0.19.6
v0.20.0-alpha.3
v0.20.0-alpha.2
v0.20.0-alpha.1
0.19.5
0.19.4
0.19.3
0.19.0
0.18.1
0.18
0.18.0.alpha.2
r0.12_cs0.17
r0.11.1
cs0.16.1
r0.11
cs0.16
r0.10.1
r0.10.0
cs0.15.0
r0.9.1
v0.14.0
r0.9.0
r0.8.1
r0.8.0
v0.13.0
r0.7.0
c0.12.0
r0.6.0
r0.5.0
resolver.0.4.0
0.11.0
0.10.5
0.10.4
0.10.3
0.10.2
0.10.1
0.10.0
0.9.3
0.9.2
0.9.1
0.9.0
0.8.1
0.8.0
0.7.3
0.7.2
0.7.1
0.7.0
0.6.0
0.5.3
0.5.1
0.5.0
0.4.0
0.3.1
0.3.0
0.2.1
0.2.0
0.1.0
Labels
Clear labels   
blocked

   
breaking-change

   
bug

   
bug:critical

   
bug:tests

   
cleanup

   
compliance

   
compliance

   
compliance

   
crate:all

   
crate:client

   
crate:native-tls

   
crate:proto

   
crate:recursor

   
crate:resolver

   
crate:resolver

   
crate:rustls

   
crate:server

   
crate:util

   
dependencies

   
docs

   
duplicate

   
easy

   
easy

   
enhance

   
enhance

   
enhance

   
feature:dns-over-https

   
feature:dns-over-quic

   
feature:dns-over-tls

   
feature:dnsssec

   
feature:global_lb

   
feature:mdns

   
feature:tsig

   
features:edns

   
has workaround

   
ops

   
perf

   
platform:WASM

   
platform:android

   
platform:fuchsia

   
platform:linux

   
platform:macos

   
platform:windows

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
test

   
tools

   
tools

   
trust

   
unclear

   
wontfix
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/hickory-dns#900
No description provided.