4. DNS Server Behavior
4.1. Authoritative Servers
When replying to a SVCB query, authoritative DNS servers SHOULD return A, AAAA, and SVCB records in the Additional section for any TargetNames that are in the zone. If the zone is signed, the server SHOULD also include DNSSEC records authenticating the existence or nonexistence of these records in the Additional section.
See Section 4.4 for exceptions.
4.2. Recursive Resolvers
Whether the recursive resolver is aware of SVCB or not, the normal response construction process used for unknown RR types [RFC3597] generates the Answer section of the response. Recursive resolvers that are aware of SVCB SHOULD help the client to execute the procedure in Section 3 with minimum overall latency by incorporating additional useful information into the Additional section of the response as follows:
-
Incorporate the results of SVCB resolution. If the recursive resolver's local chain length limit (which may be different from the client's limit) has been reached, terminate.
-
If any of the resolved SVCB records are in AliasMode, choose one of them at random, and resolve SVCB, A, and AAAA records for its TargetName.
-
If any SVCB records are resolved, go to Step 1.
-
Otherwise, incorporate the results of A and AAAA resolution, and terminate.
-
-
All the resolved SVCB records are in ServiceMode. Resolve A and AAAA queries for each TargetName (or for the owner name if TargetName is "."), incorporate all the results, and terminate.
In this procedure, "resolve" means the resolver's ordinary recursive resolution procedure, as if processing a query for that RRset. This includes following any aliases that the resolver would ordinarily follow (e.g., CNAME, DNAME [DNAME]). Errors or anomalies in obtaining additional records MAY cause this process to terminate but MUST NOT themselves cause the resolver to send a failure response.
See Section 2.4.2 for additional safeguards for recursive resolvers to implement to mitigate loops.
See Section 5.2 for possible optimizations of this procedure.
4.2.1. DNS64
DNS64 resolvers synthesize responses to AAAA queries for names that only have an A record (Section 5.1.7 of [RFC6147]). SVCB-aware DNS64 resolvers SHOULD apply the same synthesis logic when resolving AAAA records for the TargetName for inclusion in the Additional section (Step 2 in Section 4.2) and MAY omit the A records from this section.
DNS64 resolvers MUST NOT extrapolate the AAAA synthesis logic to the IP hints in the SvcParams (Section 7.3). Modifying the IP hints would break DNSSEC validation for the SVCB record and would not improve performance when the above recommendation is implemented.
4.3. General Requirements
Recursive resolvers MUST be able to convey SVCB records with unrecognized SvcParamKeys. Resolvers MAY accomplish this by treating the entire SvcParams portion of the record as opaque, even if the contents are invalid. If a recognized SvcParamKey is followed by a value that is invalid according to the SvcParam's specification, a recursive resolver MAY report an error such as SERVFAIL instead of returning the record. For complex value types whose interpretation might differ between implementations or have additional future allowed values added (e.g., URIs or "alpn"), resolvers SHOULD limit validation to specified constraints.
When responding to a query that includes the DNSSEC OK bit [RFC3225], DNSSEC-capable recursive and authoritative DNS servers MUST accompany each RRset in the Additional section with the same DNSSEC-related records that they would send when providing that RRset as an Answer (e.g., RRSIG, NSEC, NSEC3).
According to Section 5.4.1 of [RFC2181], "Unauthenticated RRs received and cached from ... the additional data section ... should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate." Recursive resolvers therefore MAY cache records from the Additional section for use in populating Additional section responses and MAY cache them for general use if they are authenticated by DNSSEC.
4.4. EDNS Client Subnet (ECS)
The EDNS Client Subnet (ECS) option [RFC7871] allows recursive resolvers to request IP addresses that are suitable for a particular client IP range. SVCB records may contain IP addresses (in ipv*hint SvcParams) or direct users to a subnet-specific TargetName, so recursive resolvers SHOULD include the same ECS option in SVCB queries as in A/AAAA queries.
According to Section 7.3.1 of [RFC7871], "Any records from [the Additional section] MUST NOT be tied to a network." Accordingly, when processing a response whose QTYPE is SVCB-compatible, resolvers SHOULD treat any records in the Additional section as having SOURCE PREFIX-LENGTH set to zero and SCOPE PREFIX-LENGTH as specified in the ECS option. Authoritative servers MUST omit such records if they are not suitable for use by any stub resolvers that set SOURCE PREFIX-LENGTH to zero. This will cause the resolver to perform a follow-up query that can receive a properly tailored ECS. (This is similar to the usage of CNAME with the ECS option as discussed in [RFC7871], Section 7.2.1.)
Authoritative servers that omit Additional records can avoid the added latency of a follow-up query by following the advice in Section 10.2.