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 #2228] hickory-resolver retries NXDOMAINs over TCP if using `try_tcp_on_error` #930

New issue

Closed

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

kerem commented

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

Owner

Originally created by @x86pup on GitHub (Jun 1, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2228

Describe the bug
hickory-resolver seems to consider NXDOMAINs (non-existent domains) errors that qualify to be retried over TCP, but NXDOMAINs are not "errors" in the sense that the query failed over UDP and needs to be retried over TCP, somehow expecting a different response.

The codepath that this seems to hit on is: https://github.com/hickory-dns/hickory-dns/blob/main/crates/resolver/src/name_server/name_server_pool.rs#L267-L270 when using try_tcp_on_error

To Reproduce
Steps to reproduce the behavior:

Enable try_tcp_on_error with hickory-resolver and debug logs enabled
Make a DNS query with hickory-resolver to a domain that returns NXDOMAIN such as awawa.google.com
See in logs that hickory_resolver says hickory_resolver::name_server::name_server_pool: error from UDP, retrying over TCP: no record found for Query { name: Name("awawa.google.com."), query_type: A, query_class: IN } which indicates that the domain has no record (NXDOMAIN) but hickory_resolver decides to retry over TCP anyways even though the query was successful

The same domain when queried with dig:

$ dig awawa.google.com                                                                                                                                                                                                                                               130 ↵  

; <<>> DiG 9.18.27 <<>> awawa.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52420
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;awawa.google.com.		IN	A

;; AUTHORITY SECTION:
google.com.		500	IN	SOA	ns1.google.com. dns-admin.google.com. 638805651 900 900 1800 60

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Jun 01 06:24:06 UTC 2024
;; MSG SIZE  rcvd: 95

Expected behavior
Domains such as awawa.google.com that return NXDOMAIN do not get retried over TCP.

System:

OS: any
Architecture: any
Version any
rustc version: any

Version:
Crate: resolver
Version: v0.24.1

Additional context
If this behaviour is truly intended (with a very thorough explanation why, but I don't see any obvious reason why this is intended either way), it would be preferable if this is behind a config option.

My crate is a Matrix homeserver, and "dead" servers over federation that were previously Matrix homeservers but no longer are homeservers can return NXDOMAIN because the owner deleted the DNS records.

There is very little to no value retrying the query over TCP as this is almost guaranteed to not be a false negative. Even then, retrying over TCP will definitely not get a successful or better response. So not having to waste queries on TCP would save resources. This is especially noticeable when apart of Matrix delegation/destination resolution, we have to query multiple DNS records. And this behaviour is just amplifying the amount of DNS queries we make for 1 single server where there could be upwards of hundreds of remote servers in a single Matrix room.

If needed, here's my crate's hickory-resolver config: github.com/girlbossceo/conduwuit@f4cfc77a57/src/service/globals/resolver.rs (L44-L82)

Tracing debug logs from my crate from hickory_resolver

2024-06-01T06:12:24.991556Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer::dns_handle: querying: awawa.google.com A
2024-06-01T06:12:24.991609Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("awawa.google.com"), query_type: A, query_class: IN }]
2024-06-01T06:12:24.991637Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server: existing connection: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
2024-06-01T06:12:24.991651Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("awawa.google.com"), query_type: A, query_class: IN }]
2024-06-01T06:12:24.991670Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer::dns_handle: querying: awawa.google.com AAAA
2024-06-01T06:12:24.991680Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("awawa.google.com"), query_type: AAAA, query_class: IN }]
2024-06-01T06:12:24.991691Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server: existing connection: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
2024-06-01T06:12:24.991698Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("awawa.google.com"), query_type: AAAA, query_class: IN }]
2024-06-01T06:12:24.991740Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 23768:QUERY:RD:NoError:QUERY:0/0/0
; query
;; awawa.google.com. IN A
2024-06-01T06:12:24.991757Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 19273:QUERY:RD:NoError:QUERY:0/0/0
; query
;; awawa.google.com. IN AAAA
2024-06-01T06:12:24.991843Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::udp::udp_stream: created socket successfully
2024-06-01T06:12:24.991952Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::udp::udp_stream: created socket successfully
2024-06-01T06:12:24.992301Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::udp::udp_client_stream: received message id: 23768
2024-06-01T06:12:24.992393Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::error: Response:; header 23768:RESPONSE:RD,RA:NXDomain:QUERY:0/1/0
; query
;; awawa.google.com. IN A
; answers 0
; nameservers 1
google.com. 1092 IN SOA ns1.google.com. dns-admin.google.com. 638805651 900 900 1800 60
; additionals 0
2024-06-01T06:12:24.992441Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server_pool: error from UDP, retrying over TCP: no record found for Query { name: Name("awawa.google.com."), query_type: A, query_class: IN }
2024-06-01T06:12:24.992463Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server: existing connection: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Tcp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
2024-06-01T06:12:24.992477Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("awawa.google.com"), query_type: A, query_class: IN }]
2024-06-01T06:12:24.992488Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer: unable to enqueue message
2024-06-01T06:12:24.992498Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server: name_server connection failure: proto error: resource too busy
2024-06-01T06:12:25.002075Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::udp::udp_client_stream: received message id: 19273
2024-06-01T06:12:25.002151Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::error: Response:; header 19273:RESPONSE:RD,RA:NXDomain:QUERY:0/1/0
; query
;; awawa.google.com. IN AAAA
; answers 0
; nameservers 1
google.com. 1200 IN SOA ns1.google.com. dns-admin.google.com. 638842609 900 900 1800 60
; additionals 0
2024-06-01T06:12:25.002184Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server_pool: error from UDP, retrying over TCP: no record found for Query { name: Name("awawa.google.com."), query_type: AAAA, query_class: IN }
2024-06-01T06:12:25.002205Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server: reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Tcp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
2024-06-01T06:12:25.002425Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::tcp::tcp_stream: TCP connection established to: 127.0.0.1:53
2024-06-01T06:12:25.002453Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("awawa.google.com"), query_type: AAAA, query_class: IN }]
2024-06-01T06:12:25.002496Z DEBUG hickory_proto::xfer::dns_multiplexer: sending message id=2413
2024-06-01T06:12:25.002508Z DEBUG hickory_proto::xfer::dns_multiplexer: final message: ; header 2413:QUERY:RD:NoError:QUERY:0/0/0
; query
;; awawa.google.com. IN AAAA
2024-06-01T06:12:25.002521Z DEBUG hickory_proto::tcp::tcp_stream: sending message len: 34 to: 127.0.0.1:53
2024-06-01T06:12:25.002737Z DEBUG hickory_proto::tcp::tcp_stream: in ReadTcpState::LenBytes: 0
2024-06-01T06:12:25.002751Z DEBUG hickory_proto::tcp::tcp_stream: got length: 84
2024-06-01T06:12:25.002758Z DEBUG hickory_proto::tcp::tcp_stream: move ReadTcpState::Bytes: 84
2024-06-01T06:12:25.002765Z DEBUG hickory_proto::tcp::tcp_stream: in ReadTcpState::Bytes: 84
2024-06-01T06:12:25.002770Z DEBUG hickory_proto::tcp::tcp_stream: reset ReadTcpState::LenBytes: 0
2024-06-01T06:12:25.002775Z DEBUG hickory_proto::tcp::tcp_stream: returning bytes
2024-06-01T06:12:25.002779Z DEBUG hickory_proto::tcp::tcp_stream: returning buffer
2024-06-01T06:12:25.002837Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::error: Response:; header 2413:RESPONSE:RD,RA:NXDomain:QUERY:0/1/0
; query
;; awawa.google.com. IN AAAA
; answers 0
; nameservers 1
google.com. 1200 IN SOA ns1.google.com. dns-admin.google.com. 638842609 900 900 1800 60
; additionals 0
2024-06-01T06:12:25.014052Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server: existing connection: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Tcp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None }
2024-06-01T06:12:25.014102Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("awawa.google.com"), query_type: A, query_class: IN }]
2024-06-01T06:12:25.014158Z DEBUG hickory_proto::xfer: ignoring send error on disconnected stream
2024-06-01T06:12:25.014183Z DEBUG hickory_proto::xfer::dns_multiplexer: sending message id=63521
2024-06-01T06:12:25.014192Z DEBUG hickory_proto::xfer::dns_multiplexer: final message: ; header 63521:QUERY:RD:NoError:QUERY:0/0/0
; query
;; awawa.google.com. IN A
2024-06-01T06:12:25.014207Z DEBUG hickory_proto::tcp::tcp_stream: sending message len: 34 to: 127.0.0.1:53
2024-06-01T06:12:25.055256Z DEBUG hickory_proto::tcp::tcp_stream: in ReadTcpState::LenBytes: 0
2024-06-01T06:12:25.055302Z DEBUG hickory_proto::tcp::tcp_stream: got length: 84
2024-06-01T06:12:25.055315Z DEBUG hickory_proto::tcp::tcp_stream: move ReadTcpState::Bytes: 84
2024-06-01T06:12:25.055324Z DEBUG hickory_proto::tcp::tcp_stream: in ReadTcpState::Bytes: 84
2024-06-01T06:12:25.055330Z DEBUG hickory_proto::tcp::tcp_stream: reset ReadTcpState::LenBytes: 0
2024-06-01T06:12:25.055335Z DEBUG hickory_proto::tcp::tcp_stream: returning bytes
2024-06-01T06:12:25.055341Z DEBUG hickory_proto::tcp::tcp_stream: returning buffer
2024-06-01T06:12:25.055481Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::error: Response:; header 63521:RESPONSE:RD,RA:NXDomain:QUERY:0/1/0
; query
;; awawa.google.com. IN A
; answers 0
; nameservers 1
google.com. 1200 IN SOA ns1.google.com. dns-admin.google.com. 638842609 900 900 1800 60
; additionals 0
2024-06-01T06:12:25.055587Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::lookup_ip: both of ipv4 or ipv6 lookup failed in ipv4_and_ipv6 strategy e1: no record found for Query { name: Name("awawa.google.com."), query_type: AAAA, query_class: IN }, e2: no record found for Query { name: Name("awawa.google.com."), query_type: A, query_class: IN }

