5.5. DNSSEC Processing DNS64 in Validating Resolver Mode

5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode

Consideriamo il caso in cui un resolver ricorsivo che sta eseguendo DNS64 ha anche una policy locale per validare le risposte secondo le procedure delineate in [RFC4035], Sezione 5. Chiamiamo questo caso generale vDNS64.

Il vDNS64 utilizza la presenza dei bit DO e CD per prendere alcune decisioni su ciò di cui l'originatore della query ha bisogno, e può reagire di conseguenza:

1. Se CD non è impostato e DO non è impostato, vDNS64 DOVREBBE eseguire la validazione e fare la sintesi come necessario. Vedere il prossimo punto per le regole su come fare validazione e sintesi. In questo caso, tuttavia, vDNS64 NON DEVE impostare il bit AD in alcuna risposta.

2. Se CD non è impostato e DO è impostato, allora vDNS64 DOVREBBE eseguire la validazione. Ogni volta che vDNS64 esegue la validazione, DEVE validare la risposta negativa per le query AAAA prima di procedere a interrogare per i record A per lo stesso nome, al fine di essere sicuro che non ci sia un record AAAA legittimo su Internet. Non osservare questo passaggio permetterebbe a un attaccante di utilizzare DNS64 come meccanismo per aggirare DNSSEC. Se la risposta negativa si valida, e la risposta alla query A si valida, allora il vDNS64 PUÒ eseguire la sintesi e DOVREBBE impostare il bit AD nella risposta al client. Questo è accettabile, perché [RFC4035], Sezione 3.2.3 dice che il bit AD è impostato dal lato name server di un name server ricorsivo security-aware se e solo se considera tutti gli RRSet nelle sezioni answer e authority autentici. In questo caso, il name server ha ragione di credere che gli RRSet siano tutti autentici, quindi DOVREBBE impostare il bit AD. Se i dati non si validano, il vDNS64 DEVE rispondere con RCODE=2 (Server failure).

   Un end point security-aware potrebbe prendere la presenza del bit AD come un'indicazione che i dati sono validi, e può passare i dati DNS (e DNSSEC) a un'applicazione. Se l'applicazione tenta di validare i dati sintetizzati, ovviamente, la validazione fallirà. Si potrebbe sostenere quindi che questo approccio non è desiderabile, ma gli stub resolver security-aware non devono riporre alcuna dipendenza sui dati ricevuti dai resolver e validati per loro conto senza certi criteri stabiliti da [RFC4035], Sezione 4.9.3. Un'applicazione che vuole eseguire la validazione da sola dovrebbe utilizzare il bit CD.

3. Se il bit CD è impostato e DO è impostato, allora vDNS64 PUÒ eseguire la validazione, ma NON DEVE eseguire la sintesi. DEVE restituire i dati all'iniziatore della query, proprio come un resolver ricorsivo regolare, e dipendere dal client per fare la validazione e la sintesi da solo.

   Lo svantaggio di questo approccio è che un end point che è translation-oblivious ma security-aware e validante non sarà in grado di utilizzare la funzionalità DNS64. In questo caso, l'end point non avrà il beneficio desiderato di NAT64. In effetti, questa strategia significa che qualsiasi end point che desidera fare validazione in un contesto NAT64 deve essere aggiornato per essere anche translation-aware.