Keep fallback, caching and trust separate

A service-location answer is a routing hint whose use and trust depend on the application and DNS context.

• If the generic recommended usage procedure has no matching positive SRV result, it describes an A lookup for the original target domain and use of the application’s service/transport information (pages 6–7). This historical fallback is not permission to ignore a single Target dot, bypass DNS errors indiscriminately or override an application-specific discovery specification.
• Target MUST have address records and MUST NOT be an alias (page 4). The local teaching validator rejects a selected CNAME target rather than quietly treating it as a compliant SRV endpoint. That local stop does not invent a new DNS error code or cover complete DNS response validation.
• Weight is intended for static selection information, not dynamic server-load balancing (pages 5–6). Cached records remain subject to DNS TTLs; changing live CPU use does not update a cached weight. A larger weight does not prove lower latency or healthy service.
• The administrator advice’s 512-byte reply discussion is historical context, not a current universal DNS packet limit. EDNS and TCP behavior belong to their specifications; this guide does not enforce a synthetic 512-byte SRV cutoff or claim to implement truncated-response handling.
• The security considerations (pages 9–10) note that DNS spoofers can supply false ports as well as names and addresses. An SRV answer does not by itself provide confidentiality, prove server identity or authorize access. Apply the relevant application and DNS security rules; no new mandatory TLS or DNSSEC requirement is invented here.
• RFC 2782 obsoletes experimental RFC 2052. Its notable naming change adds underscores to service/protocol labels (Changes from RFC 2052, page 9). RFC 6335 and RFC 8553 update naming/registration guidance, while the published SRV selection and field rules remain the subject of this guide.