4. Comportamento del server DNS
4.1. Server autoritativi
Quando rispondono a una query SVCB, i server DNS autoritativi DOVREBBERO (SHOULD) restituire i record A, AAAA e SVCB nella sezione aggiuntiva (Additional section) per qualsiasi TargetName che si trovi nella zona. Se la zona è firmata, il server DOVREBBE (SHOULD) anche includere i record DNSSEC che autenticano l'esistenza o la non esistenza di questi record nella sezione aggiuntiva.
Vedere la sezione 4.4 per le eccezioni.
4.2. Resolver ricorsivi
Indipendentemente dal fatto che il resolver ricorsivo sia a conoscenza di SVCB o meno, il normale processo di costruzione della risposta utilizzato per i tipi di RR sconosciuti [RFC3597] genera la sezione di risposta (Answer section) della risposta. I resolver ricorsivi che sono a conoscenza di SVCB DOVREBBERO (SHOULD) aiutare il client a eseguire la procedura nella sezione 3 con la minima latenza complessiva incorporando informazioni aggiuntive utili nella sezione aggiuntiva della risposta come segue:
-
Incorporare i risultati della risoluzione SVCB. Se il limite di lunghezza della catena locale del resolver ricorsivo (che può essere diverso dal limite del client) è stato raggiunto, terminare.
-
Se uno qualsiasi dei record SVCB risolti è in modalità alias (AliasMode), sceglierne uno casualmente e risolvere i record SVCB, A e AAAA per il suo TargetName.
-
Se vengono risolti record SVCB, andare al passaggio 1.
-
Altrimenti, incorporare i risultati della risoluzione A e AAAA e terminare.
-
-
Tutti i record SVCB risolti sono in modalità servizio (ServiceMode). Risolvere le query A e AAAA per ciascun TargetName (o per il nome del proprietario se TargetName è "."), incorporare tutti i risultati e terminare.
In questa procedura, "risolvere" significa la normale procedura di risoluzione ricorsiva del resolver, come se stesse elaborando una query per quel RRset. Ciò include il seguire qualsiasi alias che il resolver seguirebbe normalmente (ad esempio, CNAME, DNAME [DNAME]). Gli errori o le anomalie nell'ottenimento di record aggiuntivi POSSONO (MAY) causare la terminazione di questo processo ma NON DEVONO (MUST NOT) essi stessi causare l'invio di una risposta di fallimento da parte del resolver.
Vedere la sezione 2.4.2 per ulteriori misure di salvaguardia che i resolver ricorsivi devono implementare per mitigare i loop.
Vedere la sezione 5.2 per possibili ottimizzazioni di questa procedura.
4.2.1. DNS64
I resolver DNS64 sintetizzano risposte alle query AAAA per nomi che hanno solo un record A (sezione 5.1.7 di [RFC6147]). I resolver DNS64 che supportano SVCB DOVREBBERO (SHOULD) applicare la stessa logica di sintesi quando risolvono i record AAAA per il TargetName per l'inclusione nella sezione aggiuntiva (passaggio 2 nella sezione 4.2) e POSSONO (MAY) omettere i record A da questa sezione.
I resolver DNS64 NON DEVONO (MUST NOT) estrapolare la logica di sintesi AAAA agli hint IP nei SvcParams (sezione 7.3). La modifica degli hint IP violerebbe la convalida DNSSEC per il record SVCB e non migliorerebbe le prestazioni quando viene implementata la raccomandazione sopra indicata.
4.3. Requisiti generali
I resolver ricorsivi DEVONO (MUST) essere in grado di trasmettere record SVCB con SvcParamKey non riconosciute. I resolver POSSONO (MAY) ottenere questo trattando l'intera porzione SvcParams del record come opaca, anche se il contenuto non è valido. Se una SvcParamKey riconosciuta è seguita da un valore non valido secondo la specifica del SvcParam, un resolver ricorsivo PUÒ (MAY) segnalare un errore come SERVFAIL invece di restituire il record. Per tipi di valore complessi la cui interpretazione potrebbe differire tra le implementazioni o per i quali potrebbero essere aggiunti valori futuri aggiuntivi consentiti (ad esempio, URI o "alpn"), i resolver DOVREBBERO (SHOULD) limitare la convalida ai vincoli specificati.
Quando si risponde a una query che include il bit DNSSEC OK [RFC3225], i server DNS ricorsivi e autoritativi con capacità DNSSEC DEVONO (MUST) accompagnare ciascun RRset nella sezione aggiuntiva con gli stessi record correlati a DNSSEC che invierebbero quando forniscono quel RRset come risposta (ad esempio, RRSIG, NSEC, NSEC3).
Secondo la sezione 5.4.1 di [RFC2181], "Gli RR non autenticati ricevuti e memorizzati nella cache dalla sezione dati aggiuntiva non dovrebbero essere memorizzati nella cache in modo tale che possano essere restituiti come risposte a una query ricevuta. Possono essere restituiti come informazioni aggiuntive dove appropriato." I resolver ricorsivi POSSONO (MAY) quindi memorizzare nella cache i record dalla sezione aggiuntiva da utilizzare per popolare le risposte della sezione aggiuntiva e POSSONO (MAY) memorizzarli nella cache per uso generale se sono autenticati da DNSSEC.
4.4. EDNS Client Subnet (ECS)
L'opzione EDNS Client Subnet (ECS) [RFC7871] consente ai resolver ricorsivi di richiedere indirizzi IP adatti a un particolare intervallo di IP client. I record SVCB possono contenere indirizzi IP (nei SvcParams ipv*hint) o indirizzare gli utenti a un TargetName specifico della subnet, quindi i resolver ricorsivi DOVREBBERO (SHOULD) includere la stessa opzione ECS nelle query SVCB come nelle query A/AAAA.
Secondo la sezione 7.3.1 di [RFC7871], "Qualsiasi record dalla [sezione aggiuntiva] NON DEVE (MUST NOT) essere legato a una rete." Di conseguenza, quando si elabora una risposta il cui QTYPE è compatibile con SVCB, i resolver DOVREBBERO (SHOULD) trattare qualsiasi record nella sezione aggiuntiva come avente SOURCE PREFIX-LENGTH impostato a zero e SCOPE PREFIX-LENGTH come specificato nell'opzione ECS. I server autoritativi DEVONO (MUST) omettere tali record se non sono adatti all'uso da parte di resolver stub che impostano SOURCE PREFIX-LENGTH a zero. Ciò causerà l'esecuzione da parte del resolver di una query di follow-up che può ricevere un ECS adeguatamente personalizzato. (Questo è simile all'uso di CNAME con l'opzione ECS come discusso in [RFC7871], sezione 7.2.1.)
I server autoritativi che omettono i record aggiuntivi possono evitare la latenza aggiuntiva di una query di follow-up seguendo il consiglio nella sezione 10.2.