What's the use case of SVCB (type 65 , service binding) RR

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:

• https://groups.google.com/a/chromium.org/g/blink-dev/c/brZTXr6-2PU/m/g0g8wWwCAwAJ stating in April 2021: "Chrome will soon begin experimenting with querying HTTPS and INTEGRITY via Classic DNS (Do53) on platforms where Chrome regularly handles Do53 via its built-in resolver (Android, ChromeOS, and MacOS)."
• https://bugzilla.mozilla.org/show_bug.cgi?id=1634793 : just showing that the feature right now depends on 5 other still open bugs that probably need to be closed first, without any timeframes

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:

• PowerDNS has support already: https://doc.powerdns.com/authoritative/guides/svcb.html
• July version of nsd has support too: https://www.nlnetlabs.nl/news/2021/Jul/22/nsd-4.3.7-released/ with "New features are XoT which provides AXFR and IXFR over TLS, and DNS Cookies support and SVCB and HTTPS RR type support."
• Knot DNS also, at https://www.knot-dns.cz/2021-08-02-version-310.html with an August release and some support: "libs: support for parsing and dumping SVCB and HTTPS resource records"

So you can already experiment full support with other software.