3.1. Handling Resolution Failures (Gestione dei fallimenti di risoluzione)

Se le risposte DNS sono protette crittograficamente (ad esempio, utilizzando DNSSEC o TLS [DoT] [DoH]) e la risoluzione SVCB fallisce a causa di un errore di autenticazione, risposta SERVFAIL, errore di trasporto o timeout, il client DOVREBBE (SHOULD) abbandonare il suo tentativo di raggiungere il servizio, anche se il client è SVCB-optional. Altrimenti, un attaccante attivo potrebbe montare un attacco di downgrade negando all'utente l'accesso ai SvcParams.

Un errore SERVFAIL può verificarsi se il dominio è firmato DNSSEC, il resolver ricorsivo sta eseguendo la validazione DNSSEC e l'attaccante si trova tra il resolver ricorsivo e il server DNS autorevole. Un errore di trasporto o timeout può verificarsi se un attaccante attivo tra il client e il resolver ricorsivo sta selettivamente scartando query o risposte SVCB, in base alle loro dimensioni o altri pattern osservabili.

Se il client applica la validazione DNSSEC sulle risposte A/AAAA, DOVREBBE (SHOULD) applicare la stessa politica di validazione a SVCB. Altrimenti, un attaccante potrebbe sconfiggere la protezione A/AAAA falsificando risposte SVCB che dirigono il client verso altri indirizzi IP.

Se le risposte DNS non sono protette crittograficamente, i client POSSONO (MAY) trattare il fallimento della risoluzione SVCB come fatale o non fatale.

Se il client non è in grado di completare la risoluzione SVCB a causa del suo limite di lunghezza della catena, il client DEVE (MUST) tornare all'endpoint di autorità, come se il record SVCB del servizio non esistesse.