4. DNS-Serververhalten
4.1. Autoritative Server
Bei der Beantwortung einer SVCB-Abfrage SOLLTEN (SHOULD) autoritative DNS-Server A-, AAAA- und SVCB-Einträge im zusätzlichen Abschnitt (Additional section) für alle TargetNames zurückgeben, die sich in der Zone befinden. Wenn die Zone signiert ist, SOLLTE (SHOULD) der Server auch DNSSEC-Einträge in den zusätzlichen Abschnitt aufnehmen, die die Existenz oder Nichtexistenz dieser Einträge authentifizieren.
Siehe Abschnitt 4.4 für Ausnahmen.
4.2. Rekursive Resolver
Unabhängig davon, ob der rekursive Resolver SVCB unterstützt oder nicht, erzeugt der normale Antwortkonstruktionsprozess für unbekannte RR-Typen [RFC3597] den Antwortabschnitt (Answer section) der Antwort. Rekursive Resolver, die SVCB unterstützen, SOLLTEN (SHOULD) dem Client helfen, das Verfahren in Abschnitt 3 mit minimaler Gesamtlatenz auszuführen, indem sie zusätzliche nützliche Informationen in den zusätzlichen Abschnitt der Antwort wie folgt aufnehmen:
-
Die Ergebnisse der SVCB-Auflösung einbeziehen. Wenn die lokale Kettenlängenbeschränkung des rekursiven Resolvers (die sich von der Beschränkung des Clients unterscheiden kann) erreicht wurde, beenden.
-
Wenn einer der aufgelösten SVCB-Einträge im Alias-Modus (AliasMode) ist, wählen Sie einen davon zufällig aus und lösen Sie SVCB-, A- und AAAA-Einträge für dessen TargetName auf.
-
Wenn SVCB-Einträge aufgelöst werden, gehen Sie zu Schritt 1.
-
Andernfalls beziehen Sie die Ergebnisse der A- und AAAA-Auflösung ein und beenden Sie.
-
-
Alle aufgelösten SVCB-Einträge befinden sich im Service-Modus (ServiceMode). Lösen Sie A- und AAAA-Abfragen für jeden TargetName auf (oder für den Eigentümernamen, wenn TargetName "." ist), beziehen Sie alle Ergebnisse ein und beenden Sie.
In diesem Verfahren bedeutet "auflösen" das gewöhnliche rekursive Auflösungsverfahren des Resolvers, als ob er eine Abfrage für dieses RRset verarbeiten würde. Dies schließt das Folgen aller Aliase ein, denen der Resolver normalerweise folgen würde (z. B. CNAME, DNAME [DNAME]). Fehler oder Anomalien beim Erhalt zusätzlicher Einträge KÖNNEN (MAY) dazu führen, dass dieser Prozess beendet wird, DÜRFEN jedoch NICHT (MUST NOT) selbst dazu führen, dass der Resolver eine Fehlerantwort sendet.
Siehe Abschnitt 2.4.2 für zusätzliche Schutzmaßnahmen, die rekursive Resolver implementieren sollten, um Schleifen zu vermeiden.
Siehe Abschnitt 5.2 für mögliche Optimierungen dieses Verfahrens.
4.2.1. DNS64
DNS64-Resolver synthetisieren Antworten auf AAAA-Abfragen für Namen, die nur einen A-Eintrag haben (Abschnitt 5.1.7 von [RFC6147]). SVCB-fähige DNS64-Resolver SOLLTEN (SHOULD) dieselbe Syntheselogik anwenden, wenn sie AAAA-Einträge für den TargetName zur Aufnahme in den zusätzlichen Abschnitt auflösen (Schritt 2 in Abschnitt 4.2), und KÖNNEN (MAY) die A-Einträge aus diesem Abschnitt weglassen.
DNS64-Resolver DÜRFEN NICHT (MUST NOT) die AAAA-Syntheselogik auf die IP-Hinweise in den SvcParams extrapolieren (Abschnitt 7.3). Die Änderung der IP-Hinweise würde die DNSSEC-Validierung für den SVCB-Eintrag brechen und würde die Leistung nicht verbessern, wenn die obige Empfehlung implementiert wird.
4.3. Allgemeine Anforderungen
Rekursive Resolver MÜSSEN (MUST) in der Lage sein, SVCB-Einträge mit nicht erkannten SvcParamKeys zu übermitteln. Resolver KÖNNEN (MAY) dies erreichen, indem sie den gesamten SvcParams-Teil des Eintrags als opak behandeln, selbst wenn der Inhalt ungültig ist. Wenn einem erkannten SvcParamKey ein Wert folgt, der gemäß der Spezifikation des SvcParam ungültig ist, KANN (MAY) ein rekursiver Resolver einen Fehler wie SERVFAIL melden, anstatt den Eintrag zurückzugeben. Bei komplexen Werttypen, deren Interpretation zwischen Implementierungen unterschiedlich sein kann oder für die zukünftig zusätzliche zulässige Werte hinzugefügt werden können (z. B. URIs oder "alpn"), SOLLTEN (SHOULD) Resolver die Validierung auf die angegebenen Einschränkungen beschränken.
Bei der Beantwortung einer Abfrage, die das DNSSEC OK-Bit [RFC3225] enthält, MÜSSEN (MUST) DNSSEC-fähige rekursive und autoritative DNS-Server jeden RRset im zusätzlichen Abschnitt mit denselben DNSSEC-bezogenen Einträgen begleiten, die sie senden würden, wenn sie dieses RRset als Antwort bereitstellen (z. B. RRSIG, NSEC, NSEC3).
Gemäß Abschnitt 5.4.1 von [RFC2181] "sollten nicht authentifizierte RRs, die aus dem zusätzlichen Datenabschnitt empfangen und zwischengespeichert wurden, nicht so zwischengespeichert werden, dass sie jemals als Antworten auf eine empfangene Abfrage zurückgegeben würden. Sie können gegebenenfalls als zusätzliche Informationen zurückgegeben werden." Rekursive Resolver KÖNNEN (MAY) daher Einträge aus dem zusätzlichen Abschnitt zwischenspeichern, um sie zum Befüllen der Antworten des zusätzlichen Abschnitts zu verwenden, und KÖNNEN (MAY) sie für die allgemeine Verwendung zwischenspeichern, wenn sie durch DNSSEC authentifiziert sind.
4.4. EDNS Client Subnet (ECS)
Die EDNS Client Subnet (ECS)-Option [RFC7871] ermöglicht es rekursiven Resolvern, IP-Adressen anzufordern, die für einen bestimmten Client-IP-Bereich geeignet sind. SVCB-Einträge können IP-Adressen enthalten (in ipv*hint SvcParams) oder Benutzer zu einem subnetzspezifischen TargetName leiten, daher SOLLTEN (SHOULD) rekursive Resolver dieselbe ECS-Option in SVCB-Abfragen wie in A/AAAA-Abfragen einbeziehen.
Gemäß Abschnitt 7.3.1 von [RFC7871] "DÜRFEN (MUST NOT) alle Einträge aus [dem zusätzlichen Abschnitt] nicht an ein Netzwerk gebunden sein." Dementsprechend SOLLTEN (SHOULD) Resolver beim Verarbeiten einer Antwort, deren QTYPE SVCB-kompatibel ist, alle Einträge im zusätzlichen Abschnitt so behandeln, als ob SOURCE PREFIX-LENGTH auf Null gesetzt wäre und SCOPE PREFIX-LENGTH wie in der ECS-Option angegeben. Autoritative Server MÜSSEN (MUST) solche Einträge weglassen, wenn sie nicht für die Verwendung durch Stub-Resolver geeignet sind, die SOURCE PREFIX-LENGTH auf Null setzen. Dies wird dazu führen, dass der Resolver eine Folgeabfrage durchführt, die ein ordnungsgemäß angepasstes ECS erhalten kann. (Dies ähnelt der Verwendung von CNAME mit der ECS-Option, wie in [RFC7871], Abschnitt 7.2.1 diskutiert.)
Autoritative Server, die zusätzliche Einträge weglassen, können die zusätzliche Latenz einer Folgeabfrage vermeiden, indem sie den Rat in Abschnitt 10.2 befolgen.