A registrant, also known as a domain name registrant, is the person or entity that registers a domain name. Registrants can either register their domain with a reseller or directly with a registrar. After registering a domain name, the registrant enters a contract with the registrar or reseller if the registrant works with a third-party entity to register their domain.

A reseller is a third-party organization that is affiliated or under contract with a registrar. Resellers sell domain names and other services offered by registrars and operate between a registrant and registrar. They are not ICANN-accredited. Instead, they purchase domain names from the registrar and re-sell them to registrants. Because resellers are bound by agreements with registrars, they must send the domain information to the registrar.

A registrar is an ICANN-accredited entity. Registries certify the registrar to sell domain names. Registrars sell domain names to resellers and directly to registrants. Registrars must notify the appropriate registry when a registrant registers a domain. For example, if a registrant registers a .com domain with a registrar, the registrar must notify Verisign, which is the registry that manages .com domains.

Registry operators, also known as registries, play an internet ecosystem-level role in the registration and management of domain names. Their primary responsibility is to maintain the main database of all domain names registered in each TLD. They are also responsible for generating zone files, which primarily contain mappings between domain names, IP addresses, and other resources.

ICANN is a not-for-profit partnership of people from all over the world. They oversee the complex interconnected network of unique identifiers, such as domain names and Internet Protocol (IP) addresses. Unique identifiers allow computers on the internet to find each other. Groups representing the different interests on the internet make up ICANN. These include organizations that deal with IP addresses and ones that deal with domain names. Among other responsibilities, ICANN also draws up contracts with registries and runs an accreditation system for registrars, which lends consistency and stability to the DNS and internet.

The service binding record type (SVCB) is designed to streamline information lookups needed to make connections over the internet. You can use SVCB records in AliasMode, and they will act similar to CNAME records. However, SVCB records can function alongside SOA and NS records, which makes it possible to create SVCB records at the zone apex.

You can also use SVCB records in ServiceMode, where they convey connection parameters using the Application-Layer Protocol Negotiation (ALPN) value. You can specify an ALPN ID to indicate that the target expects a certain type of connection. For example, h2 indicates an HTTP/2 connection encrypted by TLS. Presenting connection parameters alongside host information helps reduce the number of DNS queries required for clients to connect to servers.

In a typical DNS query, it is common for several interactions to happen. Clients make an initial DNS request for a website, which might require a redirect from HTTP to HTTPS. Then, they ultimately establish a TLS connection with the website's web server for encrypted communication.

HTTPS records are a type of service binding record designed specifically for the HTTPS connection process. With HTTPS records, you can store more information than a typical A record. Values in HTTPS records can communicate information such as protocols required to reach the target and the IP addresses for web servers serving the target. By reducing the number of exchanges required to establish an optimal connection, HTTPS records can help clients connect to servers more efficiently.

When you initiate a Secure Shell (SSH) session with a new host, the host will present a fingerprint, which acts as a sort of identity. Clients can manually compare this fingerprint with a fingerprint obtained from the host's owning party to confirm its identity. However, this is inefficient and introduces the possibility for human error.

Secure Shell fingerprint (SSHFP) records present another option for this process, by storing a server's fingerprint as a value. If such a record is present, clients can perform a DNS lookup while connecting to a host to verify the fingerprint. Domain administrators typically configure Domain Name System Security Extensions (DNSSEC) when serving these records, to prevent DNS spoofing. Authenticating server fingerprints through DNS helps reduce manual intervention and the possibility for human error.

SSL/TLS encryption is the predominant protocol used to secure communications over the internet. This protocol largely depends on certificate authorities (CAs) to verify the identities of internet entities and issue TLS certificates. The certificates affirm the identities of the entities to clients during the TLS handshake process.

The DNS-based Authentication of Named Entities (DANE) protocol was introduced as a way to authenticate TLS entities without the need to trust CAs. Domain administrators can publish TLS server certificates or public keys as values in TLSA records when DNSSEC is configured. When these records are present, clients can verify that the server credentials provided during a TLS handshake match those published through DNS. Through this process, clients have the option to trust domain owners rather than CAs.