Resolve targets and handle failure

Use the target’s address and advertised port, and distinguish explicit unavailability from missing SRV data.

• The recommended usage procedure is SHOULD (Usage rules, pages 6–7). The client MUST parse all RRs in the reply. A positive NOERROR answer with matching SRV records enters the SRV ordering path; a single SRV RR whose Target is the root name dot means abort: the service is explicitly unavailable.
• For a candidate, use available address records from Additional Data or query for Target’s address records. Returning them in Additional Data is urged, not required. If addresses are missing for targets the client may connect to, it MUST look them up (Notes, page 7). SRV does not make additional-address presence mandatory.
• Try the addresses of each selected target using the chosen transport and that target’s Port. A and AAAA are address records in the RFC’s terminology. An address is not the SRV owner name or a replacement for the advertised port.
• The drawing chooses one address per target to keep failover visible. Ordered candidates B,A,Z have priority 10; C has priority 20. If B’s address fails, try A and Z; only after all reachable attempts in the lower-numbered tier fail does this example try C. If a candidate succeeds, no later candidate is required by this retry list.
• Each real target can have multiple addresses; the usage procedure tries each address before advancing that target. A DNS answer alone does not prove reachability. The drawing’s failure marks are chosen connection results, not actual probes or a health guarantee.
• Explicit single Target dot is different from absence of usable SRV data. It is not an IP address, not localhost and not an instruction to fall back to the original domain. The fallback branch for absent SRV is discussed separately in the last chapter.