4. Resolving (Risoluzione)
Questa sezione descrive il comportamento delle entità che includono funzioni di resolver consapevoli della sicurezza. In molti casi tali funzioni faranno parte di un server dei nomi ricorsivo consapevole della sicurezza.
4.1. EDNS Support (Supporto EDNS)
Le implementazioni di resolver consapevoli della sicurezza devono (MUST) supportare l'estensione della dimensione del messaggio EDNS0, devono (MUST) supportare una dimensione del messaggio di almeno 1220 ottetti e dovrebbero (SHOULD) supportare una dimensione del messaggio di 4000 ottetti.
4.2. Signature Verification Support (Supporto per la verifica della firma)
Un resolver consapevole della sicurezza deve (MUST) supportare i meccanismi di verifica della firma descritti nella Sezione 5, e deve (MUST) applicarli a ogni risposta ricevuta, tranne quando:
- Il resolver consapevole della sicurezza fa parte di un server dei nomi ricorsivo consapevole della sicurezza, e la risposta è il risultato di ricorsione per conto di una query ricevuta con il bit CD impostato
- La risposta è il risultato di una query generata direttamente tramite una forma di interfaccia applicativa che ha istruito il resolver consapevole della sicurezza a non eseguire la convalida per questa query
- La convalida per questa query è stata disabilitata dalla politica locale
Il supporto per la verifica della firma di un resolver consapevole della sicurezza deve (MUST) includere il supporto per la verifica dei nomi di proprietario wildcard (Wildcard Owner Names).
I resolver consapevoli della sicurezza possono (MAY) interrogare per RR di sicurezza mancanti nel tentativo di eseguire la convalida. Quando si tenta di recuperare RR NSEC mancanti che risiedono sul lato parentale a un taglio di zona, un resolver in modalità iterativa consapevole della sicurezza deve (MUST) interrogare i server dei nomi per la zona padre, non la zona figlia.
Quando si tenta di recuperare un DS mancante, un resolver in modalità iterativa consapevole della sicurezza deve (MUST) interrogare i server dei nomi per la zona padre, non la zona figlia.
4.3. Determining Security Status of Data (Determinazione dello stato di sicurezza dei dati)
Un resolver consapevole della sicurezza deve (MUST) essere in grado di determinare se dovrebbe aspettarsi che un particolare RRset sia firmato. Un resolver consapevole della sicurezza deve essere in grado di distinguere quattro casi:
Secure (Sicuro): Un RRset per il quale il resolver è in grado di costruire una catena di RR DNSKEY e DS firmati da un'ancora di sicurezza affidabile all'RRset. In questo caso, l'RRset dovrebbe essere firmato ed è soggetto alla convalida della firma.
Insecure (Non sicuro): Un RRset per il quale il resolver sa che non ha alcuna catena di RR DNSKEY e DS firmati da alcun punto di partenza affidabile all'RRset. Questo può verificarsi quando l'RRset target si trova in una zona non firmata o in un discendente di una zona non firmata. In questo caso, l'RRset può essere firmato o non firmato, ma il resolver non sarà in grado di verificare la firma.
Bogus (Falso): Un RRset per il quale il resolver ritiene che dovrebbe essere in grado di stabilire una catena di fiducia ma per il quale non è in grado di farlo, sia a causa di firme che per qualche motivo non riescono a convalidare sia a causa di dati mancanti che i RR DNSSEC rilevanti indicano dovrebbero essere presenti. Questo caso può indicare un attacco ma può anche indicare un errore di configurazione o una forma di corruzione dei dati.
Indeterminate (Indeterminato): Un RRset per il quale il resolver non è in grado di determinare se l'RRset dovrebbe essere firmato, poiché il resolver non è in grado di ottenere i RR DNSSEC necessari. Questo può verificarsi quando il resolver consapevole della sicurezza non è in grado di contattare server dei nomi consapevoli della sicurezza per le zone pertinenti.
4.4. Configured Trust Anchors (Ancore di fiducia configurate)
Un resolver consapevole della sicurezza deve (MUST) essere in grado di essere configurato con almeno una chiave pubblica affidabile o un RR DS e dovrebbe (SHOULD) essere in grado di essere configurato con più chiavi pubbliche affidabili o RR DS.
Poiché un resolver consapevole della sicurezza non sarà in grado di convalidare le firme senza una tale ancora di fiducia configurata, il resolver dovrebbe (SHOULD) avere un meccanismo ragionevolmente robusto per ottenere tali chiavi all'avvio.
4.5. Response Caching (Caching delle risposte)
Un resolver consapevole della sicurezza dovrebbe (SHOULD) memorizzare nella cache ogni risposta come una singola voce atomica contenente l'intera risposta, incluso l'RRset nominato e tutti i RR RRSIG e NSEC associati, indipendentemente dallo stato di sicurezza della risposta.
Un resolver consapevole della sicurezza non deve (MUST NOT) memorizzare nella cache i RR RRSIG indipendentemente dagli RRset che firmano, poiché ciò potrebbe consentire a un attaccante di riprodurre vecchi RRSIG con nuovi dati.
4.6. Handling of the CD and AD Bits (Gestione dei bit CD e AD)
Il bit CD controlla se un resolver consapevole della sicurezza esegue la convalida per una particolare query. Un resolver consapevole della sicurezza deve (MUST) impostare il bit AD in una risposta se e solo se il resolver considera tutti gli RRset nelle sezioni Answer e Authority della risposta come autentici.
Un resolver che non è consapevole della sicurezza non deve (MUST NOT) impostare il bit AD in una risposta. Un resolver consapevole della sicurezza non deve (MUST NOT) impostare il bit AD a meno che non abbia convalidato i dati secondo le regole descritte in questa specifica.
4.7. Caching BAD Data (Caching di dati non validi)
Un resolver può (MAY) memorizzare nella cache dati con uno stato di sicurezza "non valido" in modo diverso dai dati con uno stato di sicurezza "valido". Tuttavia, un resolver non deve (MUST NOT) utilizzare dati memorizzati nella cache con uno stato di sicurezza non valido a meno che:
- Il resolver stia rispondendo a una query con il bit CD impostato
- I dati non validi erano il risultato di una query con il bit CD impostato
- La politica locale autorizza esplicitamente l'uso di dati non validi
4.8. Synthesized CNAMEs (CNAME sintetizzati)
Un resolver consapevole della sicurezza deve (MUST) applicare regole di elaborazione speciali quando gestisce RR CNAME sintetizzati come descritto in [RFC2672]. Il resolver non deve (MUST NOT) aspettarsi che un CNAME sintetizzato sia firmato, ma deve (MUST) convalidare il RR DNAME da cui il CNAME è stato sintetizzato.
4.9. Stub Resolvers (Resolver stub)
Un resolver stub consapevole della sicurezza è un'entità che agisce come resolver DNS e che ha la capacità di eseguire la convalida della firma ma non agisce come un server dei nomi ricorsivo consapevole della sicurezza completo. I resolver stub si affidano tipicamente a un server dei nomi ricorsivo per eseguire la maggior parte delle operazioni DNS per loro conto.
4.9.1. Handling of the DO Bit (Gestione del bit DO)
Un resolver stub consapevole della sicurezza dovrebbe (SHOULD) impostare il bit DO nelle query per indicare che desidera ricevere RR DNSSEC nella risposta.
4.9.2. Handling of the CD Bit (Gestione del bit CD)
Un resolver stub consapevole della sicurezza può (MAY) impostare il bit CD nelle query per indicare che è disposto a eseguire la convalida da solo piuttosto che affidarsi al server dei nomi a cui sta inviando la query per eseguire la convalida per suo conto.
4.9.3. Handling of the AD Bit (Gestione del bit AD)
Un resolver stub consapevole della sicurezza può (MAY) utilizzare l'impostazione del bit AD in una risposta per indicare se il server dei nomi che ha inviato la risposta ha convalidato i dati per conto del resolver stub.
Un resolver stub consapevole della sicurezza che imposta il bit CD in una query deve (MUST) ignorare il bit AD nella risposta, poiché il server dei nomi è stato esplicitamente istruito a non eseguire la convalida per conto del resolver stub.