DNS SRV Record Generator

Under the Hood: Decoupling Ports and Hosts with DNS SRV Records

The Domain Name System (DNS) is fundamentally designed to translate human-readable hostnames into network-routable IP addresses. Standard resource records, such as A and AAAA records, handle this mapping efficiently but make an implicit assumption: that the client application already knows which network port to use. For example, standard HTTP web traffic is expected on port 80, secure HTTPS on port 443, and SMTP email on port 25.

However, when running specialized systems like VoIP telephony (SIP), instant messaging (XMPP), directory listings (LDAP), or gaming services (like Minecraft), hardcoding port addresses limits architectural flexibility. A DNS SRV (Service) record, defined by RFC 2782, solves this by introducing a service discovery layer. By querying an SRV record, a client receives not only the server's location but also the exact port number, priority ranking, and weight distribution parameters. This allows multiple instances of a service to run on different ports of a single host, making maximum use of server resources.

Before and After: Service Connection Implementations

Below is a typical code illustration comparing a rigid connection method with a flexible, dynamic DNS SRV service discovery implementation:

// Hardcoded domain, protocol, and standard port
function connectToSipService() {
    $host = "sip.example.com";
    $port = 5060; // Rigid, can't change port dynamically
    $socket = fsockopen($host, $port);
    return $socket;
}

// Dynamic resolution of service hostname and port
function connectToSipSrv() {
    $records = dns_get_record("_sip._tcp.example.com", DNS_SRV);
    usort($records, function($a, $b) {
        return $a['pri'] <=> $b['pri'];
    });
    $primary = $records[0];
    $target = $primary['target'];
    $port = $primary['port'];
    
    $socket = fsockopen($target, $port);
    return $socket;
}

3-Column SRV Record Use-Case Matrix

Common SRV Mistakes & Troubleshooting Guide

• Pointing SRV Targets to CNAME records: Under RFC 2782, the Target hostname in an SRV record must point directly to a valid A or AAAA record. Pointing an SRV record to a CNAME alias is a protocol violation. Doing so can cause resolution timeouts, security validation warnings, or connection failures on strict client resolvers.
• Omitting Leading Underscores: Developers occasionally configure the service or protocol as sip and tcp rather than _sip and _tcp. Leading underscores are mandatory to prevent collision with standard subdomains, and their omission will prevent systems from matching requests correctly.
• Forgetting Trailing Dots in BIND Zone Files: When writing BIND configurations directly, the target hostname must end with a trailing dot (e.g. mc.example.com.). If this dot is omitted, the name server will append the origin domain, resolving the host incorrectly to mc.example.com.example.com.

Best Practices for Registrar Configuration

When setting up SRV records in popular registrars like Cloudflare, GoDaddy, or Namecheap, ensure you choose the specialized "SRV" record type rather than a standard text record. This ensures the registrar parses the fields correctly and structures the record into the proper zone formats.

Additionally, maintain clean naming schemes: use lowercase letters for host targets, set realistic TTL values (typically 1 hour or 3600 seconds) to allow rapid adjustments during network maintenance, and regularly test your deployments using command-line query tools to verify weighting behaviors and confirm fallback routes are working properly.