Bitping + DNSCrypt

[engageub]

Diagnostic Output

Please run the following commands and share the output:

/proxy-dns # ./dnscrypt-proxy -version
2.1.16

/proxy-dns # ./dnscrypt-proxy --config dns-config.toml -check

/proxy-dns # ./dnscrypt-proxy --config dns-config.toml -resolve example.com
Resolving [example.com] using 127.0.0.1 port 53

Resolver      : 172.253.214.124

Canonical name: example.com.

IPv4 addresses: 172.66.147.243, 104.20.23.154
IPv6 addresses: 2606:4700:10::ac42:93f3, 2606:4700:10::6814:179a

Name servers  : elliott.ns.cloudflare.com., hera.ns.cloudflare.com.
DNSSEC signed : yes
Mail servers  : 1 mail server found

HTTPS alias   : -
HTTPS info    : [alpn]=[h2], [ipv4hint]=[104.20.23.154,172.66.147.243], [ipv6hint]=[2606:4700:10::6814:179a,2606:4700:10::ac42:93f3]

Host info     : -
TXT records   : v=spf1 -all, _k2n1y4vw3qtb4skdx9e7dxt97qrmmq9

DNS Configuration

/proxy-dns # cat dns-config.toml

listen_addresses = ['127.0.0.1:53']
server_names = ['google1', 'google2', 'cloudflare1', 'cloudflare2', 'quad9']
log_level = 6
cache = true
cache_size = 4096
cache_min_ttl = 2400
cache_max_ttl = 86400
max_clients = 500

[static]
  [static.google1]
  stamp = 'sdns://AgcAAAAAAAAABzguOC40LjQABzguOC40LjQKL2Rucy1xdWVyeQ'

  [static.google2]
  stamp = 'sdns://AgcAAAAAAAAABzguOC44LjgABzguOC44LjgKL2Rucy1xdWVyeQ'

  [static.cloudflare1]
  stamp = 'sdns://AgcAAAAAAAAABzEuMS4xLjEABzEuMS4xLjEKL2Rucy1xdWVyeQ'

  [static.cloudflare2]
  stamp = 'sdns://AgcAAAAAAAAABzEuMC4wLjEABzEuMC4wLjEKL2Rucy1xdWVyeQ'

  [static.quad9]
  stamp = 'sdns://AgcAAAAAAAAABzkuOS45LjkABzkuOS45LjkKL2Rucy1xdWVyeQ'

• I have reviewed the documentation and could not find an answer to this issue.

Description

When the Bitping application is used with DNSCrypt, Hickory DNS emits warning messages indicating DNS message ID mismatches. These warnings do not occur when:

• Bitping uses the Hickory DNS client directly.
• DNS queries are sent over a direct UDP connection.
• DNSCrypt is not involved in the DNS resolution path.

This suggests a possible issue in how DNS responses are being returned to the client when DNSCrypt is used as an intermediary resolver.

Although Bitping already uses Hickory DNS (as shown in the logs), the warnings only appear when DNS traffic is routed through DNSCrypt.

Bitping Logs

2026-07-08T05:15:22.293420Z  WARN hickory_proto::udp::udp_client_stream: expected message id: 64203 got: 25223, dropped
    at /builds/uptimesv/rust-monorepo/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/hickory-proto-0.24.4/src/udp/udp_client_stream.rs:356

2026-07-08T05:15:22.293543Z  WARN hickory_proto::udp::udp_client_stream: expected message id: 7649 got: 32464, dropped
    at /builds/uptimesv/rust-monorepo/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/hickory-proto-0.24.4/src/udp/udp_client_stream.rs:356

2026-07-08T05:15:22.293580Z  WARN hickory_proto::udp::udp_client_stream: expected message id: 3050 got: 1574, dropped
    at /builds/uptimesv/rust-monorepo/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/hickory-proto-0.24.4/src/udp/udp_client_stream.rs:356

When Does This Occur?

The issue occurs while running a Bitping node with DNS traffic redirected through DNSCrypt.

Where Does It Occur?

Bitping node application.

Steps to Reproduce

1. Download the Internet Income test branch:
   https://github.com/engageub/InternetIncome/tree/test

2. Update properties.conf:

   • Set USE_DNS_OVER_HTTPS=true
   • Set USE_DNSCRYPT=true
   • Set BITPING_EMAIL and BITPING_PASSWORD
   • Set USE_PROXIES=true
   • Set ENABLE_LOGS=true

3. Start the application:

   sudo bash internetIncome.sh --start

4. Monitor the Bitping Docker logs.

5. Observe the Hickory DNS warnings related to mismatched DNS message IDs.

Alternative Setup

Bitping can also be installed without Docker:

https://github.com/BitpingApp/Bitping-Node/blob/master/README.md

Expected Behavior

DNS responses returned through DNSCrypt should be handled in the same manner as responses received through direct UDP or standard Hickory DNS resolution, without generating message ID mismatch warnings.

Additional Context

The DNSCrypt proxy successfully resolves domains and passes health checks. The issue appears to be specific to the interaction between DNSCrypt and Hickory DNS, where Hickory receives responses containing unexpected DNS message IDs and subsequently drops them.

[jedisct1]

Thanks for the detailed report and the clean reproduction steps.

Short version: this is harmless. Nothing is being lost, and dnscrypt-proxy is not corrupting anything. It's a mismatch between how Hickory (the DNS library used by Bitping) reads UDP replies and how dnscrypt-proxy sends them.

Here's what's going on.

Every DNS query carries a small random number in its header, the transaction ID. The client uses it to match a reply to the question it asked. dnscrypt-proxy preserves that ID from end to end — the ID you send out is exactly the ID you get back. So the responses themselves are correct.

