5. DNS64 Normative Specification (Specifica Normativa DNS64)

DNS64 è una funzione logica che sintetizza record AAAA da record A. La funzione DNS64 può essere implementata in uno stub resolver, in un resolver ricorsivo, o in un name server autorevole. Funziona all'interno di quelle funzioni DNS, e appare sulla rete come se fosse un resolver DNS "semplice" o un name server conforme a [RFC1034] e [RFC1035].

L'implementazione DOVREBBE supportare la mappatura di intervalli di indirizzi IPv4 separati a prefissi IPv6 separati per la sintesi di record AAAA. Questo consente la gestione degli indirizzi IPv4 ad uso speciale [RFC5735].

I messaggi DNS contengono diverse sezioni. La porzione di un messaggio DNS che è alterata da DNS64 è la sezione answer, che è discussa di seguito nella Sezione 5.1. La risposta sintetica risultante è assemblata con altre sezioni, e questo crea il messaggio che è effettivamente restituito come risposta alla query DNS. L'assemblaggio di quella risposta è coperto di seguito nella Sezione 5.4.

DNS64 risponde anche a query PTR che coinvolgono indirizzi contenenti uno qualsiasi dei prefissi IPv6 che utilizza per la sintesi di RR AAAA.

5.1. Resolving AAAA Queries and the Answer Section (Risoluzione delle Query AAAA e la Sezione Answer)

Quando il DNS64 riceve una query per RR di tipo AAAA e classe IN, tenta prima di recuperare RR non sintetici di questo tipo e classe, sia eseguendo una query o, nel caso di un server autorevole, esaminando i propri risultati. La query può essere risolta da una cache locale, se disponibile. L'operazione DNS64 per classi diverse da IN è indefinita, e un DNS64 DEVE comportarsi come se nessuna funzione DNS64 fosse configurata.

5.1.1. The Answer when There is AAAA Data Available (La Risposta quando Sono Disponibili Dati AAAA)

