[GH-ISSUE #1980] srv lookup docs seem wrong about looking up IPs #837

New issue

Open

opened 2026-03-16 00:30:12 +03:00 by kerem · 1 comment

kerem commented

2026-03-16 00:30:12 +03:00

Owner

Originally created by @davepacheco on GitHub (Jun 27, 2023).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1980

Describe the bug

The docs for SrvLookup::ip_iter() say:

Note: That Trust-DNS performs a recursive lookup on SRV records for IPs if they were not included in the original request. If there are no IPs associated to the result, a subsequent query for the IPs via the srv.target() should not resolve to the IPs.

I assumed this means to say "if they were not included in the initial response"? I interpreted this note to mean that Trust-DNS takes each of the SRV records returned from this query, looks at the target, and makes another query for the A/AAAA records for that target. I know many DNS servers include these A/AAAA records as additional records in the response to the SRV query, and I assume Trust-DNS uses those if it can rather than making a second query. But I assumed from this text that if the server didn't include those A/AAAA records in the response, then Trust-DNS would query for each target on its own.

That doesn't seem to be the case. I've got a DNS server that returns these responses:

$ dig -t SRV _cockroach._tcp.control-plane.oxide.internal @::1 -p 49413

; <<>> DiG 9.16.13 <<>> -t SRV _cockroach._tcp.control-plane.oxide.internal @::1 -p 49413
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49811
;; flags: qr rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;_cockroach._tcp.control-plane.oxide.internal. IN SRV

;; ANSWER SECTION:
_cockroach._tcp.control-plane.oxide.internal. 0 IN SRV 0 0 2222 28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal.
_cockroach._tcp.control-plane.oxide.internal. 0 IN SRV 0 0 3333 ac9aff3a-f9d4-4135-8058-02609c5ed3e9.host.control-plane.oxide.internal.
_cockroach._tcp.control-plane.oxide.internal. 0 IN SRV 0 0 1111 c50e58fa-d56a-4e93-bf50-ebe1c061f41d.host.control-plane.oxide.internal.

;; Query time: 1 msec
;; SERVER: ::1#49413(::1)
;; WHEN: Tue Jun 27 13:08:37 PDT 2023
;; MSG SIZE  rcvd: 332

$ dig -t AAAA 28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. @::1 -p 49413

; <<>> DiG 9.16.13 <<>> -t AAAA 28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. @::1 -p 49413
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64356
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal.        IN AAAA

;; ANSWER SECTION:
28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. 0 IN AAAA ff::2

;; Query time: 0 msec
;; SERVER: ::1#49413(::1)
;; WHEN: Tue Jun 27 13:08:40 PDT 2023
;; MSG SIZE  rcvd: 116

$ dig -t AAAA ac9aff3a-f9d4-4135-8058-02609c5ed3e9.host.control-plane.oxide.internal. @::1 -p 49413

; <<>> DiG 9.16.13 <<>> -t AAAA ac9aff3a-f9d4-4135-8058-02609c5ed3e9.host.control-plane.oxide.internal. @::1 -p 49413
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43899
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ac9aff3a-f9d4-4135-8058-02609c5ed3e9.host.control-plane.oxide.internal.        IN AAAA

;; ANSWER SECTION:
ac9aff3a-f9d4-4135-8058-02609c5ed3e9.host.control-plane.oxide.internal. 0 IN AAAA ff::3

;; Query time: 0 msec
;; SERVER: ::1#49413(::1)
;; WHEN: Tue Jun 27 13:08:45 PDT 2023
;; MSG SIZE  rcvd: 116

$ dig -t AAAA 28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. @::1 -p 49413

; <<>> DiG 9.16.13 <<>> -t AAAA 28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. @::1 -p 49413
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27648
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal.        IN AAAA

;; ANSWER SECTION:
28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. 0 IN AAAA ff::2

;; Query time: 0 msec
;; SERVER: ::1#49413(::1)
;; WHEN: Tue Jun 27 13:08:47 PDT 2023
;; MSG SIZE  rcvd: 116

When I use AsyncResolver::srv_lookup() to look up _cockroach._tcp.control-plane.oxide.internal, the iterator returned by SrvLookup::ip_iter() is empty. I can see from the DNS server log that the server got a query for _cockroach._tcp.control-plane.oxide.internal, but got no queries for the other names. Am I misunderstanding this note?

To Reproduce

I expect you can reproduce this by standing up a DNS server that returns results like the above, using AsyncResolver::srv_lookup() to look up the SRV name, and then looking at the results of the ip_iter(). I could write a small program to try to reproduce this.

Expected behavior

Based on the docs, I expected to get back the set of IP addresses referenced by the AAAA records associated with the targets of the SRV records. That'd be ff::1, ff::2, and ff::3 in this case.

I think it's reasonable for Trust-DNS not to do this, but then the docs seem confusing.

System:

OS: illumos
Architecture: x86_64
Version: helios-1.0.21620
rustc version: 1.70

Version:
Crate: resolver
Version: 0.22

Originally created by @davepacheco on GitHub (Jun 27, 2023). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1980 **Describe the bug** The [docs for `SrvLookup::ip_iter()`](https://docs.rs/trust-dns-resolver/latest/trust_dns_resolver/lookup/struct.SrvLookup.html#method.ip_iter) say: > Note: That Trust-DNS performs a recursive lookup on SRV records for IPs if they were not included in the original request. If there are no IPs associated to the result, a subsequent query for the IPs via the srv.target() should not resolve to the IPs. I assumed this means to say "if they were not included in the initial _response_"? I interpreted this note to mean that Trust-DNS takes each of the SRV records returned from this query, looks at the target, and makes another query for the A/AAAA records for that target. I know many DNS servers include these A/AAAA records as additional records in the response to the SRV query, and I assume Trust-DNS uses those if it can rather than making a second query. But I assumed from this text that if the server _didn't_ include those A/AAAA records in the response, then Trust-DNS would query for each target on its own. That doesn't seem to be the case. I've got a DNS server that returns these responses: ``` $ dig -t SRV _cockroach._tcp.control-plane.oxide.internal @::1 -p 49413 ; <<>> DiG 9.16.13 <<>> -t SRV _cockroach._tcp.control-plane.oxide.internal @::1 -p 49413 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49811 ;; flags: qr rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;_cockroach._tcp.control-plane.oxide.internal. IN SRV ;; ANSWER SECTION: _cockroach._tcp.control-plane.oxide.internal. 0 IN SRV 0 0 2222 28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. _cockroach._tcp.control-plane.oxide.internal. 0 IN SRV 0 0 3333 ac9aff3a-f9d4-4135-8058-02609c5ed3e9.host.control-plane.oxide.internal. _cockroach._tcp.control-plane.oxide.internal. 0 IN SRV 0 0 1111 c50e58fa-d56a-4e93-bf50-ebe1c061f41d.host.control-plane.oxide.internal. ;; Query time: 1 msec ;; SERVER: ::1#49413(::1) ;; WHEN: Tue Jun 27 13:08:37 PDT 2023 ;; MSG SIZE rcvd: 332 $ dig -t AAAA 28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. @::1 -p 49413 ; <<>> DiG 9.16.13 <<>> -t AAAA 28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. @::1 -p 49413 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64356 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. IN AAAA ;; ANSWER SECTION: 28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. 0 IN AAAA ff::2 ;; Query time: 0 msec ;; SERVER: ::1#49413(::1) ;; WHEN: Tue Jun 27 13:08:40 PDT 2023 ;; MSG SIZE rcvd: 116 $ dig -t AAAA ac9aff3a-f9d4-4135-8058-02609c5ed3e9.host.control-plane.oxide.internal. @::1 -p 49413 ; <<>> DiG 9.16.13 <<>> -t AAAA ac9aff3a-f9d4-4135-8058-02609c5ed3e9.host.control-plane.oxide.internal. @::1 -p 49413 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43899 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ac9aff3a-f9d4-4135-8058-02609c5ed3e9.host.control-plane.oxide.internal. IN AAAA ;; ANSWER SECTION: ac9aff3a-f9d4-4135-8058-02609c5ed3e9.host.control-plane.oxide.internal. 0 IN AAAA ff::3 ;; Query time: 0 msec ;; SERVER: ::1#49413(::1) ;; WHEN: Tue Jun 27 13:08:45 PDT 2023 ;; MSG SIZE rcvd: 116 $ dig -t AAAA 28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. @::1 -p 49413 ; <<>> DiG 9.16.13 <<>> -t AAAA 28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. @::1 -p 49413 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27648 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. IN AAAA ;; ANSWER SECTION: 28e54197-8464-4b26-911e-e3cff4f0e04c.host.control-plane.oxide.internal. 0 IN AAAA ff::2 ;; Query time: 0 msec ;; SERVER: ::1#49413(::1) ;; WHEN: Tue Jun 27 13:08:47 PDT 2023 ;; MSG SIZE rcvd: 116 ``` When I use `AsyncResolver::srv_lookup()` to look up `_cockroach._tcp.control-plane.oxide.internal`, the iterator returned by `SrvLookup::ip_iter()` is empty. I can see from the DNS server log that the server got a query for `_cockroach._tcp.control-plane.oxide.internal`, but got no queries for the other names. Am I misunderstanding this note? **To Reproduce** I expect you can reproduce this by standing up a DNS server that returns results like the above, using `AsyncResolver::srv_lookup()` to look up the SRV name, and then looking at the results of the `ip_iter()`. I could write a small program to try to reproduce this. **Expected behavior** Based on the docs, I expected to get back the set of IP addresses referenced by the AAAA records associated with the targets of the SRV records. That'd be `ff::1`, `ff::2`, and `ff::3` in this case. I think it's reasonable for Trust-DNS _not_ to do this, but then the docs seem confusing. **System:** - OS: illumos - Architecture: x86_64 - Version: helios-1.0.21620 - rustc version: 1.70 **Version:** Crate: resolver Version: 0.22

kerem added the

bug

crate:resolver

labels

2026-03-16 00:30:12 +03:00

kerem commented

2026-03-16 00:30:23 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 27, 2023):

It looks like you might have run into this issue that's documented as a FIXME in the caching_client, github.com/bluejekyll/trust-dns@c4e92cf837/crates/resolver/src/caching_client.rs (L325-L329)

@bluejekyll commented on GitHub (Jun 27, 2023): It looks like you might have run into this issue that's documented as a FIXME in the caching_client, https://github.com/bluejekyll/trust-dns/blob/c4e92cf837b2cd5bd5c3567bc405d01cf6eb1f03/crates/resolver/src/caching_client.rs#L325-L329

kerem referenced this issue

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

[PR #837] [CLOSED] Bump h2 from 0.1.25 to 0.1.26 #1729