Appendix A. Motivations and Implications of Synthesizing AAAA Resource Records when Real AAAA Resource Records Exist

Appendix A. Motivations and Implications of Synthesizing AAAA Resource Records when Real AAAA Resource Records Exist

La motivazione per sintetizzare RR AAAA quando esistono RR AAAA reali è supportare il seguente scenario:

• Un'applicazione server solo IPv4 (ad esempio, software web server) è in esecuzione su un host dual-stack. Potrebbero esserci anche applicazioni server dual-stack in esecuzione sullo stesso host. Quell'host ha indirizzi IPv4 e IPv6 completamente instradabili, e quindi il server DNS autorevole ha un record A e un record AAAA.

• Un client solo IPv6 (indipendentemente dal fatto che l'applicazione client sia solo IPv6, lo stack del client sia solo IPv6, o abbia solo un indirizzo IPv6) vuole accedere al server sopra.

• Il client emette una query DNS a un resolver DNS64.

Se il DNS64 genera un AAAA sintetico solo se non c'è un AAAA reale, allora la comunicazione fallirà. Anche se c'è un AAAA reale, l'unico modo affinché la comunicazione abbia successo è con l'indirizzo tradotto. Quindi, per supportare questo scenario, l'amministratore di un servizio DNS64 può voler abilitare la sintesi di RR AAAA anche quando esistono RR AAAA reali.

L'implicazione di includere RR AAAA sintetici quando esistono RR AAAA reali è che la connettività tradotta può essere preferita rispetto alla connettività nativa in alcuni casi in cui il DNS64 è operato in modalità DNS server.

Le regole RFC 3484 [RFC3484] utilizzano "longest matching prefix" per selezionare l'indirizzo di destinazione preferito da utilizzare. Quindi, se il resolver DNS64 restituisce sia i RR AAAA sintetici che i RR AAAA reali, allora se il DNS64 è operato dallo stesso dominio dell'host iniziatore, e viene utilizzato un prefisso unicast globale (riferito come Network-Specific Prefix (NSP) in [RFC6052]), allora un RR AAAA sintetico è probabilmente preferito.

Questo significa che senza ulteriore configurazione:

• Nello scenario "una rete IPv6 verso l'Internet IPv4", l'host preferirà la connettività tradotta se viene utilizzato un NSP. Se viene utilizzato il Well-Known Prefix definito in [RFC6052], probabilmente preferirà la connettività nativa.

• Nello scenario "Internet IPv6 verso una rete IPv4", è possibile influenzare la selezione verso il RR AAAA reale se il resolver DNS64 restituisce il AAAA reale per primo nella risposta DNS, quando viene utilizzato un NSP (l'uso del Well-Known Prefix non è supportato in questo caso).

• Nello scenario "una rete IPv6 verso una rete IPv4", per destinazioni locali (cioè, host di destinazione all'interno del sito locale), è probabile che l'NSP e il prefisso di destinazione siano gli stessi, quindi possiamo utilizzare l'ordine dei RR nella risposta DNS per influenzare la selezione attraverso la connettività nativa. Se viene utilizzato il Well-Known Prefix, la regola "longest matching prefix" selezionerà la connettività nativa.

Il problema può essere risolto configurando appropriatamente la tabella delle policy di RFC 3484 [RFC3484].