3.1. Handling Resolution Failures (Gestion des échecs de résolution)

Si les réponses DNS sont protégées cryptographiquement (par exemple, en utilisant DNSSEC ou TLS [DoT] [DoH]) et que la résolution SVCB échoue en raison d'une erreur d'authentification, d'une réponse SERVFAIL, d'une erreur de transport ou d'un délai d'expiration, le client DEVRAIT (SHOULD) abandonner sa tentative d'atteindre le service, même si le client est SVCB-optional. Sinon, un attaquant actif pourrait monter une attaque de rétrogradation en refusant à l'utilisateur l'accès aux SvcParams.

Une erreur SERVFAIL peut se produire si le domaine est signé DNSSEC, le résolveur récursif effectue la validation DNSSEC, et l'attaquant se trouve entre le résolveur récursif et le serveur DNS autoritaire. Une erreur de transport ou un délai d'expiration peut se produire si un attaquant actif entre le client et le résolveur récursif abandonne sélectivement les requêtes ou réponses SVCB, en fonction de leur taille ou d'autres modèles observables.

Si le client applique la validation DNSSEC sur les réponses A/AAAA, il DEVRAIT (SHOULD) appliquer la même politique de validation à SVCB. Sinon, un attaquant pourrait contourner la protection A/AAAA en forgeant des réponses SVCB qui dirigent le client vers d'autres adresses IP.

Si les réponses DNS ne sont pas protégées cryptographiquement, les clients PEUVENT (MAY) traiter l'échec de résolution SVCB comme fatal ou non fatal.

Si le client est incapable de terminer la résolution SVCB en raison de sa limite de longueur de chaîne, le client DOIT (MUST) revenir au point de terminaison d'autorité, comme si l'enregistrement SVCB du service n'existait pas.