[GH-ISSUE #727] Client SRV lookups fail despite server returning response #281

New issue

Closed

opened 2026-03-07 23:15:34 +03:00 by kerem · 2 comments

kerem commented

2026-03-07 23:15:34 +03:00

Owner

Originally created by @bowrocker on GitHub (Apr 5, 2019).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/727

Describe the bug
Attempting to use both the trust_dns_resolver and the Sync client to do SRV record lookups. Results shown when doing A record queries, but when doing an SRV query for a known, existing SRV record, nothing is return to the calling code below. Thanks for any and all help!

Code:

    let address = "8.8.8.8:53".parse().unwrap();
    let conn = UdpClientConnection::new(address).unwrap();

    let client = SyncClient::new(conn);
    let name = Name::from_str("_http._tcp.example.com.").unwrap();

    let response: Message = client.query(&name, DNSClass::IN, RecordType::SRV).unwrap();
    println!("answer length: {}" , response.answers().len());

dig shows record exists:

; <<>> DiG 9.10.6 <<>> srv _http._tcp.example.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60327
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_http._tcp.example.com.		IN	SRV

;; AUTHORITY SECTION:
example.com.		1218	IN	SOA	sns.dns.icann.org. noc.dns.icann.org. 2018112886 7200 3600 1209600 3600

tcpdump shows packet response from server while running the code above:

08:27:43.812417 IP (tos 0x0, ttl 64, id 40455, offset 0, flags [none], proto UDP (17), length 79)
    192.168.1.16.47946 > google-public-dns-a.google.com.domain: [udp sum ok] 5654+ [1au] SRV? _http._tcp.example.com. ar: . OPT UDPsize=1452 (51)
08:27:43.843404 IP (tos 0x0, ttl 119, id 3786, offset 0, flags [none], proto UDP (17), length 136)
    google-public-dns-a.google.com.domain > 192.168.1.16.47946: [udp sum ok] 5654 NXDomain q: SRV? _http._tcp.example.com. 0/1/1 ns: example.com. SOA sns.dns.icann.org. noc.dns.icann.org. 2018112886 7200 3600 1209600 3600 ar: . OPT UDPsize=512 (108)

No response from client:

answer length: 0

To Reproduce
Code snippet above with google resolvers.

Expected behavior
Expect an SRV record to be returned.

System:

MacOS
x86_64
10.14.3
rustc 1.33.0

Version:
Crate: client, resolver
Version: resolver: 0.10.3, client: 0.13

Additional context
Add any other context about the problem here.

Originally created by @bowrocker on GitHub (Apr 5, 2019). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/727 **Describe the bug** Attempting to use both the trust_dns_resolver and the Sync client to do SRV record lookups. Results shown when doing A record queries, but when doing an SRV query for a known, existing SRV record, nothing is return to the calling code below. Thanks for any and all help! Code: let address = "8.8.8.8:53".parse().unwrap(); let conn = UdpClientConnection::new(address).unwrap(); let client = SyncClient::new(conn); let name = Name::from_str("_http._tcp.example.com.").unwrap(); let response: Message = client.query(&name, DNSClass::IN, RecordType::SRV).unwrap(); println!("answer length: {}" , response.answers().len()); dig shows record exists: ``` ; <<>> DiG 9.10.6 <<>> srv _http._tcp.example.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60327 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;_http._tcp.example.com. IN SRV ;; AUTHORITY SECTION: example.com. 1218 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2018112886 7200 3600 1209600 3600 ``` tcpdump shows packet response from server while running the code above: ``` 08:27:43.812417 IP (tos 0x0, ttl 64, id 40455, offset 0, flags [none], proto UDP (17), length 79) 192.168.1.16.47946 > google-public-dns-a.google.com.domain: [udp sum ok] 5654+ [1au] SRV? _http._tcp.example.com. ar: . OPT UDPsize=1452 (51) 08:27:43.843404 IP (tos 0x0, ttl 119, id 3786, offset 0, flags [none], proto UDP (17), length 136) google-public-dns-a.google.com.domain > 192.168.1.16.47946: [udp sum ok] 5654 NXDomain q: SRV? _http._tcp.example.com. 0/1/1 ns: example.com. SOA sns.dns.icann.org. noc.dns.icann.org. 2018112886 7200 3600 1209600 3600 ar: . OPT UDPsize=512 (108) ``` No response from client: ``` answer length: 0 ``` **To Reproduce** Code snippet above with google resolvers. **Expected behavior** Expect an SRV record to be returned. **System:** - MacOS - x86_64 - 10.14.3 - rustc 1.33.0 **Version:** Crate: client, resolver Version: resolver: 0.10.3, client: 0.13 **Additional context** Add any other context about the problem here.

kerem

2026-03-07 23:15:34 +03:00

closed this issue
added the
unclear

crate:client

crate:resolver
labels

kerem commented

2026-03-07 23:15:50 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 5, 2019):

Before we dig into this, I want to make sure we're clear about a couple of things. The resolver will do some recursive resolutions to find the records behind an SRV record, or at least it can and should. We'll need to double check that, but I think it will.

The client on the other hand is a "dumb" client, it will do no recursive queries, and leaves that up to the user of that library to perform any additional processing etc, to find the results.

With that out of the way, are you sure your looking up the correct name? The dig output you posted appears to have returned an NXDOMAIN (non-existent domain), for that query:

...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60327
...
;; QUESTION SECTION:
;_http._tcp.example.com.		IN	SRV

@bluejekyll commented on GitHub (Apr 5, 2019): Before we dig into this, I want to make sure we're clear about a couple of things. The `resolver` will do some recursive resolutions to find the records behind an SRV record, or at least it can and should. We'll need to double check that, but I think it will. The `client` on the other hand is a "dumb" client, it will do no recursive queries, and leaves that up to the user of that library to perform any additional processing etc, to find the results. With that out of the way, are you sure your looking up the correct name? The dig output you posted appears to have returned an NXDOMAIN (non-existent domain), for that query: ```text ... ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60327 ... ;; QUESTION SECTION: ;_http._tcp.example.com. IN SRV ```

kerem commented

2026-03-07 23:15:55 +03:00

Author

Owner

@bowrocker commented on GitHub (Apr 5, 2019):

My apologies, I had the wrong SRV record as you point out. Once I had a good one, it works as expected.

Thank you for the response and for the detail about the client and resolver differences, that helps a lot.

@bowrocker commented on GitHub (Apr 5, 2019): My apologies, I had the wrong SRV record as you point out. Once I had a good one, it works as expected. Thank you for the response and for the detail about the client and resolver differences, that helps a lot.

kerem referenced this issue

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

[PR #281] [MERGED] Client: Don't make dnssec-openssl a default feature (breaking change). #1337