[GH-ISSUE #2256] Long TXT records dropped from response #938

New issue

Closed

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

kerem commented

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

Owner

Originally created by @JarrahG on GitHub (Jun 24, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2256

Describe the bug
When querying for TXT records, if one of the records is abnormally long it is not returned in the result set (though other responses are). The response is sent (it shows up in pcaps) and packets are not being fragmented.

To Reproduce
Steps to reproduce the behavior:

Sent a TXT request to a server with long responses. I've setup a-s.undef.tools for testing, feel free to use it.
See the "normal sized record" show up, but not the second entry with 184 a's
Compare with the output of dig.

Expected behavior
I expected all results to be returned. See below dig output.

;; ANSWER SECTION:
a-s.undef.tools.	259	IN	TXT	"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
a-s.undef.tools.	259	IN	TXT	"normal sized record"

System:

OS: Linux
Architecture: x86_64
Version: Fedora 40
rustc version: 1.79.0

Version:
Crate: Resolver
Version: 0.24.1

Additional context
In real-world usage, SPF records commonly hit this limit, this is where I hit it.
Resolver opts just in case I missed something there:

ResolverOpts {
    ndots: 1,
    timeout: 5s,
    attempts: 2,
    rotate: true,
    check_names: true,
    edns0: true,
    validate: false,
    ip_strategy: Ipv4thenIpv6,
    cache_size: 0,
    use_hosts_file: true,
    positive_min_ttl: None,
    negative_min_ttl: None,
    positive_max_ttl: None,
    negative_max_ttl: None,
    num_concurrent_reqs: 1,
    preserve_intermediates: true,
    try_tcp_on_error: true,
    server_ordering_strategy: QueryStatistics,
    recursion_desired: true,
    authentic_data: false,
    shuffle_dns_servers: false,
}

Thanks!

Originally created by @JarrahG on GitHub (Jun 24, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2256 **Describe the bug** When querying for TXT records, if one of the records is abnormally long it is not returned in the result set (though other responses are). The response is sent (it shows up in pcaps) and packets are not being fragmented. **To Reproduce** Steps to reproduce the behavior: 1. Sent a TXT request to a server with long responses. I've setup a-s.undef.tools for testing, feel free to use it. 2. See the "normal sized record" show up, but not the second entry with 184 a's 3. Compare with the output of `dig`. **Expected behavior** I expected all results to be returned. See below `dig` output. ``` ;; ANSWER SECTION: a-s.undef.tools. 259 IN TXT "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" a-s.undef.tools. 259 IN TXT "normal sized record" ``` **System:** - OS: Linux - Architecture: x86_64 - Version: Fedora 40 - rustc version: 1.79.0 **Version:** Crate: Resolver Version: 0.24.1 **Additional context** In real-world usage, SPF records commonly hit this limit, this is where I hit it. Resolver opts just in case I missed something there: ``` ResolverOpts { ndots: 1, timeout: 5s, attempts: 2, rotate: true, check_names: true, edns0: true, validate: false, ip_strategy: Ipv4thenIpv6, cache_size: 0, use_hosts_file: true, positive_min_ttl: None, negative_min_ttl: None, positive_max_ttl: None, negative_max_ttl: None, num_concurrent_reqs: 1, preserve_intermediates: true, try_tcp_on_error: true, server_ordering_strategy: QueryStatistics, recursion_desired: true, authentic_data: false, shuffle_dns_servers: false, } ``` Thanks!

kerem closed this issue

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

kerem commented

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

Author

Owner

@djc commented on GitHub (Jun 24, 2024):

Is this being received over UDP or TCP? I probably won't have time to dig into this -- would need someone to figure out what layer of the code is dropping the response here so we can see why it is doing so.

If this is over UDP, try adding some debugging to send_serial_message_inner() in udp_client_stream.rs to see how this is getting parsed? If TCP, not quite sure where its SerialMessages get converted to Message right now...

@djc commented on GitHub (Jun 24, 2024): Is this being received over UDP or TCP? I probably won't have time to dig into this -- would need someone to figure out what layer of the code is dropping the response here so we can see why it is doing so. If this is over UDP, try adding some debugging to `send_serial_message_inner()` in `udp_client_stream.rs` to see how this is getting parsed? If TCP, not quite sure where its `SerialMessage`s get converted to `Message` right now...

kerem commented

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

Author

Owner

@JarrahG commented on GitHub (Jun 24, 2024):

It was UDP. I already had a poke around the TXT record parsing code before posting, but I'll try again in the next few days, thanks for the pointer.

@JarrahG commented on GitHub (Jun 24, 2024): It was UDP. I already had a poke around the TXT record parsing code before posting, but I'll try again in the next few days, thanks for the pointer.

kerem commented

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

Author

Owner

@JarrahG commented on GitHub (Jun 25, 2024):

Sorry for the noise, it turns out that that particular request had a non-character byte attached to the front of it, when my application attempted to stringify the response it was silently dropping that entry.

Not sure how my test on a different server with another long string also managed to trigger that bug, but either way, it's not your bug!

Thanks again.

@JarrahG commented on GitHub (Jun 25, 2024): Sorry for the noise, it turns out that that particular request had a non-character byte attached to the front of it, when my application attempted to stringify the response it was silently dropping that entry. Not sure how my test on a different server with another long string also managed to trigger that bug, but either way, it's not your bug! Thanks again.

kerem referenced this issue

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

[PR #938] [CLOSED] Resolver #1803