[GH-ISSUE #2781] CachingClient flattens `additionals` into `answers` #1059

New issue

Closed

opened 2026-03-16 01:29:00 +03:00 by kerem · 1 comment

kerem commented

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

Owner

Originally created by @howardjohn on GitHub (Feb 14, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2781

Describe the bug
I am sending a lookup through CachingClient. The response from the upstream looks like:

2025-02-14T16:23:51.941167Z     debug   hickory_resolver::error:lookup{src=10.10.0.32:40976 query=SRV name=_tcp.db.srv.tld.}    Response:; header 51968:RESPONSE:RD,AA
:NoError:QUERY:3/0/3
; query
;; _tcp.db.srv.tld. IN SRV
; answers 3
_tcp.db.srv.tld. 8 IN SRV 0 0 1024 privatelink-db.srv.tld.
_tcp.db.srv.tld. 8 IN SRV 0 0 1025 privatelink-db.srv.tld.
_tcp.db.srv.tld. 8 IN SRV 0 0 1026 privatelink-db.srv.tld.
; nameservers 0
; additionals 3
privatelink-db.srv.tld. 8 IN A 10.140.0.250
privatelink-db.srv.tld. 8 IN A 10.140.0.250
privatelink-db.srv.tld. 8 IN A 10.140.0.250

The response from hickory flattens the additionals though:

$dig _tcp.db.srv.tld. SRV

; <<>> DiG 9.18.31 <<>> _tcp.db.srv.tld. SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59590
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_tcp.db.srv.tld.               IN      SRV

;; ANSWER SECTION:
_tcp.db.srv.tld.        8       IN      SRV     0 0 1024 privatelink-db.srv.tld.
_tcp.db.srv.tld.        8       IN      SRV     0 0 1025 privatelink-db.srv.tld.
_tcp.db.srv.tld.        8       IN      SRV     0 0 1026 privatelink-db.srv.tld.
privatelink-db.srv.tld. 8       IN      A       10.140.0.250
privatelink-db.srv.tld. 8       IN      A       10.140.0.250
privatelink-db.srv.tld. 8       IN      A       10.140.0.250

;; Query time: 3 msec
;; SERVER: 10.120.0.10#53(10.120.0.10) (UDP)
;; WHEN: Fri Feb 14 16:23:51 UTC 2025
;; MSG SIZE  rcvd: 218

(for completeness, the same dig not going through hickory:

/ $dig _tcp.db.srv.tld. SRV

; <<>> DiG 9.18.31 <<>> _tcp.db.srv.tld. SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41364
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9521c3230b00f6ae (echoed)
;; QUESTION SECTION:
;_tcp.db.srv.tld.               IN      SRV

;; ANSWER SECTION:
_tcp.db.srv.tld.        6       IN      SRV     0 0 1024 privatelink-db.srv.tld.
_tcp.db.srv.tld.        6       IN      SRV     0 0 1025 privatelink-db.srv.tld.
_tcp.db.srv.tld.        6       IN      SRV     0 0 1026 privatelink-db.srv.tld.

;; ADDITIONAL SECTION:
privatelink-db.srv.tld. 6       IN      A       10.140.0.250
privatelink-db.srv.tld. 6       IN      A       10.140.0.250
privatelink-db.srv.tld. 6       IN      A       10.140.0.250

;; Query time: 3 msec
;; SERVER: 10.120.0.10#53(10.120.0.10) (UDP)
;; WHEN: Fri Feb 14 16:31:31 UTC 2025
;; MSG SIZE  rcvd: 341

)

To Reproduce
This can be reproduced against a coredns upstream server with the following config:

    template ANY ANY _tcp.db.srv.tld {
      answer "{{ .Name }} 8 IN SRV 0 0 1024 privatelink-db.srv.tld."
      answer "{{ .Name }} 8 IN SRV 0 0 1025 privatelink-db.srv.tld."
      answer "{{ .Name }} 8 IN SRV 0 0 1026 privatelink-db.srv.tld."
      additional "privatelink-db.srv.tld. 8 IN A 10.140.0.250"
      additional "privatelink-db.srv.tld. 8 IN A 10.140.0.250"
      additional "privatelink-db.srv.tld. 8 IN A 10.140.0.250"
    }

Then send a request through hickory.

Expected behavior
additionals should be preserved (I think?)

System:

OS: Linux
Architecture: x86_64
Version: v0.24.2
rustc version:1.84.0

Version:
Crate: [e.g. client, server, resolver]
Version: v0.24.2

Additional context
I believe the split of answers/additionals is lost here github.com/hickory-dns/hickory-dns@284c625eaa/crates/resolver/src/caching_client.rs (L393) where we flatten them all together

Originally created by @howardjohn on GitHub (Feb 14, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2781 **Describe the bug** I am sending a `lookup` through `CachingClient`. The response from the upstream looks like: ``` 2025-02-14T16:23:51.941167Z debug hickory_resolver::error:lookup{src=10.10.0.32:40976 query=SRV name=_tcp.db.srv.tld.} Response:; header 51968:RESPONSE:RD,AA :NoError:QUERY:3/0/3 ; query ;; _tcp.db.srv.tld. IN SRV ; answers 3 _tcp.db.srv.tld. 8 IN SRV 0 0 1024 privatelink-db.srv.tld. _tcp.db.srv.tld. 8 IN SRV 0 0 1025 privatelink-db.srv.tld. _tcp.db.srv.tld. 8 IN SRV 0 0 1026 privatelink-db.srv.tld. ; nameservers 0 ; additionals 3 privatelink-db.srv.tld. 8 IN A 10.140.0.250 privatelink-db.srv.tld. 8 IN A 10.140.0.250 privatelink-db.srv.tld. 8 IN A 10.140.0.250 ``` The response from hickory flattens the additionals though: ``` $dig _tcp.db.srv.tld. SRV ; <<>> DiG 9.18.31 <<>> _tcp.db.srv.tld. SRV ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59590 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;_tcp.db.srv.tld. IN SRV ;; ANSWER SECTION: _tcp.db.srv.tld. 8 IN SRV 0 0 1024 privatelink-db.srv.tld. _tcp.db.srv.tld. 8 IN SRV 0 0 1025 privatelink-db.srv.tld. _tcp.db.srv.tld. 8 IN SRV 0 0 1026 privatelink-db.srv.tld. privatelink-db.srv.tld. 8 IN A 10.140.0.250 privatelink-db.srv.tld. 8 IN A 10.140.0.250 privatelink-db.srv.tld. 8 IN A 10.140.0.250 ;; Query time: 3 msec ;; SERVER: 10.120.0.10#53(10.120.0.10) (UDP) ;; WHEN: Fri Feb 14 16:23:51 UTC 2025 ;; MSG SIZE rcvd: 218 ``` (for completeness, the same `dig` not going through hickory: ``` / $dig _tcp.db.srv.tld. SRV ; <<>> DiG 9.18.31 <<>> _tcp.db.srv.tld. SRV ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41364 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 9521c3230b00f6ae (echoed) ;; QUESTION SECTION: ;_tcp.db.srv.tld. IN SRV ;; ANSWER SECTION: _tcp.db.srv.tld. 6 IN SRV 0 0 1024 privatelink-db.srv.tld. _tcp.db.srv.tld. 6 IN SRV 0 0 1025 privatelink-db.srv.tld. _tcp.db.srv.tld. 6 IN SRV 0 0 1026 privatelink-db.srv.tld. ;; ADDITIONAL SECTION: privatelink-db.srv.tld. 6 IN A 10.140.0.250 privatelink-db.srv.tld. 6 IN A 10.140.0.250 privatelink-db.srv.tld. 6 IN A 10.140.0.250 ;; Query time: 3 msec ;; SERVER: 10.120.0.10#53(10.120.0.10) (UDP) ;; WHEN: Fri Feb 14 16:31:31 UTC 2025 ;; MSG SIZE rcvd: 341 ``` ) **To Reproduce** This can be reproduced against a coredns upstream server with the following config: ``` template ANY ANY _tcp.db.srv.tld { answer "{{ .Name }} 8 IN SRV 0 0 1024 privatelink-db.srv.tld." answer "{{ .Name }} 8 IN SRV 0 0 1025 privatelink-db.srv.tld." answer "{{ .Name }} 8 IN SRV 0 0 1026 privatelink-db.srv.tld." additional "privatelink-db.srv.tld. 8 IN A 10.140.0.250" additional "privatelink-db.srv.tld. 8 IN A 10.140.0.250" additional "privatelink-db.srv.tld. 8 IN A 10.140.0.250" } ``` Then send a request through hickory. **Expected behavior** `additionals` should be preserved (I think?) **System:** - OS: Linux - Architecture: x86_64 - Version: v0.24.2 - rustc version:1.84.0 **Version:** Crate: [e.g. client, server, resolver] Version: v0.24.2 **Additional context** I believe the split of answers/additionals is lost here https://github.com/hickory-dns/hickory-dns/blob/284c625eaa0aff270d6995b503b4eb69fa960064/crates/resolver/src/caching_client.rs#L393 where we flatten them all together

kerem closed this issue

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

kerem commented

2026-03-16 01:29:11 +03:00

Author

Owner

@divergentdave commented on GitHub (Feb 14, 2025):

Yeah, this is probably the wrong behavior. For example, the DNSSEC RFCs have a SHOULD saying that responses should be cached "as a single atomic entry".

Issue #2602 is somewhat related, but in the case of the recursive resolver we split responses into many cache entries, rather than combining them into one entry with just one list of records.

@divergentdave commented on GitHub (Feb 14, 2025): Yeah, this is probably the wrong behavior. For example, the DNSSEC RFCs have a SHOULD saying that responses should be cached "as a single atomic entry". Issue #2602 is somewhat related, but in the case of the recursive resolver we split responses into many cache entries, rather than combining them into one entry with just one list of records.

kerem referenced this issue

2026-03-16 03:43:24 +03:00

[PR #1059] [MERGED] Bump serde from 1.0.105 to 1.0.106 #1926

kerem referenced this issue

2026-03-16 03:59:46 +03:00

[PR #1059] [MERGED] Bump serde from 1.0.105 to 1.0.106 #1933