Se la query risulta in uno o più record AAAA nella sezione answer, il risultato viene restituito al client richiedente secondo la normale semantica DNS, tranne nel caso in cui uno qualsiasi dei record AAAA corrisponda a un insieme speciale di esclusione di prefissi, come considerato nella Sezione 5.1.4. Se sono disponibili dati AAAA (non esclusi), DNS64 NON DOVREBBE includere RR AAAA sintetici nella risposta (vedere Appendice A per un'analisi delle motivazioni e delle implicazioni del non conformarsi a questa raccomandazione). Per impostazione predefinita, le implementazioni DNS64 NON DEVONO sintetizzare RR AAAA quando esistono RR AAAA reali.

5.1.2. The Answer when There is an Error (La Risposta in Presenza di un Errore)

Se la query risulta in una risposta con un RCODE diverso da 0 (No error condition), allora ci sono due possibilità. Un risultato con RCODE=3 (Name Error) è gestito secondo la normale operazione DNS (che normalmente è restituire l'errore al client). Questa fase è ancora precedente a qualsiasi sintesi che sia avvenuta, quindi una risposta da restituire al client non necessita di alcun assemblaggio speciale diverso da quello che accadrebbe normalmente nell'operazione DNS.

Qualsiasi altro RCODE è trattato come se l'RCODE fosse 0 (vedere Sezioni 5.1.6 e 5.1.7) e la sezione answer fosse vuota. Questo è dovuto al grande numero di risposte diverse dai name server distribuiti quando ricevono query AAAA senza che un record AAAA sia disponibile (vedere [RFC4074]). Si noti che questo significa, per scopi pratici, che diverse classi di errore nel DNS sono tutte trattate come se un record AAAA non fosse disponibile per quell'owner name.

È importante notare che, al momento della scrittura, alcuni server rispondono con RCODE=3 a una query AAAA anche se è disponibile un record A per quell'owner name. Quei server sono in chiara violazione del significato di RCODE 3, e ci si aspetta che diminuiranno nell'uso man mano che la distribuzione IPv6 aumenta.

5.1.3. Dealing with Timeouts (Gestione dei Timeout)

Se la query non riceve risposta prima del timeout (che potrebbe essere il timeout da ogni server autorevole, a seconda che il DNS64 sia in modalità recursive-resolver), è trattata come RCODE=2 (Server failure).

5.1.4. Special Exclusion Set for AAAA Records (Insieme di Esclusione Speciale per i Record AAAA)

Alcuni indirizzi IPv6 non sono effettivamente utilizzabili da host solo IPv6. Se vengono restituiti ad agenti richiedenti solo IPv6 come record AAAA, quindi, l'obiettivo di diminuire il numero di modalità di fallimento non sarà raggiunto. Gli esempi includono record AAAA con indirizzi nella rete ::ffff:0:0/96, e possibilmente (a seconda del contesto) record AAAA con il Pref64::/n del sito o il Well-Known Prefix (vedere sotto per maggiori informazioni sul Well-Known Prefix). Un'implementazione DNS64 DOVREBBE fornire un meccanismo per specificare intervalli di prefissi IPv6 da trattare come se il AAAA che li contiene fosse una risposta vuota. Un'implementazione DOVREBBE includere la rete ::ffff/96 in quell'intervallo per impostazione predefinita. Il mancato fornimento di questa funzionalità significherà che i client che interrogano la funzione DNS64 potrebbero non essere in grado di comunicare con host che sarebbero raggiungibili da un host dual-stack.

Quando il DNS64 esegue la sua query AAAA iniziale, se riceve una risposta con solo record AAAA contenenti indirizzi negli intervalli esclusi, allora DEVE trattare la risposta come se fosse una risposta vuota, e procedere di conseguenza. Se riceve una risposta con almeno un record AAAA contenente un indirizzo al di fuori di uno qualsiasi degli intervalli esclusi, allora per impostazione predefinita DOVREBBE costruire una sezione answer per una risposta includendo solo i record AAAA che non contengono nessuno degli indirizzi all'interno degli intervalli esclusi. Quella sezione answer è utilizzata nell'assemblaggio di una risposta come dettagliato nella Sezione 5.4. In alternativa, PUÒ trattare la risposta come se fosse una risposta vuota, e procedere di conseguenza. NON DEVE restituire i record AAAA offensivi come parte di una risposta.

5.1.5. Dealing with CNAME and DNAME (Gestione di CNAME e DNAME)

Se la risposta contiene un CNAME o un DNAME, allora la catena CNAME o DNAME è seguita fino al primo record A o AAAA terminante. Questo può richiedere al DNS64 di chiedere un record A, nel caso in cui la risposta alla query AAAA originale sia un CNAME o DNAME senza un record AAAA da seguire. Il record AAAA o A risultante è trattato come qualsiasi altro caso AAAA o A, come appropriato.

Quando si assembla la sezione answer, qualsiasi catena di RR CNAME o DNAME è inclusa come parte della risposta insieme al AAAA sintetico (se appropriato).

5.1.6. Data for the Answer when Performing Synthesis (Dati per la Risposta durante la Sintesi)

Se la query risulta in nessun errore ma una sezione answer vuota nella risposta, il DNS64 tenta di recuperare record A per il nome in questione, sia eseguendo un'altra query o, nel caso di un server autorevole, esaminando i propri risultati. Se questa nuova query RR A risulta in una risposta vuota o in un errore, allora il risultato vuoto o l'errore è utilizzato come base per la risposta restituita al client richiedente. Se invece la query risulta in uno o più RR A, il DNS64 sintetizza RR AAAA basati sui RR A secondo la procedura delineata nella Sezione 5.1.7. Il DNS64 restituisce i record AAAA sintetizzati nella sezione answer, rimuovendo i record A che formano la base della sintesi.

5.1.7. Performing the Synthesis (Esecuzione della Sintesi)

Un record AAAA sintetico è creato da un record A come segue:

• Il campo NAME è impostato al campo NAME dal record A.

• Il campo TYPE è impostato a 28 (AAAA).

• Il campo CLASS è impostato al campo CLASS originale, 1. Sotto questa specifica, DNS64 per qualsiasi CLASS diversa da 1 è indefinito.

• Il campo Time to Live (TTL) è impostato al minimo del TTL del RR A originale e del RR SOA per il dominio interrogato. (Si noti che per ottenere il TTL del RR SOA, il DNS64 non deve eseguire una nuova query, ma può ricordare il TTL dal RR SOA nella risposta negativa alla query AAAA. Se il RR SOA non è stato consegnato con la risposta negativa alla query AAAA, allora il DNS64 DOVREBBE utilizzare il TTL del RR A originale o 600 secondi, qualunque sia più corto. È possibile invece interrogare esplicitamente per il RR SOA e utilizzare il risultato di quella query, ma questo aumenterà il carico di query e il tempo di risoluzione con poco beneficio aggiuntivo.) Questo è in linea con l'approccio utilizzato nel caching negativo [RFC2308].

• Il campo RDLENGTH è impostato a 16.

• Il campo RDATA è impostato alla rappresentazione IPv6 dell'indirizzo IPv4 dal campo RDATA del record A. Il DNS64 DEVE controllare ogni RR A rispetto agli intervalli di indirizzi IPv4 configurati e selezionare il prefisso IPv6 corrispondente da utilizzare nella sintesi del RR AAAA. Vedere Sezione 5.2 per la discussione degli algoritmi da utilizzare nell'effettuare la trasformazione.

5.1.8. Querying in Parallel (Query in Parallelo)

Il DNS64 PUÒ eseguire la query per il RR AAAA e per il RR A in parallelo, al fine di minimizzare il ritardo.

NOTA: Interrogare in parallelo risulterà nell'esecuzione di query RR A non necessarie nel caso in cui non sia richiesta la sintesi di RR AAAA. Un possibile compromesso sarebbe eseguirle sequenzialmente ma con un intervallo molto breve tra loro, quindi se otteniamo una risposta veloce, evitiamo di fare la query aggiuntiva. (Si noti che questa discussione è rilevante solo se la funzione DNS64 deve eseguire query esterne per recuperare il RR. Se le informazioni RR necessarie sono disponibili localmente, come nel caso di un server autorevole, il problema non è più rilevante.)

5.2. Generation of the IPv6 Representations of IPv4 Addresses (Generazione delle Rappresentazioni IPv6 degli Indirizzi IPv4)

DNS64 supporta algoritmi multipli per la generazione della rappresentazione IPv6 di un indirizzo IPv4. I vincoli imposti sugli algoritmi di generazione sono i seguenti:

• Lo stesso algoritmo per creare un indirizzo IPv6 da un indirizzo IPv4 DEVE essere utilizzato sia da un DNS64 per creare l'indirizzo IPv6 da restituire nel RR AAAA sintetico dall'indirizzo IPv4 contenuto in un RR A originale, sia da un traduttore IPv6/IPv4 per creare l'indirizzo IPv6 da includere nel campo indirizzo sorgente dei pacchetti IPv6 in uscita dall'indirizzo IPv4 incluso nel campo indirizzo sorgente del pacchetto IPv4 in entrata.

• L'algoritmo DEVE essere reversibile; cioè, DEVE essere possibile derivare l'indirizzo IPv4 originale dalla rappresentazione IPv6.

• L'input per l'algoritmo DEVE essere limitato all'indirizzo IPv4; al prefisso IPv6 (denotato Pref64::/n) utilizzato nelle rappresentazioni IPv6; e, opzionalmente, a un insieme di parametri stabili che sono configurati nel DNS64 e nel NAT64 (come una stringa fissa da utilizzare come suffisso).

  • Per ogni prefisso Pref64::/n, n DEVE essere minore o uguale a 96. Se uno o più Pref64::/n sono configurati nel DNS64 attraverso qualsiasi mezzo (come configurazione manuale, o altri mezzi automatici non specificati in questo documento), l'algoritmo predefinito DEVE utilizzare questi prefissi (e non utilizzare il Well-Known Prefix). Se nessun prefisso è disponibile, l'algoritmo DEVE utilizzare il Well-Known Prefix 64:ff9b::/96 definito in [RFC6052] per rappresentare l'intervallo di indirizzi unicast IPv4.

Un DNS64 DEVE supportare l'algoritmo per generare rappresentazioni IPv6 di indirizzi IPv4 definito nella Sezione 2 di [RFC6052]. Inoltre, l'algoritmo sopra menzionato DEVE essere l'algoritmo predefinito utilizzato dal DNS64. Mentre la descrizione normativa dell'algoritmo è fornita in [RFC6052], una descrizione campione dell'algoritmo e la sua applicazione a scenari diversi sono fornite nella Sezione 7 a scopo illustrativo.

5.3. Handling Other Resource Records and the Additional Section (Gestione di Altri Resource Record e della Sezione Additional)

5.3.1. PTR Resource Record (Resource Record PTR)

Se un server DNS64 riceve una query PTR per un record nel dominio IP6.ARPA, DEVE rimuovere le etichette IP6.ARPA dal QNAME, invertire la porzione di indirizzo del QNAME secondo lo schema di codifica delineato nella Sezione 2.5 di [RFC3596], ed esaminare l'indirizzo risultante per vedere se il suo prefisso corrisponde a uno qualsiasi dei Pref64::/n configurati localmente o al Well-Known Prefix predefinito. Ci sono due alternative per un server DNS64 per rispondere a tali query PTR. Un server DNS64 DEVE fornire una di queste, e NON DOVREBBE fornire entrambe contemporaneamente a meno che zone IP6.ARPA diverse richiedano risposte di tipo diverso:

1. La prima opzione è per il server DNS64 rispondere autoritativamente per i suoi prefissi. Se il prefisso dell'indirizzo corrisponde a qualsiasi Pref64::/n utilizzato nel sito, sia un NSP che il Well-Known Prefix (cioè, 64:ff9b::/96), allora il server DNS64 PUÒ rispondere alla query utilizzando RDATA localmente appropriato. Il server DNS64 PUÒ utilizzare lo stesso RDATA per tutte le risposte. Si noti che il requisito è corrispondere a qualsiasi Pref64::/n utilizzato nel sito, e non semplicemente al Pref64::/n configurato localmente. Questo perché i client finali potrebbero chiedere un record PTR corrispondente a un indirizzo ricevuto attraverso un DNS64 diverso (fornito dal sito), e se questa strategia è in vigore, quelle query non dovrebbero mai essere inviate al DNS globale. Il vantaggio di questa strategia è che rende chiaro al client richiedente che il prefisso è uno operato dal sito (DNS64), e che le risposte che il client sta ottenendo sono generate da DNS64. Lo svantaggio è che qualsiasi informazione utile dell'albero inverso che potrebbe essere nel DNS globale è non disponibile ai client che interrogano il DNS64.

2. La seconda opzione è per il name server DNS64 sintetizzare un CNAME che mappa lo spazio dei nomi IP6.ARPA al corrispondente nome IN-ADDR.ARPA. In questo caso, il name server DNS64 DOVREBBE assicurarsi che ci sia RDATA al PTR del corrispondente nome IN-ADDR.ARPA, e che non ci sia un CNAME esistente a quel nome. Questo è per evitare di sintetizzare un CNAME che rende una catena CNAME più lunga o che in realtà non punta a nulla. Il resto della risposta sarebbe il normale processing DNS. Il CNAME può essere firmato al volo se necessario. Il vantaggio di questo approccio è che qualsiasi informazione utile nell'albero inverso è disponibile al client richiedente. Gli svantaggi sono che aggiunge carico aggiuntivo al DNS64 (perché i CNAME devono essere sintetizzati per ogni query PTR che corrisponde al Pref64::/n), e che può richiedere la firma al volo.

Se il prefisso dell'indirizzo non corrisponde a nessun Pref64::/n, allora il server DNS64 DEVE processare la query come se fosse qualsiasi altra query; cioè, un name server ricorsivo DEVE tentare di risolvere la query come se fosse qualsiasi altra query (non-A/AAAA), e un server autorevole DEVE rispondere autoritativamente o con un referral, come appropriato.

5.3.2. Handling the Additional Section (Gestione della Sezione Additional)

La sintesi DNS64 NON DEVE essere eseguita su alcun record nella sezione additional delle risposte sintetizzate. Il DNS64 DEVE passare la sezione additional invariata.

NOTA: Potrebbe sembrare che aggiungere record sintetici alla sezione additional sia desiderabile, perché i client a volte utilizzano i dati nella sezione additional per procedere senza dover interrogare nuovamente. Non c'è in generale alcuna promessa, tuttavia, che la sezione additional conterrà tutti i record rilevanti, quindi qualsiasi client che dipende dalla sezione additional essendo in grado di soddisfare le sue necessità (cioè, senza query aggiuntive) è necessariamente difettoso. Un client solo IPv6 che necessita di un record AAAA, quindi, invierà una query per il record AAAA necessario se non è in grado di trovare tale record nella sezione additional di una risposta che sta consumando. Per un client che funziona correttamente, l'effetto non sarebbe diverso se la sezione additional fosse vuota. L'alternativa di rimuovere i record A nella sezione additional e sostituirli con record AAAA sintetici può causare un host dietro un NAT64 di interrogare direttamente un name server che non è a conoscenza del NAT64 in questione. Il risultato in questo caso sarà comunque un fallimento di risoluzione, ma più tardi nell'operazione di risoluzione. Il divieto di dati sintetici nella sezione additional riduce, ma non elimina, la possibilità di fallimenti di risoluzione dovuti a dati DNS memorizzati nella cache da dietro il DNS64. Vedere Sezione 6.

5.3.3. Other Resource Records (Altri Resource Record)

Se il DNS64 è in modalità recursive-resolver, allora le considerazioni delineate in [DEFAULT-LOCAL-ZONES] possono essere rilevanti.

Tutti gli altri RR DEVONO essere restituiti invariati. Questo include risposte a query per RR A.

5.4. Assembling a Synthesized Response to a AAAA Query (Composizione di una Risposta Sintetizzata a una Query AAAA)

Un DNS64 utilizza pezzi diversi di dati per costruire la risposta restituita al client richiedente.

La query che è utilizzata come base per la sintesi risulta in un errore, una risposta che può essere utilizzata come base per la sintesi, o una risposta (autorevole) vuota. Se c'è una risposta vuota, allora il DNS64 risponde al client richiedente originale con la risposta che il DNS64 ha ricevuto alla query originale (dell'iniziatore). Altrimenti, la risposta è assemblata come segue.

I campi header sono impostati secondo le regole usuali per server ricorsivi o autorevoli, a seconda del ruolo che il DNS64 sta servendo. La sezione question è copiata dalla query originale (dell'iniziatore). La sezione answer è popolata secondo le regole nella Sezione 5.1.7. Le sezioni authority e additional sono copiate dalla risposta alla query finale che il DNS64 ha eseguito, e utilizzate come base per la sintesi.

La risposta finale dal DNS64 è soggetta a tutte le regole DNS standard, incluso il troncamento [RFC1035] e la gestione EDNS0 [RFC2671].

5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode (Elaborazione DNSSEC: DNS64 in Modalità Resolver Validante)

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.