5. Integrazione HTTP (HTTP Integration)
5.1. Interazione con la cache (Cache Interaction)
Gli scambi DoH sono compatibili con la cache HTTP [RFC7234]. La durata di freschezza specificata per una risposta DoH deve (MUST) essere minore o uguale al TTL minimo nella sezione Answer della risposta DNS. Altrimenti, una cache potrebbe fornire una risposta più vecchia di quanto consentito dal DNS. Se il TTL nella sezione Answer è minore della durata di freschezza della risposta HTTP, la risposta DNS può essere aggiornata tramite la normale scadenza e validazione della cache HTTP, mentre la risposta DNS restituita dal client DoH può usare il TTL originale più breve.
La chiave di cache HTTP derivata da una query DoH deve (MUST) contenere solo l'URI e il tipo di media della richiesta, per esempio il campo di intestazione Content-Type in application/dns-message. Includere il campo Accept, ad esempio, causerebbe duplicazioni inutili di voci di cache per query semanticamente equivalenti. Tuttavia, secondo le specifiche HTTP, intestazioni come Authorization dovrebbero influenzare la cache HTTP.
Il client DoH può (MAY) scegliere di mantenere una copia memorizzata di una risposta HTTP prima della scadenza della freschezza della cache HTTP per qualsiasi ragione, incluse, ma non solo, semantiche di cache HTTP private o nuove conoscenze su alias DNS. Il client DoH può (MAY) aggiornare il TTL DNS in modo coerente con la freschezza della cache HTTP, purché il TTL DNS sia minore o uguale alla freschezza HTTP.
Una risposta a una richiesta HTTP condizionale [RFC7232] per una query DNS può (MAY) rivalidare una risposta DNS non di errore come voce di cache. Il TTL DNS della risposta rivalidata dovrebbe (SHOULD) riflettere la freschezza al momento della risposta, non la vita residua della risposta originale. Il client potrebbe dover recuperare una nuova risposta quando riceve una risposta 304 (Not Modified) per ottenere un TTL aggiornato.
Le richieste Range [RFC7233] per query DNS non sono applicabili, perché il contenuto della risposta non è adatto al trasferimento parziale.
Il server DoH può (MAY) usare il server push HTTP, vedere la Sezione 5.3, per fornire risposte in anticipo al client DoH, ma la politica di cache delle risposte push è la stessa delle risposte non push.
I reindirizzamenti HTTP, come descritto nella Sezione 4.2.1, cambiano l'URI effettivo della richiesta e quindi la chiave usata per la cache HTTP.
Il client DoH deve (MUST) essere in grado di gestire il campo di intestazione di risposta Vary [RFC7231]. Ciò può includere la scelta di non memorizzare nella cache le risposte a tali query.
Esempio: calcolo della durata di freschezza
Se una risposta DNS contiene tre record con TTL rispettivamente di 200, 300 e 400 secondi, max-age nell'intestazione Cache-Control della risposta HTTP deve essere minore o uguale a 200 secondi:
Cache-Control: max-age=200
Se il client DoH riceve una risposta dalla cache HTTP il cui campo Age indica che la risposta è stata memorizzata per 50 secondi, il client può usare la risposta, ma il TTL effettivo dei record DNS dovrebbe essere ridotto di 50 secondi.
5.2. HTTP/2
L'uso di HTTP/2 [RFC7540] consente di multiplexare la connessione tra client DoH e server DoH, riducendo il costo delle query DNS aggiuntive e migliorando le prestazioni. Il numero di query parallele è pari al parametro HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS del server.
Il controllo di flusso di una connessione HTTP/2 offre anche un certo controllo sulla dimensione delle query. La dimensione minima della finestra a livello di stream è 65.535 byte. Uno scambio DoH dovrebbe (SHOULD) fornire almeno una finestra di 65.535 byte, per evitare ritardi per risposte DNS di dimensione minore o uguale a 65.535 byte.
Quando si usa il server push HTTP/2, vedere la Sezione 5.3, deve (MUST) essere aperto uno stream bidirezionale per il normale scambio richiesta/risposta HTTP prima di dichiarare lo stream push.
5.3. Server Push
Il server push HTTP/2 consente a un server DoH di fornire risposte DNS al client DoH prima che il client le richieda. Questo può migliorare le prestazioni. Per esempio, quando il client interroga il record A di un nome, il server può inviare in push il record AAAA dello stesso nome.
Se una risposta push non viene usata immediatamente, viene aggiunta alla cache HTTP come qualsiasi altra risposta HTTP ed è soggetta alla stessa politica di controllo della cache.
Il client DoH deve (MUST) essere in grado di ricevere risposte push dal server, ma non è obbligato a usarle. Il client DoH può (MAY) applicare limiti all'accettazione di risposte push, ad esempio limitando il numero di risposte push pendenti contemporaneamente.
L'uso delle risposte push richiede che il client DoH possa associarle a query future. A questo scopo, quando la richiesta e la risposta push hanno lo stesso tipo di media, il client DoH può (MAY) associare la risposta push a una futura query eseguita con il metodo GET, purché l'URI della risposta push corrisponda all'URI di tale query.
5.4. Negoziazione del contenuto (Content Negotiation)
Per consentire la possibilità di altri formati, il client DoH può includere il campo di intestazione HTTP Accept. Tali richieste dovrebbero (SHOULD) includere il tipo di media application/dns-message, per assicurare l'interoperabilità minima con DoH.
Come indicato nella Sezione 4.1, l'uso del campo Accept in questi scambi ha anche effetti sulla cache HTTP, che potrebbero essere indesiderati.
Quando si usa il campo di intestazione HTTP Accept, il server DoH dovrebbe (SHOULD) restituire un campo di intestazione di risposta Vary il cui valore includa almeno Accept.
Il server potrebbe non essere in grado di rispondere nel formato richiesto dal campo Accept. Il client DoH deve (MUST) essere preparato a gestire questa situazione.