Quando un resolver riceve una risposta dal DNSSEC name server, deve iniziare la verifica delle firme associate agli RR ricevuti come risposta. Ma la verifica della firma dice solo che il messaggio è stato correttamente firmato. Non dice nulla circa la falsità dei dati. Così, abbiamo solo l'integrità dei dati, ma non l'autenticazione dell'origine dei dati.
Il resolver deve in qualche modo determinare se la chiave KEY con cui sono stati firmati gli RR è sicura e se è autorizzato a firmare questi RR. Per fare questo deve costruire una catena verificata crittograficamente di KEY e SIG RR verso un punto di fiducia.
Ogni KEY RR è firmato con la chiave del padre di zona. Quindi per verificare il SIG RR di una KEY, il resolver deve recuperare informazioni sul padre delle zone.
Vediamo un esempio. Supponiamo di voler recuperare l'indirizzo RR di host.mydomain.com. Il resolver dovrebbe fare una query al name server per il nome e il tipo richiesto.
Quando riceve la risposta, si ha un A RR per il nome host.mydomain.com e anche un SIG RR per l'A RR insieme con un KEY RR contenente la chiave pubblica che verifica la firma.
Il problema è: si puo' aver fiducia in quella chiave pubblica?
Il processo di autenticazione è basato sul fatto che la chiave pubblica Root è sicura dal momento che è preconfigurata nel resolver.
Assumiamo che gli RR di mydomain.com (posti sulla macchina securens.mydomain.com) erano firmati con la chiave privata di mydomain.com.
La chiave pubblica (memorizzata in KEY RR recuparata da noi) è anche firmata, ma dal dominio padre, cioè con la chiave privata di com. Per verificarla, si deve recuperare anche la chiave pubblica di "com". Nella stessa maniera, la chiave pubblica di com è firmata dalla chiave privata root.
Dopo le verifiche della chiave pubblica di com (con la chiave pubblica root in possesso), si deve raggiungere un punto nell'albero di cui ci si può fidare. Quindi, si può concludere che la pubblic KEY di mydomain.com può essere sicura. In questo modo, un resolver dovrebbe "imparare" a fidarsi delle chiavi verificando le loro firme passando attraverso queste catene di KEY e SIG RR.
In secondo luogo è necessario verificare se è possibile fidarsi dei dati messi in cache durante le precedenti valutazioni. Nel caso peggiore, un resolver dovrebbe confermare la firma delle chiavi fino al livello della radice dell' albero DNS.
