[GH-ISSUE #1627] Regression when using Resolver::txt_lookup #713

New issue

Closed

opened 2026-03-15 23:56:27 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 23:56:27 +03:00

Owner

Originally created by @glts on GitHub (Feb 5, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1627

I have been using trust_dns_resolver::Resolver::txt_lookup successfully with version 0.20.4.

The same lookup now fails with version 0.21.0-alpha.4.

To reproduce:

use trust_dns_resolver::Resolver;

fn main() {
    let resolver = Resolver::default().unwrap();

    let name = "bmc.org";
    match resolver.txt_lookup(name) {
        Ok(lookup) => {
            for txt in lookup {
                eprintln!(
                    "<{:?}>",
                    txt.iter()
                        .map(|data| String::from_utf8_lossy(data))
                        .collect::<String>()
                );
            }
        }
        Err(e) => {
            eprintln!("error: {}", e);
        }
    }
}

Output with trust-dns-resolver 0.20.4:

<"docusign=5140f07f-9f9c-4561-8a94-e69761a38442">
<"OVrFqSjwZz9OshiM1LGcVWYjzhtYrg930HlRDNn43M3PFP0Vx3XSv2w0rNxzACUUtgmhp0iXx15yK18nnl0svg==">
<"ZOOM_verify_xJpoFs3nSDywDsvmMWygGg">
<"">
<"4FVu/Fi5/VTEsxj+08airJyjv1oKUMC6yFTlOfWCg3ol7HwVAu3lmZre+8UOrQXKpzgJ1vbe/zRUepCN7cnFJg==">
<"v*spf1 include:servers.mcsv.net ?all">
<"v=spf1 a mx include:us._netblocks.mimecast.com include:spf1.service.formassembly.com -all">
<"apple-domain-verification=UnyCDv1Ozqb0yjW7">
<"docusign=2d29c1de-6a95-474d-ada4-3b7c3ee40fa8">

Output with trust-dns-resolver 0.21.0-alpha.4:

error: no record found for name: bmc.org. type: TXT class: IN

I can reproduce this on two separate hosts (home and VPS).

Originally created by @glts on GitHub (Feb 5, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1627 I have been using `trust_dns_resolver::Resolver::txt_lookup` successfully with version 0.20.4. The same lookup now fails with version 0.21.0-alpha.4. To reproduce: ```rust use trust_dns_resolver::Resolver; fn main() { let resolver = Resolver::default().unwrap(); let name = "bmc.org"; match resolver.txt_lookup(name) { Ok(lookup) => { for txt in lookup { eprintln!( "<{:?}>", txt.iter() .map(|data| String::from_utf8_lossy(data)) .collect::<String>() ); } } Err(e) => { eprintln!("error: {}", e); } } } ``` Output with trust-dns-resolver 0.20.4: ```text <"docusign=5140f07f-9f9c-4561-8a94-e69761a38442"> <"OVrFqSjwZz9OshiM1LGcVWYjzhtYrg930HlRDNn43M3PFP0Vx3XSv2w0rNxzACUUtgmhp0iXx15yK18nnl0svg=="> <"ZOOM_verify_xJpoFs3nSDywDsvmMWygGg"> <""> <"4FVu/Fi5/VTEsxj+08airJyjv1oKUMC6yFTlOfWCg3ol7HwVAu3lmZre+8UOrQXKpzgJ1vbe/zRUepCN7cnFJg=="> <"v*spf1 include:servers.mcsv.net ?all"> <"v=spf1 a mx include:us._netblocks.mimecast.com include:spf1.service.formassembly.com -all"> <"apple-domain-verification=UnyCDv1Ozqb0yjW7"> <"docusign=2d29c1de-6a95-474d-ada4-3b7c3ee40fa8"> ``` Output with trust-dns-resolver 0.21.0-alpha.4: ```text error: no record found for name: bmc.org. type: TXT class: IN ``` I can reproduce this on two separate hosts (home and VPS).

kerem

2026-03-15 23:56:27 +03:00

closed this issue
added the
bug

crate:resolver
labels

kerem commented

2026-03-15 23:56:43 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 6, 2022):

Thanks the for the report. I think there are two potential changes related to this: #1556 and #1562

I was able to reproduce this with the resolve command and when enabling debug, you can see that the difference between the two requests is that in the 0.20 version it fails the intial request, then reattempts with TCP. In the 0.21 (main) branch, it appears that the promotion to TCP resolution isn't attempted.

My guess is that this is due to the larger record response on all the TXT records, and it requires TCP (> 512 byte reponse).

@peterthejohnston, I think we're going to need to revisit some of those changes. @glts, thank you for finding this before we pushed the next release for 0.21.

@bluejekyll commented on GitHub (Feb 6, 2022): Thanks the for the report. I think there are two potential changes related to this: #1556 and #1562 I was able to reproduce this with the `resolve` command and when enabling debug, you can see that the difference between the two requests is that in the 0.20 version it fails the intial request, then reattempts with TCP. In the 0.21 (`main`) branch, it appears that the promotion to TCP resolution isn't attempted. My guess is that this is due to the larger record response on all the TXT records, and it requires TCP (> 512 byte reponse). @peterthejohnston, I think we're going to need to revisit some of those changes. @glts, thank you for finding this before we pushed the next release for 0.21.

kerem commented

2026-03-15 23:56:48 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 7, 2022):

#1629 appears to resolve this. I want to make sure that we have a test case to reproduce this before merging.

@bluejekyll commented on GitHub (Feb 7, 2022): #1629 appears to resolve this. I want to make sure that we have a test case to reproduce this before merging.

kerem commented

2026-03-15 23:56:54 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 8, 2022):

The patch for this was released today in v0.21.0-alpha.5.

@bluejekyll commented on GitHub (Feb 8, 2022): The patch for this was released today in `v0.21.0-alpha.5`.