4. DNS サーバーの動作
4.1. 権威サーバー
SVCB クエリに応答する際、権威 DNS サーバーは、ゾーン内にある任意の TargetName に対する A、AAAA、および SVCB レコードを追加セクション (Additional section) に返すべきです (SHOULD)。ゾーンが署名されている場合、サーバーは、追加セクションにこれらのレコードの存在または非存在を認証する DNSSEC レコードも含めるべきです (SHOULD)。
例外については、セクション 4.4 を参照してください。
4.2. 再帰リゾルバー
再帰リゾルバーが SVCB を認識しているかどうかに関わらず、未知の RR タイプ [RFC3597] に使用される通常の応答構築プロセスが応答の回答セクション (Answer section) を生成します。SVCB を認識している再帰リゾルバーは、以下のように応答の追加セクションに追加の有用な情報を組み込むことにより、セクション 3 の手順を最小の全体的なレイテンシーで実行するようクライアントを支援すべきです (SHOULD)：
-
SVCB 解決の結果を組み込みます。再帰リゾルバーのローカルチェーン長制限（クライアントの制限とは異なる場合があります）に達した場合は、終了します。
-
解決された SVCB レコードのいずれかがエイリアスモード (AliasMode) である場合、それらの中から 1 つをランダムに選択し、その TargetName に対して SVCB、A、および AAAA レコードを解決します。
-
SVCB レコードが解決された場合は、ステップ 1 に進みます。
-
そうでない場合は、A および AAAA 解決の結果を組み込み、終了します。
-
-
解決されたすべての SVCB レコードがサービスモード (ServiceMode) です。各 TargetName（または TargetName が "." の場合は所有者名）に対して A および AAAA クエリを解決し、すべての結果を組み込み、終了します。
この手順において、「解決」とは、その RRset に対するクエリを処理しているかのように、リゾルバーの通常の再帰解決手順を意味します。これには、リゾルバーが通常従う任意のエイリアス（例：CNAME、DNAME [DNAME]）に従うことが含まれます。追加レコードの取得におけるエラーまたは異常は、このプロセスを終了させる可能性がありますが (MAY)、それ自体がリゾルバーに失敗応答を送信させてはなりません (MUST NOT)。
ループを軽減するために再帰リゾルバーが実装すべき追加の保護措置については、セクション 2.4.2 を参照してください。
この手順の可能な最適化については、セクション 5.2 を参照してください。
4.2.1. DNS64
DNS64 リゾルバーは、A レコードのみを持つ名前に対する AAAA クエリの応答を合成します（[RFC6147] のセクション 5.1.7）。SVCB 対応の DNS64 リゾルバーは、追加セクションに含めるための TargetName の AAAA レコードを解決する際に同じ合成ロジックを適用すべきであり (SHOULD)、このセクションから A レコードを省略してもかまいません (MAY)（セクション 4.2 のステップ 2）。
DNS64 リゾルバーは、AAAA 合成ロジックを SvcParams 内の IP ヒント（セクション 7.3）に外挿してはなりません (MUST NOT)。IP ヒントを変更すると SVCB レコードの DNSSEC 検証が破損し、上記の推奨事項が実装されている場合にパフォーマンスが向上することはありません。
4.3. 一般要件
再帰リゾルバーは、認識されていない SvcParamKey を持つ SVCB レコードを伝達できなければなりません (MUST)。リゾルバーは、内容が無効であっても、レコードの SvcParams 部分全体を不透明として扱うことでこれを達成してもかまいません (MAY)。認識された SvcParamKey の後に SvcParam の仕様に従って無効な値が続く場合、再帰リゾルバーはレコードを返す代わりに SERVFAIL などのエラーを報告してもかまいません (MAY)。実装によって解釈が異なる可能性があるか、将来的に追加の許可された値が追加される可能性がある複雑な値タイプ（例：URI または "alpn"）については、リゾルバーは検証を指定された制約に制限すべきです (SHOULD)。
DNSSEC OK ビット [RFC3225] を含むクエリに応答する場合、DNSSEC 対応の再帰および権威 DNS サーバーは、追加セクションの各 RRset に、その RRset を回答として提供する際に送信するのと同じ DNSSEC 関連レコード（例：RRSIG、NSEC、NSEC3）を添付しなければなりません (MUST)。
[RFC2181] のセクション 5.4.1 によれば、「追加データセクションから受信およびキャッシュされた未認証 RR は、受信したクエリへの回答として返されることがないようにキャッシュすべきではありません。適切な場合には、追加情報として返されてもかまいません。」したがって、再帰リゾルバーは、追加セクションの応答を埋めるために使用するために追加セクションからのレコードをキャッシュしてもかまいませんし (MAY)、DNSSEC によって認証されている場合は一般的な使用のためにキャッシュしてもかまいません (MAY)。
4.4. EDNS クライアントサブネット (ECS)
EDNS クライアントサブネット (ECS) オプション [RFC7871] により、再帰リゾルバーは特定のクライアント IP 範囲に適した IP アドレスを要求できます。SVCB レコードには IP アドレス（ipv*hint SvcParams 内）が含まれるか、ユーザーをサブネット固有の TargetName に誘導する可能性があるため、再帰リゾルバーは、A/AAAA クエリと同じ ECS オプションを SVCB クエリに含めるべきです (SHOULD)。
[RFC7871] のセクション 7.3.1 によれば、「[追加セクション] からの任意のレコードは、ネットワークに結び付けられてはなりません (MUST NOT)。」したがって、QTYPE が SVCB 互換である応答を処理する際、リゾルバーは追加セクション内の任意のレコードを SOURCE PREFIX-LENGTH がゼロに設定され、SCOPE PREFIX-LENGTH が ECS オプションで指定されたものとして扱うべきです (SHOULD)。これらのレコードが SOURCE PREFIX-LENGTH をゼロに設定するスタブリゾルバーによる使用に適していない場合、権威サーバーはこれらのレコードを省略しなければなりません (MUST)。これにより、リゾルバーは適切に調整された ECS を受信できるフォローアップクエリを実行することになります。（これは、[RFC7871] のセクション 7.2.1 で議論されている ECS オプションを使用した CNAME の使用に類似しています。）
追加レコードを省略する権威サーバーは、セクション 10.2 のアドバイスに従うことにより、フォローアップクエリの追加レイテンシーを回避できます。