The friction is about ordering, not correctness.

Bitping/Hickory sends several queries at once over a single UDP socket and expects the replies to come back in the same order it asked. That assumption holds when you talk straight to a normal resolver over plain UDP.

dnscrypt-proxy doesn't work that way. It handles each query independently and in parallel, then sends each answer back the moment it's ready. Because some answers come from cache, some from a fast server, some from a slow one, some after a retry, they naturally come back in a different order than they were asked. Every reply is valid and has the right ID — they just don't arrive in the order Hickory was expecting.

So when Hickory is sitting there waiting for reply 64203 and reply 25223 shows up first, it logs "expected 64203, got 25223, dropped" and waits for the next datagram. The one it wanted arrives a moment later, and everything resolves fine. That's why you see the warnings but resolution still works and health checks pass. It's log noise, not a failure.

This is really a client-side expectation in Hickory (assuming replies come back in order on a shared socket). A couple of things on your side make the warnings go away:

• Point Bitping at dnscrypt-proxy over TCP instead of UDP, if it lets you.
• Or use a Hickory version/configuration that matches replies purely by ID rather than by arrival order (newer Hickory releases are generally better about this).

Nothing to fix on the dnscrypt-proxy side here — the answers are correct, just delivered as soon as each one is ready rather than strictly in request order.

[engageub]

Hi,

Thank you for the detailed update.

The script has been updated to support Hickory DNS. When USE_DNSCRYPT=false is configured, the system uses the Hickory DNS server instead of DNSCrypt.

Hickory DNS also enables caching by default, and the mismatched message IDs observed previously do not appear in the BitPing logs when Hickory DNS is used. The configuration is set up so that all DNS queries directed to UDP port 53 are forwarded to the DNS resolver server which uses TCP.

Since the mismatch messages are not occurring with Hickory DNS, it appears the issue may be related to how cached responses are handled. Would it be possible for cached responses to be returned using the same message ID as the original query?

Thank you.

[jedisct1]

Cached responses already do exactly that. On a cache hit, dnscrypt-proxy copies the incoming query's transaction ID onto the response before sending it back — the cache never invents or reuses an ID of its own. So the cache can't be the source of a mismatch.

In fact, no path in dnscrypt-proxy can hand you a response whose ID doesn't match the query you sent:

• Cache hits copy your query's ID onto the answer.
• Encrypted DNSCrypt responses carry your original ID inside the encrypted payload and come back untouched.
• DoH/ODoH strip the ID on the wire and then restore your original ID before replying.
• And there's an explicit check that rejects any upstream answer whose ID doesn't match the question — a wrong-ID packet is never forwarded to you in the first place.

So when Hickory reports "expected 64203, got 25223", the 25223 it received is a perfectly valid response with the correct ID for query 25223 — it's just not the query Hickory happened to be waiting on at that instant. That's the whole thing: every datagram is correct, they simply don't arrive in the order Hickory expects on its shared UDP socket.

The reason TCP makes it disappear is not that TCP fixes any ID. It's that over TCP each answer is framed and read one at a time, so ordering can't surprise the client. Over UDP, dnscrypt-proxy answers each query the moment it's ready, and Hickory's UDP path assumes replies come back in request order.

Nothing to change on the dnscrypt-proxy side here. The IDs are already preserved everywhere, cache included. Sticking with TCP, or a Hickory build that matches replies by ID rather than by arrival order, is the way to silence the warnings.

[jedisct1]

To close the loop on where the fix belongs: this is really something for Hickory to address, not dnscrypt-proxy.

DNS over UDP has never guaranteed that replies come back in the same order the queries went out. That's the entire reason each query carries a transaction ID — so a client can match a response to its question no matter what order they arrive in. Any caching resolver, forwarder, or load balancer is free to answer queries as soon as each one is ready, which means out of order. dnscrypt-proxy is behaving normally here; so would most resolvers.

The correct way to handle several queries on one shared UDP socket is to keep a small table of "ID → who's waiting for it" and hand each incoming datagram to the matching waiter by its ID. A datagram whose ID matches nothing outstanding is simply ignored. What should not happen is treating a valid answer for query 25223 as junk to be "dropped" just because query 64203 happened to be first in line. That part is a limitation in Hickory's UDP path — it appears to assume replies arrive in request order, which the protocol doesn't promise. It's also why talking straight to an upstream looks clean (one query, one reply, no chance to reorder) while anything that parallelizes or caches trips the warning.

Worth flagging upstream to Hickory as "match responses by transaction ID on a shared socket, and don't warn on non-matching datagrams" — a concrete, standards-backed request.

One broader note: Hickory is still a young, experimental project on a 0.x release line (0.26 at the time of writing). A pre-1.0 version number is the authors telling you the API and behavior aren't settled yet. I'd be cautious about relying on it for anything you actually depend on. This ordering assumption is a good example of the kind of rough edge you run into with a resolver that hasn't reached a stable release. Pointing your client at dnscrypt-proxy over TCP sidesteps it for now.

[engageub]

Hi,
Thanks for the response. I haven't looked directly at the codebase or internals, but according to the logs, here is exactly what's happening.

Thank you

[engageub]

Hi,

When cache = false is set in dns-config.toml, the errors no longer occur. This suggests that the issue may be related either to the IDs returned from cached responses or to a timing-related behavior.

If the problem is timing-related, would introducing a delay before returning cached responses help resolve the issue? If doing so resolves the issue, we can confirm that the root cause is related to timing rather than the IDs returned in cached responses.

Thank you.