7. Stub Resolver Considerations (Considerazioni sui resolver stub)

Sebbene non sia strettamente richiesto dal protocollo, la maggior parte delle query DNS proviene da resolver stub. Per definizione, i resolver stub sono resolver DNS minimali che utilizzano la modalità di query ricorsiva per scaricare la maggior parte del lavoro di risoluzione DNS su un name server ricorsivo. Data l'ampia diffusione dei resolver stub, l'architettura DNSSEC deve tenere conto dei resolver stub, ma le funzionalità di sicurezza necessarie in un resolver stub differiscono sotto alcuni aspetti da quelle necessarie in un resolver iterativo consapevole della sicurezza.

Anche un resolver stub non consapevole della sicurezza può beneficiare di DNSSEC se i name server ricorsivi che utilizza sono consapevoli della sicurezza, ma affinché il resolver stub possa fare realmente affidamento sui servizi DNSSEC, il resolver stub deve fidarsi sia dei name server ricorsivi in questione che dei canali di comunicazione tra sé stesso e tali name server. Il primo di questi problemi è una questione di politica locale: in sostanza, un resolver stub non consapevole della sicurezza non ha altra scelta che mettersi alla mercé dei name server ricorsivi che utilizza, poiché non esegue esso stesso controlli di validità DNSSEC. Il secondo problema richiede un qualche tipo di meccanismo di sicurezza del canale, l'uso appropriato di meccanismi di autenticazione delle transazioni DNS come SIG(0) ([RFC2931]) o TSIG ([RFC2845]) sarebbe sufficiente, così come l'uso appropriato di IPsec. Implementazioni particolari potrebbero avere altre opzioni disponibili, come meccanismi di comunicazione tra processi specifici del sistema operativo. La riservatezza non è necessaria per questo canale, ma l'integrità dei dati e l'autenticazione dei messaggi lo sono.

Un resolver stub consapevole della sicurezza che si fida sia dei suoi name server ricorsivi che del suo canale di comunicazione con essi può scegliere di esaminare l'impostazione del bit Authenticated Data (AD) nell'intestazione del messaggio dei messaggi di risposta che riceve. Il resolver stub può utilizzare questo bit di flag come suggerimento per scoprire se il name server ricorsivo è stato in grado di convalidare le firme per tutti i dati nelle sezioni Answer e Authority della risposta.

C'è un altro passo che un resolver stub consapevole della sicurezza può intraprendere se, per qualsiasi motivo, non è in grado di stabilire una relazione di fiducia utile con i name server ricorsivi che utilizza: può eseguire la propria convalida della firma impostando il bit Checking Disabled (CD) nei suoi messaggi di query. Un resolver stub validante è quindi in grado di trattare le firme DNSSEC come relazioni di fiducia tra gli amministratori di zona e il resolver stub stesso.