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 192.0.2.1
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.
