SRV Record Lookup finds the host and port that provide a named service on a domain. Unlike most DNS records, an SRV record carries a port number, which is what lets a client discover not just where a service lives but which port to reach it on. The name follows a fixed pattern of service, protocol and domain, such as _sip._tcp.example.com, and the leading underscores are part of the specification rather than a convention. Each record has four fields: priority and weight, then port and target. Priority works like MX, lowest first, while weight distributes traffic between records that share a priority, in proportion to the numbers given. This is the mechanism behind autodiscovery in Microsoft 365, XMPP, SIP telephony and Minecraft servers, among others. The most common mistake is pointing the target at an IP address or a CNAME; like MX, the target must be a hostname with its own address record. A missing SRV record usually shows up as a client that cannot autoconfigure rather than as an obvious DNS failure.
DNS resolution happens in multiple stages. When you type a domain name, your browser first checks its own cache, then the OS resolver cache, then queries your configured DNS resolver (usually your ISP or a public resolver like 8.8.8.8 or 1.1.1.1). If none have the record cached, the resolver performs a recursive query: it asks the root name servers for the TLD servers (.com, .net, etc.), then asks the TLD servers for the authoritative name servers of the specific domain, and finally asks the authoritative servers for the actual record. This entire process typically completes in under 100ms. DNS-over-HTTPS (DoH) encrypts DNS queries in HTTPS traffic, preventing ISPs and network observers from seeing which domains you query. It was standardized in RFC 8484 in 2018 and is now supported by all major browsers. Google and Cloudflare both operate free public DoH endpoints (dns.google and cloudflare-dns.com). TXT records have become a critical security mechanism: SPF (Sender Policy Framework) records specify which servers are allowed to send email for a domain, DKIM (DomainKeys Identified Mail) records provide public keys for verifying email signatures, and DMARC records tell receiving mail servers what to do when SPF or DKIM checks fail. Checking these records is the first step in diagnosing email deliverability problems.