SVCB/HTTPS: Bind9 and Dig fail to parse packet if zero SvcPriority and existing SvcParams

Summary

Whenever a SVCB/HTTPS record appears in a DNS packet, and SvcPriority is zero (indicating AliasMode) and SvcParams exist (which they shouldn't in AliasMode, but it might happen), then the parsing routines fail.

This is true for Dig, as well as for Bind9 trying to AXFR/IXFR a zone containing such record.

RFC 9460 says:

In AliasMode, recipients MUST ignore any SvcParams that are present. Zone-file parsers MAY emit a warning if an AliasMode record has SvcParams. The use of SvcParams in AliasMode records is currently not defined, but a future specification could extend AliasMode records to include SvcParams.

Which clearly does not encourage the recipient to throw away whole DNS response in such case.

BIND version affected

9.18.26, 9.16.23, 9.18.18, git "main" branch

Steps to reproduce

I prepared a testing record in xdp.cz zone to demonstrate this issue. Note that the record might be deleted in the future.

dig @ns1.xdp.cz. https-test1.xdp.cz. -t HTTPS

What is the current bug behavior?

dig @ns1.xdp.cz. https-test1.xdp.cz. -t HTTPS
;; Got bad packet: extra input data
85 bytes
f2 68 85 00 00 01 00 01 00 00 00 01 0b 68 74 74          .h...........htt
70 73 2d 74 65 73 74 31 03 78 64 70 02 63 7a 00          ps-test1.xdp.cz.
00 41 00 01 c0 0c 00 41 00 01 00 00 01 2c 00 1a          .A.....A.....,..
00 00 03 77 77 77 08 6b 6e 6f 74 2d 64 6e 73 02          ...www.knot-dns.
63 7a 00 00 01 00 03 02 68 32 00 00 29 04 d0 00          cz......h2..)...
00 00 00 00 00

What is the expected correct behavior?

Similar to how kdig works:

kdig @ns1.xdp.cz. https-test1.xdp.cz. -t HTTPS
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 3653
;; Flags: qr aa rd; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; https-test1.xdp.cz.          IN      HTTPS

;; ANSWER SECTION:
https-test1.xdp.cz.     300     IN      HTTPS   0 www.knot-dns.cz. alpn="h2"

;; Received 74 B
;; Time 2024-04-29 17:15:18 CEST
;; From 2001:1488:ac15:ff90::165@53(UDP) in 5.3 ms

...plus optionally emit a warning

How to fix it

Probably just removing this https://gitlab.isc.org/isc-projects/bind9/-/blob/main/lib/dns/rdata/in_1/svcb_64.c?ref_type=heads#L829

And you might want to add sanity checks elsewhere.