5.1. Resolving AAAA Queries and the Answer Section

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

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

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

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

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

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

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

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

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.)