I am getting lot of SVCB (type 65) queries from my clients. On further digging , i figure out that few clients (like apple iOS 14) uses this RR heavily.

sample query of SVCB (type 65) is as follows -

dig gsp85-ssl.ls.apple.com -t type65 @

; <<>> DiG  <<>> gsp85-ssl.ls.apple.com -t type65 @
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30904
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;gsp85-ssl.ls.apple.com.        IN  TYPE65

gsp85-ssl.ls.apple.com. 1823    IN  CNAME   gsp85-ssl.ls2-apple.com.akadns.net.

akadns.net.     117 IN  SOA internal.akadns.net. hostmaster.akamai.com. 1619000353 90000 90000 90000 180

;; Query time: 1 msec
;; WHEN: Tue Aug 24 20:33:05 2021
;; MSG SIZE  rcvd: 164

I have the following doubts -

i. Does type65 RR can be a replacement of CNAME , especially in cases as we can't have CNAME at the top level of the zone

ii. How i can instruct the browsers to ask for type65 queries instead of A or AAAA for my domain so that i have my abc.com directly over CDN

iii. which version of bind supports SVCB (type 65) RR

1 Answer 1


SVCB/HTTPS DNS records are currently being worked on (see https://github.com/MikeBishop/dns-alt-svc/blob/master/draft-ietf-dnsop-svcb-https.md for the working document or https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-07.txt at IETF) but not yet finalised.

The strange ambiguous situation right now is that IANA already registered the codes for them (which is why they can already happen in the wild and be interoperable, through the RFC 3597 way of handling generic record types), even if the RFC is not yet ready/published, and some vendors (Apple and Cloudflare, see below) said they already implemented it and use it.

See https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ for example for Cloudflare, which also gives an example why it is used. I recommend reading it, probably before the technical standard itself, except if you already master DNS and TLS.

The idea came out basically after/during TLS 1.3 (and encrypted clientHello/encrypted SNI needs), and HTTP/3 and QUIC. The document aims to solve multiple problems in fact, where part of them were already solved by SRV records that no browsers decided to implement back then.

As taken from the abstract:

SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.

Now on your specific points:

i. Does type65 RR can be a replacement of CNAME , especially in cases as we can't have CNAME at the top level of the zone

Yes, SVCB/HTTPS were designed to help handling the "CNAME at apex" case. See "10.3.2. Apex aliasing" in the draft:

   Consider a zone that is using CNAME aliasing:

   $ORIGIN aliased.example. ; A zone that is using a hosting service
   ; Subdomain aliased to a high-performance server pool
   www             7200 IN CNAME pool.svc.example.
   ; Apex domain on fixed IPs because CNAME is not allowed at the apex
   @                300 IN A
                        IN AAAA  2001:db8::1

   With HTTPS RRs, the owner of aliased.example could alias the apex by
   adding one additional record:

   @               7200 IN HTTPS 0 pool.svc.example.

ii. How i can instruct the browsers to ask for type65 queries instead of A or AAAA for my domain so that i have my abc.com directly over CDN

You will have to wait for browsers to support it :-)

Have a look at the thread at https://mailarchive.ietf.org/arch/msg/dnsop/eeP4H9fli712JPWnEMvDg1sLEfg/ ; there is support in iOS 14 and Safari it seems, in some experimental fashion.

The blog article at Cloudflare gives at the end two links to track status of feature in Firefox and Chrome:

By the way, pleased don't obfuscate badly. Use example.com in documentation, see RFC2606

iii. which version of bind supports SVCB (type 65) RR

None shipped yet. This is tracked in https://gitlab.isc.org/isc-projects/bind9/-/issues/1132 It has been merged 6 days ago :-) So maybe the next versions will ship it, based on what is in the ticket for the milestone: "September 2021 (9.11.36, 9.11.36-S1, 9.16.21, 9.16.21-S1, 9.17.18)"

However, thanks to RFC 3597 you should be able to enter the records using the generic syntax, with TYPE65 in the zonefile, and bind should serve it. You loose obviously syntax checks and other features (you can look at https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5332/diffs to see exactly what "adding SVCB/HTTPS support to bind" means code-wise; see §4 in the IETF draft to see what specific support authoritative and recursive resolvers need to have for these records; it is a SHOULD so variations are accepted if good reasons, like no true full support yet in the software), but at least you can serve the records.

But remember, there is not just bind out there:

So you can already experiment full support with other software.

  • Thanks @Patrick for such a nice and detailed explanation. Aug 25, 2021 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.