DNS SRV records help a present-day software agent find which host and port provide a named network service. Instead of hard-coding one machine, the agent queries a service-specific DNS name, receives candidate hosts with priorities, weights and ports, resolves their addresses, and tries them according to the service protocol’s rules. The result is service discovery, not proof that a host is trustworthy or that a complex autonomous intelligence exists.
The essential distinction is that priority controls the failover tier, weight influences the order of servers within one tier, TTL governs how long a DNS answer may be cached, and a successful authenticated application connection proves something different from receiving a DNS record. This guide explains the original IETF rules, checks numerical cases, separates discovery from authorization, and shows how an ordinary AI assistant can reconnect to a permitted internal service without silently repeating an unsafe action.
Contents: Why a software agent needs service discovery · Read the five pieces of an SRV answer · Construct the correct query name · Priority means preference among reachable tiers · Weight only compares targets in the same tier · A step-by-step weighted selection example · The special meaning of zero weight · How the target and port are used · What the dot target means · TTL describes DNS cache lifetime, not service health · A checked TTL calculation · Why static SRV weights are not a live load balancer · Use the right failure budget across endpoints · DNS answers cannot prove that an API call succeeded · Authenticate the discovered service separately · Separate discovery from SSRF defenses · Distinguish DNSSEC failure from absent service · Do not mistake HTTPS and SVCB records for SRV · Address records can change independently of SRV records · A safe example of three service locations · Distinguish failover from retrying a committed write · What changes when targets serve different tenants? · A clean state machine for a discovering agent · Parse DNS data as untrusted structured input · Timeouts must be bounded at every network stage · How to avoid DNS refresh storms · An operational test for priority and weight behavior · A complete failure-injection exercise · Observability metrics with explicit denominators · Security and privacy boundaries in a school service · Changed-context transfer: a weighted tier becomes unreachable · Changed-context transfer: total retry time exceeds the deadline · When not to use SRV discovery · Questions readers commonly ask · Original standards and verified learning pathways
Why a software agent needs service discovery
A document-processing agent may depend on a queue broker, indexing gateway, directory service or internal scheduling endpoint. If its configuration names one specific machine and port, maintenance or a deployment change can interrupt the workflow. DNS SRV provides a way for a participating protocol or deployment to publish the location of a service rather than only the address of an individual hostname. The agent can learn several candidates and follow the selection policy without pretending that every IP address hosts the same protocol.
Service discovery is not a universal requirement. An HTTPS API may legitimately use a stable URL and ordinary A, AAAA or HTTPS records instead. The client must have a protocol or deployment contract telling it to consult SRV; searching for arbitrary SRV names and automatically connecting to what appears there can be unsafe. The first design question is therefore not how to parse a record, but which service namespace the client is authorized to discover and under what conditions.
Read the five pieces of an SRV answer
The essential SRV fields are priority, weight, port and target, attached to a DNS owner name that identifies service, transport and domain. For an illustrative service, the owner might be _study-sync._tcp.example.org.. An answer could specify priority 10, weight 60, port 8443 and target sync-a.example.org.. It could also list other targets with the same or a different priority. These are example names in the reserved example.org domain, not live services or measured operational settings.
SRV is DNS resource record type 33 as specified in RFC 2782. Its syntax is not a JSON API for current server health. The record does not carry application credentials, a certificate, current queue depth, successful-replication proof or a legal authority to process data. It identifies where a participating client should try to connect. The workflow after DNS resolution remains the responsibility of the application protocol and the organization’s trust policy.
Construct the correct query name
The owner-name pattern is an underscore-prefixed service identifier, then an underscore-prefixed transport identifier, then the domain. For example _ldap._tcp.example.org. names a hypothetical LDAP service using TCP under example.org. The underscore convention keeps service metadata distinct from ordinary hostnames. A client must know the appropriate service label and transport from its protocol specification or approved configuration; it should not derive names by blindly concatenating an untrusted message.
When a service protocol defines special discovery procedures, follow that document as well as RFC 2782. A resolver response for an unrelated service name is not interchangeable merely because it points to the same server. Protocol names, ports, security handshakes and request semantics may differ. An agent that searches a calendar service must not reinterpret a messaging-service SRV answer as calendar authority. Constrain the allowable suffix and service type before querying DNS.
Priority means preference among reachable tiers
Lower numeric priority values are attempted before higher numeric priority values. Suppose the service advertises target A at priority 10, target B at priority 10, and target C at priority 20. A and B form the preferred tier. C is a fallback tier when the lower-priority options cannot be reached under the client’s connection policy. A priority of 20 is not twice the capacity of 10; these are ordering labels, not performance scores or probabilities.
This ordering is essential to the distinction between high availability and weighted distribution. If A and B share priority 10, weights may influence which is tried first. But an ordinary client should not skip the reachable preferred tier merely because a higher-numbered target has an attractive weight. It must also define what it means for a connection to be unreachable: failed DNS address resolution, refused connection, timeouts, TLS validation failure and a server returning application-level overload have different consequences and may demand different handling.
Weight only compares targets in the same tier
The weight field is a relative selection hint among records with equal priority. Suppose A, B and C all have priority 10 and weights 60, 30 and 10. Their total weight is 100. In an intuitive steady-state interpretation, A gets about 60 of every 100 first-choice selections, B about 30 and C about 10, provided the protocol follows weight-based ordering and no other routing policy overrides it. These are selection tendencies, not guaranteed traffic proportions or availability commitments.
RFC 2782 provides a specific weighted ordering procedure, including special treatment for zero weights and a randomly chosen value between zero and the running total. That specification-level discrete algorithm is not precisely identical to a simplistic 60%/30%/10% lottery on every implementation and finite sample. Retries, failed connections, persistent sessions, DNS caching and client populations further change observed request distribution. Never use SRV weights as a substitute for capacity measurements or dynamic load-balancer health decisions.
A step-by-step weighted selection example
Take three equal-priority records with weights 6, 3 and 1. The sum is 10. A teaching shorthand normalizes these weights to 6/10, 3/10 and 1/10 of the overall weight mass. In the RFC algorithm, zero-weight entries are arranged first, cumulative weights are computed in order and an integer from zero through the sum, inclusive, is selected. The first cumulative value at least as large determines the next target. After selecting a target, remove it from the remaining set and repeat to construct a complete trial order.
The algorithm builds an order, not an instruction to send six consecutive requests to A. For a single connection, try the first selected target. If it fails appropriately, the next selected target can be tried. If the application establishes a long-lived connection, one selected endpoint may carry thousands of messages, so request counts need not reflect the nominal weights. Testing should inspect whether the resolver or library orders records itself, whether the client reorders them, and whether any source of randomness is deterministic across process restarts.
The special meaning of zero weight
A weight of zero does not mean that the target is forbidden or must never receive a connection. RFC 2782 says zero-weight records should have a very small chance of being selected when other records in the same priority group have positive weights. It also prescribes ordering zero-weight records before nonzero-weight records when computing the cumulative weighted choice. That is more subtle than removing zero-weight records entirely from the list.
A common implementation mistake is to divide every record weight by the total and then drop zero entries. If every weight is zero, the denominator becomes zero and that shortcut is undefined. A robust library handles the RFC’s ordering rules and a group of all-zero weights without division by zero. The operational team should document why zero weights were chosen: a deliberately low-preference peer is not the same thing as a failed server. Real health-check logic belongs at another layer.
How the target and port are used
An SRV record supplies a target hostname and a port for the intended service. The client resolves the target to its address records and tries the service at the advertised port. For example, sync-a.example.org. on port 8443 is not necessarily the same endpoint as the default HTTPS service on port 443. Hard-coding a conventional port after SRV discovery defeats one of the record’s core purposes. It can also connect to an unrelated application on the same machine.
RFC 2782 says the SRV target must have address records and must not be an alias in the CNAME sense. An implementation should not silently reinterpret incompatible records as valid SRV targets merely because a generic hostname-resolution library happens to follow aliases. When address results contain both IPv4 and IPv6, the connection policy should consider family preference, timeouts and safe fallback while still preserving the service’s authentication requirements. The name supplied for identity verification must be chosen under the relevant application and TLS rules, not improvised from an arbitrary IP.
What the dot target means
A target consisting of a single dot, ., is the explicit SRV convention indicating that the service is not available at the domain. It is not a root-host address to connect to and not a clever shorthand for whichever server is nearest. If a domain explicitly says the requested service is unavailable, the agent should report that state or follow a separately specified fallback policy. Quietly choosing an unrelated hostname can turn a clean failure into a security incident.
Distinguish this explicit signal from no record found, a temporary DNS timeout, a DNSSEC validation failure or a resolver returning SERVFAIL. Those states have different meanings. A protocol can define application-specific fallback after an empty answer, but the fallback must be authorized and documented. For an internal education system, failure to locate its approved assessment service should not cause the agent to send student material to the first vaguely similar service it discovers elsewhere.
TTL describes DNS cache lifetime, not service health
An SRV record has a DNS TTL, which tells caches how long the answer may be retained according to DNS semantics. If the authoritative record has TTL 300 seconds, a resolver that just obtained it can normally cache it for up to five minutes, subject to resolver behavior and subsequent policy. A client may encounter an answer with a lower remaining TTL because it has already spent time in a cache. The number is not a promise that the target stays reachable for 300 seconds.
Do not confuse DNS refresh with connection retry. If the first selected server fails 20 seconds after discovery, the client can try another previously discovered suitable target without waiting for its DNS cache to expire. Conversely, reconnecting to the same failed address every millisecond does not become safe merely because the TTL has not expired. Maintain explicit deadlines, backoff and failure evidence; re-resolve when appropriate, and do not use DNS freshness as the sole definition of availability.
A checked TTL calculation
Imagine a client records an SRV answer with 300 seconds of remaining TTL at time t = 0. At t = 120 seconds, the remaining nominal cache lifetime is 180 seconds. At t = 301 seconds, the original unrefreshed answer has exceeded that lifetime and should not be presented as a current cached result under ordinary TTL semantics. This arithmetic concerns the local lifetime of one cached answer. It says nothing about whether an authoritative operator has already changed the record or whether other resolvers still hold older answers.
Over twenty minutes there are 1,200 seconds, equivalent to four 300-second intervals. That does not mean exactly four DNS network queries will occur: an idle client may make none; an intermediate resolver may reuse its own cached answer; policy can refresh earlier; and negative caching follows separate rules. Capacity planning should measure actual queries rather than multiplying wall-clock intervals into an invented network-traffic count.
Why static SRV weights are not a live load balancer
RFC 2782 describes weights as a mechanism intended for relatively static choices, such as differences in hardware capacity or network connectivity. Rapidly changing weights to chase per-second CPU load can require very short TTLs and can work against DNS caching. Moreover, a client may keep a connection open long after a lookup, so changing its discovery order does not rebalance existing traffic. The record layer therefore has limited visibility into current request queues and per-user workloads.
If a service needs dynamic routing, use an appropriate load balancer or service mesh with authenticated health signals and well-defined failover. SRV can still point to stable service gateways, but it should not be credited with behavior supplied by other components. When documenting an outage, distinguish the DNS answer, the client-selected endpoint, the actual backend chosen by a proxy, and the application outcome. Otherwise the wrong team may be asked to repair a problem DNS never controlled.
Use the right failure budget across endpoints
A software agent must avoid spending the entire user deadline retrying stale endpoints. Suppose an operation has 900 ms total available, and DNS resolution consumes 50 ms. If the first endpoint uses a 350 ms connection attempt that fails, 500 ms remain. A second attempt taking 300 ms leaves 200 ms for any final fallback and result processing. A third endpoint with a 400 ms minimum handshake expectation cannot fit reliably into that remaining budget; the client should return an explicit incomplete result rather than silently overrunning its deadline.
The calculation matters because retries are not free. Every attempt consumes elapsed time and possibly server resources. Use monotonic elapsed time for deadlines so system clock adjustments do not accidentally extend a request. Pass a bounded residual budget into each connection or downstream RPC. Distinguish retrying a connection that certainly never reached an application from retrying an operation whose remote side may already have committed a write. That latter case requires idempotency or reconciliation, not merely a fresh SRV target.
DNS answers cannot prove that an API call succeeded
An SRV answer can identify candidate hosts and ports. A TCP connection confirms transport reachability at one instant. A TLS handshake, if the protocol uses TLS, helps authenticate the remote peer and protect traffic. An authenticated application response can then report whether a request was accepted, rejected or completed. These are progressively different observations. An AI agent that logs only successful DNS discovery may falsely claim it completed the service action when the application was never contacted.
Track separate states such as discovered, address-resolved, connected, authenticated, request-sent, response-verified and effect-reconciled. For a read-only lookup the final state may be a verified result payload. For an external write it may require an authoritative operation ID and a subsequent status check. Discovery is the beginning of a workflow, not evidence for its conclusion. This boundary becomes essential when tasks are automatically chained together by software agents.
Authenticate the discovered service separately
DNS generally describes how to find a service, not who it is in a cryptographic sense. A malicious or misconfigured answer could redirect a client to a host it should not trust. DNSSEC can provide authenticated DNS data where correctly deployed and validated, but it does not by itself replace TLS certificate verification, application authorization or request-scoped credentials. The correct identity check depends on the protocol and whether the service name, target name or another configured identity is authoritative.
Never disable hostname verification just to make an SRV-discovered endpoint work. If the server certificate does not match the identity that the protocol requires, treat it as a security failure and investigate. Do not automatically forward tokens intended for one audience to a different endpoint simply because DNS listed it. A secure agent also constrains which service names it may query and which discovered destinations it may contact, preventing an untrusted document from steering the agent into internal networks.
Separate discovery from SSRF defenses
Server-side request forgery can arise when software treats an attacker-supplied destination as authority to make arbitrary network connections. DNS SRV adds multiple indirection steps: a supplied domain could lead to a service target, which resolves to one or more addresses. A defensive agent must validate the permitted service namespace and destination policy at the right points, not only the spelling of the original query. A public-looking hostname is not sufficient proof that all resolved addresses are safe.
Where the business task allows only a set of approved internal services, use an allowlist of service identifiers and expected domains, enforce network egress controls, and perform application authentication. When redirecting or retrying, reapply authorization to the actual destination. Avoid turning a user question or retrieved webpage into a DNS owner name without validation. Legitimate discovery and SSRF protection are compatible, but only when the policy is explicit rather than assumed from DNS record structure.
Distinguish DNSSEC failure from absent service
A validating resolver may reject a DNS answer whose DNSSEC proof is invalid. That is different from a correctly authenticated assertion that an SRV record is absent. Treating a validation failure as ordinary no-answer and falling back to an unprotected guessed hostname can erase a meaningful security signal. The application should log enough information for authorized operators to distinguish network timeout, missing name, signed denial, bogus validation, unsupported record type and a dot target.
Even when DNSSEC is operating correctly, a discovered host must still pass the service’s TLS and application controls. Conversely, an environment without DNSSEC may use authenticated application protocols and carefully constrained discovery, but it should not claim DNS data integrity it has not verified. Document what the resolver actually validates and where trust anchors live. The companion guide on DNSSEC addresses the chain-of-trust details without making SRV selection rules responsible for them.
Do not mistake HTTPS and SVCB records for SRV
Modern DNS also has SVCB and HTTPS records defined in RFC 9460. They help describe service endpoints and associated parameters, and support use cases such as alternative HTTP transports and service aliasing. Their structure and processing rules are not identical to SRV’s priority-and-weight selection. A field called priority in one record family must not automatically be fed into the other family’s selection algorithm.
When a client uses an HTTP origin, its URI scheme, host and security semantics remain central. Many HTTP clients do not use SRV for ordinary web requests. RFC 9460 explains why HTTPS records serve several web-specific needs. Pick discovery mechanisms according to the actual protocol, not a universal preference for one acronym. If a deployment migrates from one discovery record type to another, test the client’s supported lookup path, parameter parsing and authentication behavior rather than assuming a DNS administrator can change record types transparently.
Address records can change independently of SRV records
An SRV record points to a hostname and port; that target normally requires another DNS resolution step for address records. The SRV RRset and target’s A or AAAA RRsets may have different TTLs and can change at different times. Caching them as one immutable object forever is unsafe. A client should obey relevant lifetimes and be prepared for an address lookup to fail even after a valid SRV response was obtained.
For example, if the SRV answer retains 200 seconds of validity but the target address has only 30 seconds remaining, the agent should not assume it can reuse the old address for all 200 seconds simply because the SRV target name is unchanged. The record types answer different questions: which hostname is the service target, and which network addresses currently correspond to that hostname. Connection libraries may cache additional state, so production tests should include explicit address rotations and mixed IPv4/IPv6 failures.
A safe example of three service locations
Suppose a permitted internal service publishes A and B at priority 10, and C at priority 20. A has weight 70, B has weight 30 and C has weight 0. When both A and B are reachable, a client preferentially selects between them within the first tier using the protocol’s relative weight rules. The zero weight on C does not prevent it serving as fallback: its different priority already means it belongs to another selection tier. Its weight would matter only in relation to other targets in priority 20.
If A refuses a connection, the client can continue through the remaining ordered targets in priority 10; after that tier is unavailable, it can consider C. An application must also decide whether a 429-like rate-limit response counts as a reason to switch targets or a signal to slow down globally. Blindly bypassing server rate limits by hopping through SRV records can undermine fairness and overload controls. Document that decision in the client contract.
Distinguish failover from retrying a committed write
Imagine an agent sends a request to mark a task as complete. The connection drops before the response reaches the agent. Retrying the same action on another SRV target may create a duplicate side effect if the first target already committed it. The problem is not DNS routing; it is an ambiguous outcome. Use a stable operation identifier, an idempotency key where supported, or an authoritative status read to reconcile the first attempt before submitting again.
The safe sequence is to mark the result unknown, consult the system of record, and only retry when the contract makes repetition safe. Two backends may share a database, replicate asynchronously or represent different shards. SRV does not tell you which. A service endpoint is not a certificate of global consistency. In a multi-agent workflow, owner fencing, permission checks and explicit transaction results are separate obligations from selecting the next hostname.
What changes when targets serve different tenants?
A DNS service record set usually describes where a logical service can be reached, but it does not guarantee that every server contains every tenant’s data. If a deployment partitions customers by region, school or organization, routing may need tenant-aware application logic. An agent must not infer that two SRV targets are interchangeable for every document simply because they share the same service label. The service contract should state whether targets are replicas, shards, gateways or independent instances.
If one target returns a tenant-not-found response, randomly trying another target might be appropriate for a documented partitioning strategy, but it could also leak tenant identifiers to an unintended recipient. Authorization must apply before sending sensitive content, and the chosen API audience should be bound to the intended service. Operational observability should record which target handled each request without exposing secrets or personal data in logs.
A clean state machine for a discovering agent
Model the client as several explicit states: validated intent, service-name selection, DNS resolution, SRV parsing, weighted ordered candidate list, target address resolution, transport connection, application authentication, request, verified response and completion. Add failure states for unknown service, explicit unavailable dot target, invalid response, deadline exhaustion, security refusal and ambiguous operation outcome. This representation prevents a loose network library callback from being mistaken for complete task success.
State transitions should be auditable. For example, discovery failure should not transition directly to a success notification just because a stale local cache exists; the cache policy must permit its use, and application verification still follows. Human operators can then diagnose whether a task is blocked by DNS, an invalid certificate, a rejected OAuth token or a downstream application error. Explicit states also reduce the risk of repeated destructive actions when a process restarts.
Parse DNS data as untrusted structured input
DNS responses have wire-format constraints and name-compression rules. A production client should use a maintained DNS resolver library rather than hand-parsing packets inside an agent script. Validate that response records actually match the queried service owner and type, and reject malformed fields without invoking them as commands. Keep all arithmetic within the defined 16-bit bounds for priority and weight, and watch for unexpectedly large response sets or resolver failures.
A maliciously supplied domain name, an unexpected internationalized name or an overly long answer can trigger downstream mistakes if it is concatenated into URLs or shell commands. Do not place target text into a shell string; use APIs that accept structured hostname and port fields. Treat DNS text as data and maintain a clear boundary between discovery and execution. Logging should escape untrusted control characters so a fake DNS record cannot forge operational log entries.
Timeouts must be bounded at every network stage
There is not one universal timeout. An agent may need limits for DNS lookup, address resolution, TCP connection, TLS handshake, application request and overall task completion. A single huge timeout on a failed target can consume the deadline before the next weighted or lower-priority server is tried. Conversely, excessively short connect attempts can misclassify a healthy but distant endpoint as unreachable, especially during transient congestion.
Use an overall monotonic deadline and per-stage budgets based on observations. Record timeout rates per candidate and monitor both median and tail latency. Retries should include backoff and jitter when repeated failures could amplify an outage. After the overall deadline, make an incomplete outcome visible to the caller; do not claim that the action was performed. For a calendar-writing agent, reconcile any prior request with the authoritative calendar before later runs attempt the same mutation.
How to avoid DNS refresh storms
A fleet of agents that all refresh service discovery at precisely the same second can create bursts against resolvers and downstream targets. Cache results according to permitted TTL behavior, coalesce concurrent identical lookups and spread optional proactive refreshes with jitter. But do not invent a longer lifetime for security-critical answers solely to reduce lookup traffic. DNS caching policies may also include negative caching and resolver-level limits beyond one application’s control.
Suppose 500 workers restart simultaneously and each independently queries the same SRV name. That is 500 application-initiated lookups, though a shared resolver may answer many from cache. Coalescing those workers behind a local service-discovery component can greatly reduce redundant client activity, but it introduces a shared dependency that must itself remain available. A fair benchmark counts real upstream queries, cache hits and recovery delays instead of assuming every application call reaches the authoritative DNS server.
An operational test for priority and weight behavior
Create a controlled test DNS zone and publish three SRV targets whose services return distinct harmless identifiers. Keep two targets at priority 10 with different weights and one at priority 20. Run many independent fresh connections and record first choices, successful connections and failure paths. Repeated connection attempts are different from requests on an existing persistent connection, so test them separately. Introduce failures one at a time to verify that same-tier peers are tried before the lower-preference tier.
Compare observed target choice with the library’s documented algorithm; do not demand exact nominal weight percentages in a small sample. Verify that a zero-weight record remains a valid fallback, that the dot target is treated as unavailable, and that changing TTL does not make the client reuse stale addresses indefinitely. Include malformed packets, resolver timeouts and negative responses. This test measures a discovery implementation, not the accuracy or intelligence of the agent’s language model.
A complete failure-injection exercise
Start with a fresh SRV lookup that returns A and B in the preferred tier and C as fallback. First make A refuse connections. Next keep A reachable but present a TLS certificate that fails the application’s identity check. Then let B accept a request but drop its reply after recording a side effect. Finally disable C entirely. Each failure tests a different boundary: reachability, identity, ambiguous commitment and exhaustion of options. The proper outcomes should not all be labeled retry.
The identity failure must not be bypassed by disabling verification. The ambiguous write must trigger reconciliation instead of unbounded replay. The all-targets-down case must return a finite, truthful failure. Audit logs should retain a request identifier, target, state transition and elapsed duration while excluding bearer tokens and personal payloads. A system that passes only the first refused-connection test has not proved safe failover.
Observability metrics with explicit denominators
Useful measurements include the number of SRV lookup attempts, successful DNS answers, explicit service-unavailable answers, DNSSEC failures, endpoints tried, authenticated connections, and application requests completed. A 99% DNS success rate over 1,000 lookups means 990 successful answers, not 990 successful downstream actions. Separately, if 920 of those 990 resolutions lead to an authenticated application response, that conditional completion rate is 920/990, approximately 92.9%. These are illustrative numbers, not observed data from a deployed service.
Report both counts and conditional rates so an apparent improvement is not merely a changed denominator. Distinguish a resolved target from a completed user task, and distinguish benign retries from unintended repeated writes. Track tail recovery time after target failure, because a service can have excellent steady-state resolution and still recover too slowly during an outage. Segment statistics by service and relevant region, not just one global percentage.
Security and privacy boundaries in a school service
Consider a school assistant that accesses a permitted timetable endpoint. DNS discovery can identify redundant service gateways, but the assistant should send a student’s information only after obtaining the correct service audience, verifying the endpoint and checking the user’s authorization. A public question from a student must not be able to change the SRV lookup suffix to an arbitrary domain. The assistant can use a fixed service identity and a controlled mapping from permitted schools or tenants to destinations.
Private details should not be written into DNS labels as improvised lookup keys. Standard DNS resolution can expose query names to resolvers and infrastructure operators. Store only necessary operational records and avoid logging query payloads in discovery traces. If the service is unavailable, the assistant can explain that the live timetable could not be verified; it should not fabricate meeting times or substitute a cached result without clearly stating its age and authority.
Changed-context transfer: a weighted tier becomes unreachable
Suppose the original set is A at priority 5 and weight 80, B at priority 5 and weight 20, and C at priority 15 and weight 100. A and B are tried as the preferred tier; C is not preferred simply because its weight is 100. Now assume A is offline but B still accepts connections. The correct design continues to B before treating C as the normal fallback. If both A and B become unreachable, the client can attempt C subject to authentication and the remaining deadline.
What if C’s weight changes from 100 to 1 while it remains the only record at priority 15? That does not create a 99% drop in its probability of being reached as a fallback; its weight is relative only to records with the same priority. With no same-tier competitor, weight has no intended traffic-splitting role. This transfer problem exposes a common but consequential confusion between global load fractions and within-tier ordering.
Changed-context transfer: total retry time exceeds the deadline
An agent has a 1,500 ms deadline. DNS plus initial address resolution take 120 ms, and an application identity check takes 180 ms on each reached target. The first target fails after a 500 ms connection attempt, so 880 ms remain. The second target connects in 300 ms and then requires 180 ms for its identity check, leaving 400 ms for application work and a response. If the application contract requires up to 600 ms, completion cannot be guaranteed within the remaining budget.
The repair is not to suppress the identity check or mark the action complete early. The agent may shorten upstream work, use a verified faster fallback, request a larger deadline from the caller or return a pending/failed outcome according to policy. Explicit arithmetic prevents operational haste from becoming a silent trust bypass. The example uses milliseconds of sequential elapsed time; overlapping operations would require a different critical-path calculation.
When not to use SRV discovery
Do not add SRV records merely to make an architecture sound distributed. If a single approved HTTPS origin already has suitable load balancing, adding client-side service selection may create another layer of DNS caches and failover logic without solving a real problem. If the service protocol has no defined SRV discovery convention, inventing a lookup name can reduce interoperability. If a workload needs rapidly changing load information, DNS static weights are not a complete replacement for health-aware routing.
SRV is attractive when a protocol explicitly supports it and clients need a discoverable host-and-port service set. Its usefulness is bounded by valid DNS resolution, correct selection and safe application behavior. The design should remain comprehensible when every target fails, when a target is malicious, when a retry’s outcome is unknown and when the network is partitioned. Adding more DNS entries does not remove these fundamental distributed-systems questions.
Questions readers commonly ask
Does priority 0 mean inactive? No; lower priority numbers are preferred, and zero is a valid highest-preference value. Does weight 0 mean forbidden? No; it can remain selectable or serve as a fallback within its tier under RFC rules. Does a 300-second TTL guarantee five minutes of uptime? No, it describes DNS caching. Does SRV return an IP address? The target is a hostname, which normally needs address resolution. Does the port always equal the default protocol port? No; the SRV port is explicit.
Can a client assume an SRV host is trustworthy? No; use DNS security where available and proper endpoint authentication and authorization. Does SRV force every HTTP client to use it? No; follow the applicable service specification. Does a successful lookup mean the agent has performed a requested action? No; confirm application outcomes. Is it evidence that artificial superintelligence already exists? No; it is ordinary network engineering suitable for currently deployed software agents.
Original standards and verified learning pathways
The normative starting point is the IETF specification RFC 2782: A DNS RR for Specifying the Location of Services (DNS SRV), February 2000: https://www.rfc-editor.org/rfc/rfc2782. Check its service-name structure, 16-bit priority and weight fields, weighted selection procedure, target-name requirements, and explicit unavailable dot target. For related modern service-binding use cases, read RFC 9460: SVCB and HTTPS Resource Records, November 2023: https://www.rfc-editor.org/rfc/rfc9460. These are different protocol specifications; do not mix their algorithms.
For trustworthy DNS answers and failure distinctions, continue with Agent DNSSEC Validation — Trust Chains, Bogus Answers and Signed Denials. For finite budgets across chained network work, see Agent gRPC Deadlines — Status Codes, Propagation and Ambiguous Writes. Return to the How Super Intelligence Works hub for the broader engineering pathway. None of these resources establishes that artificial superintelligence currently exists.