Originally created by @x86pup on GitHub (Jun 1, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2228 **Describe the bug** hickory-resolver seems to consider NXDOMAINs (**non-existent** domains) errors that qualify to be retried over TCP, but NXDOMAINs are not "errors" in the sense that the query failed over UDP and needs to be retried over TCP, somehow expecting a different response. The codepath that this seems to hit on is: https://github.com/hickory-dns/hickory-dns/blob/main/crates/resolver/src/name_server/name_server_pool.rs#L267-L270 when using `try_tcp_on_error` **To Reproduce** Steps to reproduce the behavior: - Enable `try_tcp_on_error` with hickory-resolver and debug logs enabled - Make a DNS query with hickory-resolver to a domain that returns NXDOMAIN such as `awawa.google.com` - See in logs that hickory_resolver says `hickory_resolver::name_server::name_server_pool: error from UDP, retrying over TCP: no record found for Query { name: Name("awawa.google.com."), query_type: A, query_class: IN }` which indicates that the domain has no record (NXDOMAIN) but hickory_resolver decides to retry over TCP anyways even though the query was successful The same domain when queried with `dig`: ``` $ dig awawa.google.com 130 ↵ ; <<>> DiG 9.18.27 <<>> awawa.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52420 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;awawa.google.com. IN A ;; AUTHORITY SECTION: google.com. 500 IN SOA ns1.google.com. dns-admin.google.com. 638805651 900 900 1800 60 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Sat Jun 01 06:24:06 UTC 2024 ;; MSG SIZE rcvd: 95 ``` **Expected behavior** Domains such as `awawa.google.com` that return `NXDOMAIN` do not get retried over TCP. **System:** - OS: any - Architecture: any - Version any - rustc version: any **Version:** Crate: resolver Version: v0.24.1 **Additional context** If this behaviour is truly intended (with a very thorough explanation why, but I don't see any obvious reason why this is intended either way), it would be preferable if this is behind a config option. My crate is a Matrix homeserver, and "dead" servers over federation that were previously Matrix homeservers but no longer are homeservers can return NXDOMAIN because the owner deleted the DNS records. There is very little to no value retrying the query over TCP as this is almost guaranteed to not be a false negative. Even then, retrying over TCP will definitely not get a successful or better response. So not having to waste queries on TCP would save resources. This is especially noticeable when apart of Matrix delegation/destination resolution, we have to query multiple DNS records. And this behaviour is just amplifying the amount of DNS queries we make for 1 single server where there could be upwards of hundreds of remote servers in a single Matrix room. If needed, here's my crate's hickory-resolver config: https://github.com/girlbossceo/conduwuit/blob/f4cfc77a577e0dfd152878830294c8eb3fe47861/src/service/globals/resolver.rs#L44-L82 <details> <summary>Tracing debug logs from my crate from hickory_resolver</summary> ``` 2024-06-01T06:12:24.991556Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer::dns_handle: querying: awawa.google.com A 2024-06-01T06:12:24.991609Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("awawa.google.com"), query_type: A, query_class: IN }] 2024-06-01T06:12:24.991637Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server: existing connection: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None } 2024-06-01T06:12:24.991651Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("awawa.google.com"), query_type: A, query_class: IN }] 2024-06-01T06:12:24.991670Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer::dns_handle: querying: awawa.google.com AAAA 2024-06-01T06:12:24.991680Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server_pool: sending request: [Query { name: Name("awawa.google.com"), query_type: AAAA, query_class: IN }] 2024-06-01T06:12:24.991691Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server: existing connection: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Udp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None } 2024-06-01T06:12:24.991698Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("awawa.google.com"), query_type: AAAA, query_class: IN }] 2024-06-01T06:12:24.991740Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 23768:QUERY:RD:NoError:QUERY:0/0/0 ; query ;; awawa.google.com. IN A 2024-06-01T06:12:24.991757Z DEBUG hickory_proto::udp::udp_client_stream: final message: ; header 19273:QUERY:RD:NoError:QUERY:0/0/0 ; query ;; awawa.google.com. IN AAAA 2024-06-01T06:12:24.991843Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::udp::udp_stream: created socket successfully 2024-06-01T06:12:24.991952Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::udp::udp_stream: created socket successfully 2024-06-01T06:12:24.992301Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::udp::udp_client_stream: received message id: 23768 2024-06-01T06:12:24.992393Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::error: Response:; header 23768:RESPONSE:RD,RA:NXDomain:QUERY:0/1/0 ; query ;; awawa.google.com. IN A ; answers 0 ; nameservers 1 google.com. 1092 IN SOA ns1.google.com. dns-admin.google.com. 638805651 900 900 1800 60 ; additionals 0 2024-06-01T06:12:24.992441Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server_pool: error from UDP, retrying over TCP: no record found for Query { name: Name("awawa.google.com."), query_type: A, query_class: IN } 2024-06-01T06:12:24.992463Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server: existing connection: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Tcp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None } 2024-06-01T06:12:24.992477Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("awawa.google.com"), query_type: A, query_class: IN }] 2024-06-01T06:12:24.992488Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer: unable to enqueue message 2024-06-01T06:12:24.992498Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server: name_server connection failure: proto error: resource too busy 2024-06-01T06:12:25.002075Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::udp::udp_client_stream: received message id: 19273 2024-06-01T06:12:25.002151Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::error: Response:; header 19273:RESPONSE:RD,RA:NXDomain:QUERY:0/1/0 ; query ;; awawa.google.com. IN AAAA ; answers 0 ; nameservers 1 google.com. 1200 IN SOA ns1.google.com. dns-admin.google.com. 638842609 900 900 1800 60 ; additionals 0 2024-06-01T06:12:25.002184Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server_pool: error from UDP, retrying over TCP: no record found for Query { name: Name("awawa.google.com."), query_type: AAAA, query_class: IN } 2024-06-01T06:12:25.002205Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server: reconnecting: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Tcp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None } 2024-06-01T06:12:25.002425Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::tcp::tcp_stream: TCP connection established to: 127.0.0.1:53 2024-06-01T06:12:25.002453Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("awawa.google.com"), query_type: AAAA, query_class: IN }] 2024-06-01T06:12:25.002496Z DEBUG hickory_proto::xfer::dns_multiplexer: sending message id=2413 2024-06-01T06:12:25.002508Z DEBUG hickory_proto::xfer::dns_multiplexer: final message: ; header 2413:QUERY:RD:NoError:QUERY:0/0/0 ; query ;; awawa.google.com. IN AAAA 2024-06-01T06:12:25.002521Z DEBUG hickory_proto::tcp::tcp_stream: sending message len: 34 to: 127.0.0.1:53 2024-06-01T06:12:25.002737Z DEBUG hickory_proto::tcp::tcp_stream: in ReadTcpState::LenBytes: 0 2024-06-01T06:12:25.002751Z DEBUG hickory_proto::tcp::tcp_stream: got length: 84 2024-06-01T06:12:25.002758Z DEBUG hickory_proto::tcp::tcp_stream: move ReadTcpState::Bytes: 84 2024-06-01T06:12:25.002765Z DEBUG hickory_proto::tcp::tcp_stream: in ReadTcpState::Bytes: 84 2024-06-01T06:12:25.002770Z DEBUG hickory_proto::tcp::tcp_stream: reset ReadTcpState::LenBytes: 0 2024-06-01T06:12:25.002775Z DEBUG hickory_proto::tcp::tcp_stream: returning bytes 2024-06-01T06:12:25.002779Z DEBUG hickory_proto::tcp::tcp_stream: returning buffer 2024-06-01T06:12:25.002837Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::error: Response:; header 2413:RESPONSE:RD,RA:NXDomain:QUERY:0/1/0 ; query ;; awawa.google.com. IN AAAA ; answers 0 ; nameservers 1 google.com. 1200 IN SOA ns1.google.com. dns-admin.google.com. 638842609 900 900 1800 60 ; additionals 0 2024-06-01T06:12:25.014052Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::name_server::name_server: existing connection: NameServerConfig { socket_addr: 127.0.0.1:53, protocol: Tcp, tls_dns_name: None, trust_negative_responses: false, bind_addr: None } 2024-06-01T06:12:25.014102Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_proto::xfer: enqueueing message:QUERY:[Query { name: Name("awawa.google.com"), query_type: A, query_class: IN }] 2024-06-01T06:12:25.014158Z DEBUG hickory_proto::xfer: ignoring send error on disconnected stream 2024-06-01T06:12:25.014183Z DEBUG hickory_proto::xfer::dns_multiplexer: sending message id=63521 2024-06-01T06:12:25.014192Z DEBUG hickory_proto::xfer::dns_multiplexer: final message: ; header 63521:QUERY:RD:NoError:QUERY:0/0/0 ; query ;; awawa.google.com. IN A 2024-06-01T06:12:25.014207Z DEBUG hickory_proto::tcp::tcp_stream: sending message len: 34 to: 127.0.0.1:53 2024-06-01T06:12:25.055256Z DEBUG hickory_proto::tcp::tcp_stream: in ReadTcpState::LenBytes: 0 2024-06-01T06:12:25.055302Z DEBUG hickory_proto::tcp::tcp_stream: got length: 84 2024-06-01T06:12:25.055315Z DEBUG hickory_proto::tcp::tcp_stream: move ReadTcpState::Bytes: 84 2024-06-01T06:12:25.055324Z DEBUG hickory_proto::tcp::tcp_stream: in ReadTcpState::Bytes: 84 2024-06-01T06:12:25.055330Z DEBUG hickory_proto::tcp::tcp_stream: reset ReadTcpState::LenBytes: 0 2024-06-01T06:12:25.055335Z DEBUG hickory_proto::tcp::tcp_stream: returning bytes 2024-06-01T06:12:25.055341Z DEBUG hickory_proto::tcp::tcp_stream: returning buffer 2024-06-01T06:12:25.055481Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::error: Response:; header 63521:RESPONSE:RD,RA:NXDomain:QUERY:0/1/0 ; query ;; awawa.google.com. IN A ; answers 0 ; nameservers 1 google.com. 1200 IN SOA ns1.google.com. dns-admin.google.com. 638842609 900 900 1800 60 ; additionals 0 2024-06-01T06:12:25.055587Z DEBUG request{dest="awawa.google.com"}:send:resolve:well-known:ip: hickory_resolver::lookup_ip: both of ipv4 or ipv6 lookup failed in ipv4_and_ipv6 strategy e1: no record found for Query { name: Name("awawa.google.com."), query_type: AAAA, query_class: IN }, e2: no record found for Query { name: Name("awawa.google.com."), query_type: A, query_class: IN } ``` </details>

kerem closed this issue

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

kerem commented

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

Author

Owner

@bluejekyll commented on GitHub (Jun 2, 2024):

Do you get the behavior you want when you disable retry over TCP?

@bluejekyll commented on GitHub (Jun 2, 2024): Do you get the behavior you want when you disable retry over TCP?

kerem commented

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

Author

Owner

@bluejekyll commented on GitHub (Jun 2, 2024):

I do wonder if after a few of these revisions if this config value isn’t actually doing what should be the expected behavior. That is, we retry tcp no matter what in certain cases right now.

it seems like this should really say if e.is_no_connections() || (opts.try_tcp_on_error && e.is_io())

as I think you’re right that DNS failures shouldn’t the retried. I’d have to look for past issues in this area to understand how we ended up here. It’s possible that there are some odd configurations in the wild where local DNS servers are improperly responding to queries, though that really shouldn’t be handled in this location.

@bluejekyll commented on GitHub (Jun 2, 2024): I do wonder if after a few of these revisions if this config value isn’t actually doing what should be the expected behavior. That is, we retry tcp no matter what in certain cases right now. it seems like this should really say `if e.is_no_connections() || (opts.try_tcp_on_error && e.is_io())` as I think you’re right that DNS failures shouldn’t the retried. I’d have to look for past issues in this area to understand how we ended up here. It’s possible that there are some odd configurations in the wild where local DNS servers are improperly responding to queries, though that really shouldn’t be handled in this location.

kerem commented

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

Author

Owner

@x86pup commented on GitHub (Jun 2, 2024):

Do you get the behavior you want when you disable retry over TCP?

Not really because it's expected for us to support TCP fallback. My crate has retry over TCP enabled for everyone by default with an optional config option for someone to toggle it off.

SRV queries on Matrix can have large responses which only TCP fallback can provide, and if a user has exhausted UDP resources then retrying on TCP is not a bad default to have. We just don't want it to be amplifying unnecessary amounts of DNS queries by retrying on NXDOMAIN.

@x86pup commented on GitHub (Jun 2, 2024): > Do you get the behavior you want when you disable retry over TCP? Not really because it's expected for us to support TCP fallback. My crate has retry over TCP enabled for everyone by default with an optional config option for someone to toggle it off. SRV queries on Matrix can have large responses which only TCP fallback can provide, and if a user has exhausted UDP resources then retrying on TCP is not a bad default to have. We just don't want it to be amplifying unnecessary amounts of DNS queries by retrying on NXDOMAIN.

kerem commented

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

Author

Owner

@x86pup commented on GitHub (Jun 2, 2024):

it seems like this should really say if e.is_no_connections() || (opts.try_tcp_on_error && e.is_io())

I don't know all the cases where it makes sense to retry TCP on error except for too large DNS responses (e.g. SRV records), and UDP I/O error yeah, but on the surface this makes sense to me.

@x86pup commented on GitHub (Jun 2, 2024): > it seems like this should really say `if e.is_no_connections() || (opts.try_tcp_on_error && e.is_io())` I don't know all the cases where it makes sense to retry TCP on error except for too large DNS responses (e.g. SRV records), and UDP I/O error yeah, but on the surface this makes sense to me.

kerem referenced this issue

2026-03-16 02:26:01 +03:00

[PR #930] [CLOSED] Bump async-trait from 0.1.18 to 0.1.19 #1798