Feature request: support for SVCB and HTTPS dns records

[mikeS7]

SVCB, HTTPSSVC, and ALTSVC DNS records are introduced by IETF draft - https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/11/

Chrome started to use HTTPS record type, more info can be found here - https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ/edit?usp=sharing

Please add support for SVCB (type 64) and HTTPS (type 65) records.
ipv4hint and ipv6hint can be added directly from a response but CNAME requires special processing and data structure change.

I’ve got issues with bbc cdn in case when HTTPS record returns CNAME which can be resolved in multiple addresses but A record return only one.

[blind-oracle]

Sorry it took some time to look at this. If that's still relevant - can you provide examples or problematic sites to see edge cases? Should be quite easy to add

[mikeS7]

Sure, please take a look for:
www.rutracker.org for ipv4hint and ipv6hint
dig @1.1.1.1 www.rutracker.org HTTPS

`;; ANSWER SECTION:

www.rutracker.org. 300 IN HTTPS 1 . alpn="h3,h3-29,h2" ipv4hint=104.21.72.173,172.67.187.38 ipv6hint=2606:4700:3033::6815:48ad,2606:4700:3034::ac43:bb26`

www.bbc.com - I've got only CNAME with no full resolve to A record
dig @1.1.1.1 www.bbc.com HTTPS
`;; ANSWER SECTION:

www.bbc.com. 28589 IN CNAME www.bbc.com.pri.bbc.com.
www.bbc.com.pri.bbc.com. 89 IN CNAME bbc.map.fastly.net.`

I have no examples for SVCB records but looks like Chrome doesn't request them.

More examples can be found in https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/12/ paragraph 10.4
example.com. 7200 IN HTTPS 0 svc.example.net.

Also looks like Chrome asks HTTPS record for returned CNAME so it can be nested somehow:
after `;; QUESTION SECTION:
;weather-data.apple.com. IN HTTPS

;; ANSWER SECTION:
weather-data.apple.com. 256 IN CNAME weather-data.apple.com.akadns.net.
weather-data.apple.com.akadns.net. 16 IN CNAME weather-data.apple.com.akamaized.net.
weather-data.apple.com.akamaized.net. 21556 IN CNAME a2047.dscapi9.akamai.net.`

I can see request for ;; QUESTION SECTION: ;a2047.dscapi9.akamai.net. IN HTTPS

[blind-oracle]

Well, I guess the case with ipv*hint I'll add, should be easy.

The case with only CNAMEs and no A record in a reply chain is harder since either we need to do our resolving, or cache the original domain and last CNAME target in the chain and wait for the client to request it subsequently and then store original domain -> IP mapping. It shouldn't be hard but would require some work to implement the cache etc

[blind-oracle]

Ok, bbc case is just wrong since it returns the same answer for any query, not only HTTPS. The only case is when you request A it returns A records along and only CNAMEs for all others.

[mikeS7]

Agree, but such operation can be found on others CDNs. Response to HTTPS request shouldn't return A record.
I think there should be some mapping between domain and CNAME not just domain -> IP

[blind-oracle]

Response to HTTPS request shouldn't return A record.

Response to IN HTTPS should be only HTTPS RR, not CNAME I think. At least going thru RFC gave me that impression.

[mikeS7]

Looks you are right, Chrome performs A and AAAA queries for www.bbc.com and ignores CNAME response.
From Chrome logic (https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ/edit#heading=h.w9t041jx3u8n):

Followup Queries
Unlike A/AAAA there are cases where HTTPS responses could result in the need for Chrome to make additional queries. (Note that Chrome, like most DNS clients, always relies on recursive resolvers handling CNAME and including the full chain in responses seen by Chrome, so CNAME results do not ever result in followup queries in current Chrome logic.)

If Chrome receives an HTTPS alias record, but a record for the alias target is not included in the same response, Chrome will need to make an additional round of A/AAAA/HTTPS queries for the alias target name. To avoid any issues with loops or poor performance from chains, Chrome will only make one such round of followup. If more are needed, Chrome will behave as if the HTTPS records do not exist and will use the data from the original A/AAAA records alone (ignoring any A/AAAA results from the first followup query). Note that the potential for multiple alias followups should only come from successive chain links because splitting aliases at the same level are disallowed (spec states to pick one at random if it happens).

If Chrome receives a compatible HTTPS service record with a different service name than the query name, but no address hints are given, Chrome will need to make additional A/AAAA queries (but not an HTTPS query). In theory, Chrome could attempt such followups for all compatible service records, but for simplicity/performance, Chrome will only allow one such followup (possible exception for cache-only followups) per host resolution job, choosing the highest priority service record based on protocol and weight.