6. Deployment Notes (Note di Distribuzione)
6. Deployment Notes (Note di Distribuzione)
Mentre DNS64 è inteso come parte di una strategia per aiutare la distribuzione IPv6 in un ambiente di internetworking con alcune reti solo IPv4 e solo IPv6, è importante realizzare che è incompatibile con alcune cose che possono essere distribuite in un contesto solo IPv4 o dual-stack.
6.1. DNS Resolvers and DNS64
I resolver full-service che non sono consapevoli della funzione DNS64 possono essere (mal)configurati per agire come resolver in modalità mista iterativa e forwarding. In un contesto IPv4 nativo, questo tipo di configurazione può sembrare funzionare. È impossibile farlo funzionare correttamente senza essere consapevole della funzione DNS64, perché probabilmente a un certo punto otterrà record glue solo IPv4 e tenterà di utilizzarli per la risoluzione. Il risultato che viene restituito conterrà solo record A, e senza la capacità di eseguire la funzione DNS64 il resolver sarà incapace di rispondere alle query AAAA necessarie.
6.2. DNSSEC Validators and DNS64
Un validatore DNSSEC esistente (cioè, uno che non è consapevole di DNS64) potrebbe rifiutare tutti i dati che provengono da DNS64 come essendo stati manomessi (anche se non ha impostato CD quando interrogava). Se è necessario avere validazione dietro il DNS64, allora il validatore deve sapere come eseguire la funzione DNS64 da solo. In alternativa, l'host validante può stabilire una connessione fidata con un DNS64, e consentire al resolver ricorsivo DNS64 di fare tutta la validazione per suo conto.
6.3. DNS64 and Multihomed and Dual-Stack Hosts
6.3.1. IPv6 Multihomed Hosts
I record AAAA sintetici possono essere costruiti sulla base del contesto di rete in cui sono stati costruiti. Se un host invia query DNS a resolver in reti multiple, è possibile che alcuni di essi ricevano risposte da un DNS64 senza che tutti siano connessi tramite un NAT64. Per esempio, supponiamo che un sistema abbia due interfacce, i1 e i2. Mentre i1 è connesso all'Internet IPv4 tramite NAT64, i2 ha connettività IPv6 nativa solo. I1 potrebbe ricevere una risposta AAAA da un DNS64 che è configurato per un particolare NAT64; l'indirizzo IPv6 contenuto in quella risposta AAAA non si connetterà con nulla tramite i2.
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
| host |
| | +-------------+
| i2 (IPv6)+-----------------+IPv6 Internet|
+---------------+ +-------------+
Figure 1: IPv6 Multihomed Hosts
Questo esempio illustra perché è generalmente preferibile che gli host trattino le risposte DNS da un'interfaccia come locali a quell'interfaccia. La risposta ricevuta su un'interfaccia non funzionerà sull'altra interfaccia. Gli host che tentano di utilizzare risposte DNS globalmente possono incontrare fallimenti sorprendenti in questi casi.
Si noti che il problema non è che ci sono due interfacce, ma che ci sono due reti coinvolte. Gli stessi risultati potrebbero essere raggiunti con una singola interfaccia instradata verso due reti diverse.
6.3.2. Accidental Dual-Stack DNS64 Use
Analogamente, supponiamo che i1 abbia connettività IPv6 e possa connettersi all'Internet IPv4 attraverso NAT64, ma i2 ha connettività IPv4 nativa. In questo caso, i1 potrebbe ricevere un indirizzo IPv6 da un AAAA sintetico che sarebbe meglio raggiunto tramite IPv4 nativo. Ancora una volta, vale la pena sottolineare che questo si verifica perché ci sono due reti coinvolte.
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
| host |
| | +-------------+
| i2 (IPv4)+-----------------+IPv4 Internet|
+---------------+ +-------------+
Figure 2: Accidental Dual-Stack DNS64 Use
La configurazione predefinita degli host dual-stack è che IPv6 è preferito rispetto a IPv4 ([RFC3484]). In quell'arrangiamento, l'host utilizzerà spesso il NAT64 quando IPv4 nativo sarebbe più desiderabile. Per questa ragione, gli host con connettività IPv4 all'Internet dovrebbero evitare di utilizzare DNS64. Questo può essere parzialmente risolto dagli ISP quando forniscono resolver DNS ai client, ma non è una garanzia che il NAT64 non verrà mai utilizzato quando dovrebbe essere utilizzata una connessione IPv4 nativa. Non c'è alcun meccanismo general-purpose per garantire che il transito IPv4 nativo sarà sempre preferito, perché per un host ignaro di DNS64, il DNS64 sembra proprio come un server DNS ordinario. Gli operatori di un NAT64 dovrebbero aspettarsi traffico che passa attraverso il NAT64 anche quando non è necessario.
6.3.3. Intentional Dual-Stack DNS64 Use
Infine, consideriamo il caso in cui la connettività IPv4 su i2 è solo con una LAN, e non con l'Internet IPv4. L'Internet IPv4 è accessibile solo utilizzando il NAT64. In questo caso, è critico che il DNS64 non sintetizzi risposte AAAA per host nella LAN, o che il DNS64 sia consapevole degli host nella LAN e fornisca risposte context-sensitive (risposte DNS "split view") per gli host all'interno della LAN. Come con qualsiasi arrangiamento split view DNS, gli operatori devono essere preparati per i dati che trapelano da un contesto all'altro, e per fallimenti che si verificano perché i nodi accessibili da un contesto non sono accessibili dall'altro.
+---------------+ +-------------+
| i1 (IPv6)+----NAT64--------+IPv4 Internet|
| | +-------------+
| host |
| |
| i2 (IPv4)+---(local LAN only)
+---------------+
Figure 3: Intentional Dual-Stack DNS64 Use
È importante per i distributori di DNS64 realizzare che, in alcune circostanze, rendere il DNS64 disponibile a un host dual-stack causerà l'host a preferire inviare pacchetti tramite NAT64 invece che tramite IPv4 nativo, con la perdita associata di prestazioni o funzionalità (o entrambe) comportata dal NAT. Allo stesso tempo, alcuni host non sono in grado di apprendere su server DNS forniti su indirizzi IPv6, o semplicemente non possono inviare pacchetti DNS su IPv6.