5.3. Handling Other Resource Records and the Additional Section

5.3.1. PTR Resource Record

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:

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

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

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.