Nota

Questa esercitazione richiede l'accesso a Oracle Cloud. Per iscriverti a un account gratuito, consulta Inizia a utilizzare Oracle Cloud Infrastructure Free Tier.
Utilizza valori di esempio per le credenziali, la tenancy e i compartimenti di Oracle Cloud Infrastructure. Al termine del laboratorio, sostituisci questi valori con quelli specifici del tuo ambiente cloud.

Usa Oracle Cloud Infrastructure DNS per risolvere i domini nativi

Introduzione

OraStage è un'azienda leader nel settore energetico, specializzata in soluzioni di energia rinnovabile e tecnologie energetiche innovative, l'azienda ha annunciato una decisione strategica per migrare i propri carichi di lavoro su Oracle Cloud Infrastructure (OCI) per migliorare prestazioni, scalabilità e sicurezza.

immagine

Tenendo conto delle esigenze e delle condizioni specifiche che OraStage ha delineato, l'azienda richiede una soluzione ibrida DNS (Domain Name System) nel cloud, e tramite ibrido qui significa utilizzare il proprio sistema DNS Berkeley Internet Name Domain versione 9 (BIND9) in aggiunta al servizio DNS OCI, dove l'architettura finale che si sta cercando di creare è mostrata nella seguente immagine.

immagine

OraStage Requisiti DNS:

L'azienda ha diversi domini interni e sottodomini, tutti devono essere risolti dal proprio DNS BIND9 in OCI, dove OraStage gestirà tutte le zone e i record correlati. Uno di questi domini è orastage.com che useremo in questo tutorial. Pertanto, qualsiasi query a orastage.com deve essere inoltrata al proprio BIND9.
In alcuni casi devono ancora risolvere i domini nativi OCI (oraclevcn.com, oraclecloud.com e così via) e questa operazione verrà eseguita utilizzando i componenti DNS privati OCI: viste private, endpoint e regole di inoltro e endpoint di ascolto.
Tutte le query devono essere ispezionate da un'istanza del firewall pfSense.
Per evitare un singolo punto di errore, OraStage prevede di utilizzare un altro server DNS e sfruttare il load balancer OCI per distribuire le query tra il DNS primario e quello secondario.

Questa serie di esercitazioni ti guiderà passo dopo passo per raggiungere i requisiti descritti sopra, costruendo l'intera soluzione da zero. È possibile accedere facilmente a ciascun tutorial dall'elenco seguente:

Esercitazione 1: Configura BIND9 DNS in OCI. Scopri come installare e configurare BIND9 su un'istanza di computazione, rendendolo il server DNS locale per due ambienti di test in OCI. Questi ambienti saranno costituiti da server "Frontend" e "Backend", ciascuno ospitato in una rete spoke separata. Il server BIND9 gestirà tutte le query DNS dirette a orastage.com.
Esercitazione 2: Implementa High Availability su BIND9 scenario DNS in OCI. Questa esercitazione si concentra sull'aggiunta di un server BIND9 secondario e sulla configurazione di un load balancer di rete (NLB) per distribuire il traffico DNS tra entrambi i server. Le query DNS su orastage.com verranno indirizzate all'IP NLB, che bilancierà il carico tra i server BIND9 primari e secondari. Se un server non è più disponibile, la risoluzione DNS continuerà senza interruzione del servizio.
Esercitazione 3: Utilizza DNS OCI per risolvere i domini nativi. Concentrandosi solo su uno specifico caso d'uso, in cui utilizziamo componenti DNS nativi in OCI, nel caso in cui sia necessario risolvere domini nativi come oraclevcn.com e oraclecloud.com. BIND9 DNS non viene utilizzato in questa esercitazione.
Esercitazione 4: aggiunta della sicurezza all'architettura DNS mediante il firewall pfSense. Concentrarsi sull'installazione di un firewall pfSense nella VCN hub in OCI ed eseguire la configurazione di rete necessaria per instradare tutto il traffico East-West, incluse le query DNS (eseguite nelle esercitazioni precedenti) attraverso il firewall da ispezionare.

Panoramica

In questo tutorial, ci concentreremo sulla gestione dei domini nativi OCI come oraclevcn.com e oraclecloud.com. In questa sezione, ci allontaneremo dalla risoluzione di domini personalizzati come orastage.com utilizzando BIND9 ed esploreremo invece le funzionalità DNS integrate OCI.

Ci immergeremo nei componenti del DNS privato OCI e negli elementi chiave coinvolti nella gestione delle query, che svolgono ruoli cruciali nella gestione del traffico DNS all'interno delle reti private OCI. Si noterà che li abbiamo già utilizzati in alcune parti di Tutorial 1 e Tutorial 2. che includono:

Zona DNS privata: contiene dati DNS accessibili solo dall'interno di una VCN ad esempio indirizzi IP privati. Una zona DNS privata dispone di capacità simili a una zona DNS Internet, ma fornisce risposte solo per i client che possono raggiungerla tramite una VCN. Ogni zona appartiene a una singola vista.
Vista DNS privata: un raggruppamento di zone private, ciascuna vista può essere associata a un resolver per controllare la modalità di risoluzione delle query DNS. Una singola vista può essere utilizzata da più resolver, consentendo la condivisione dei dati DNS privati tra diverse VCN. Ogni zona può essere solo parte di una vista.

Ad esempio, sono state create due nuove VCN: VCN-A e VCN-B. Per impostazione predefinita, le risorse all'interno della rete VCN-A possono risolversi a vicenda senza ulteriori configurazioni, poiché i relativi record vengono memorizzati nella stessa zona privata, che si trova nella rete VCN-A vista privata. Stessa cosa per la VCN-B. Tuttavia, se desideri che le risorse nella rete VCN-A risolvano le risorse nella rete VCN-B, devi associare la vista privata della rete VCN-B al resolver VCN-A. Se desideri che le risorse nella rete VCN-B risolvano le risorse nella rete VCN-A, devi associare la vista privata della rete VCN-A al resolver VCN-B.
Risolutore DNS privato: un resolver DNS privato dedicato alla VCN fornisce risposte alle query DNS nell'ordine seguente: controllerà innanzitutto le zone nelle viste private collegate, quindi nella vista predefinita, quindi controllando le regole di inoltro e infine utilizzando il DNS Internet. In pratica, è il motore che cerca le risposte alle query della tua istanza.

Ad esempio, lo screenshot di immagine riportato di seguito mostra una pagina del resolver VCN. La sequenza seguita durante la risoluzione di una query da un'istanza in questa VCN avrà lo stesso effetto:
Inoltro di endpoint e regole: gli endpoint di inoltro fungono da connettori tra la VCN OCI e i resolver DNS esterni o altre zone DNS. Utilizzando le regole di inoltro, puoi indirizzare query DNS specifiche a server o listener esterni designati in altri resolver VCN, abilitando architetture DNS cloud ibride o risoluzione multizona.
Endpoint di ascolto: questi endpoint vengono utilizzati per ricevere query DNS da origini esterne. Consentono alla tua infrastruttura DNS OCI di ascoltare e rispondere alle richieste DNS in entrata, migliorando la capacità di gestire le query DNS in varie configurazioni di rete.

Insieme, questi componenti forniscono potenti strumenti per la gestione e la personalizzazione del DNS all'interno dell'ambiente OCI.

Alla fine di questa esercitazione, avrai una solida conoscenza di come utilizzare questi componenti DNS OCI per gestire e risolvere in modo efficiente le query all'interno del tuo ambiente cloud.

Obiettivi

L'obiettivo principale di questa esercitazione è consentire al client FE-VM (fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com) di eseguire una query su BE-VM (be-vm.beprivatesubnet.backendvcn.oraclevcn.com) e viceversa, con il listener LSN per rispondere a tutte queste query.

Architettura finale

immagine

Nota:

Quando crei inizialmente una VCN e una subnet, puoi specificare le etichette DNS per ogni istanza di computazione, quindi avviarne una, puoi assegnare un nome host. Alla fine, il nome dominio completamente qualificato (FQDN) dell'istanza sarà simile al seguente: <VM-HOSTNAME>.<SUBNET-DNS-Label>.<VCN-DNS-Label>.oraclevcn.com. La specifica di queste etichette è facoltativa. Se le si lascia vuote, verranno assegnati nomi casuali presi dal nome della risorsa, proprio come FE-VM e BE-VM in questa esercitazione.

Se avevamo solo bisogno di risorse OCI per risolverci a vicenda, qui non è necessario un listener, poiché questo può essere fatto solo utilizzando viste private come indicato nella sezione Panoramica. Tuttavia, il motivo alla base della scelta di utilizzare un listener qui è anche quello di gestire la risoluzione DNS da qualsiasi altro ambiente, ad esempio on premise e altri cloud, e l'aggiunta di tutte le viste private al resolver di questo listener sarà sufficiente. Questa impostazione risolve un caso d'uso specifico in cui potrebbero essere necessari anche altri ambienti (on-premise o altri ambienti cloud) per risolvere le risorse OCI. Tuttavia, questo non è incluso in questo tutorial.

Tutte le query oraclevcn.com e oraclecloud.com devono essere inoltrate allo stesso listener, indipendentemente dal fatto che la query provenga da OCI, dalla rete in locale o da un'altra rete di provider cloud, poiché il resolver per la VCN LSN gestirà tutte queste query da viste private.

In questa esercitazione non verranno sottoposte a test le query da ambienti on premise o Microsoft Azure, ma solo da istanze OCI. Pertanto, il seguente diagramma è solo a scopo illustrativo.

Prerequisiti

Accesso a una tenancy OCI e autorizzazioni per gestire la rete e i servizi di computazione necessari.
Comprensione di base dell'instradamento e della sicurezza della rete OCI e relative funzionalità: rete cloud virtuale (VCN), tabella di instradamento, gateway di instradamento dinamico (DRG), lista di sicurezza, bastion e load balancer di rete OCI.
Conoscenza di base del DNS in generale.
Assicurati di completare i primi due tutorial:
1. Configurare BIND9 Domain Name System in Oracle Cloud Infrastructure.
2. Implementa High Availability su BIND9 Domain Name System in Oracle Cloud Infrastructure.
Una VCN è necessaria con una subnet privata e la collega al DRG esistente. Per ulteriori informazioni, vedere Task 1.3: collegare VCN al DRG.
- VCN LSN: questa operazione ospiterà il listener. Tenere presente che il listener non deve trovarsi in una VCN dedicata, ma in questa esercitazione si è preferito eseguire questa operazione per separarlo da altre risorse.
In base ai prerequisiti, si dovrebbe aver già costruito la seguente architettura.

Task 1: Impostare componenti di rete come Routing e sicurezza

Task 1.1: creare una rete cloud virtuale (LSN-VCN)

Assicurarsi di avere già creato la VCN LSN (10.3.0.0/16), contenente LSN-Private-Subnet (10.3.0.0/24).

Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Networking.
2. Fare clic su Reti cloud virtuali.
Possiamo vedere la VCN in posizione, attualmente dispone di una sola subnet privata e la tabella di instradamento e la lista di sicurezza predefinite collegate ad essa.

Task 1.2: Configura instradamento e sicurezza per LSN-VCN

Questa operazione deve essere eseguita a livello di subnet. Passare alla pagina VCN e fare clic su LSN-VCN.
Fare clic sulla subnet privata.
Fare clic su Tabella di instradamento, che è una tabella di instradamento assegnata.
Aggiungere le seguenti regole.
- 10.0.0.0/16 - DRG: instrada il traffico destinato alla DNS-VCN nel gateway DRG.
- 10.1.0.0/16: DRG: instrada il traffico destinato a VCN frontend nel gateway DRG.
- 10.2.0.0/16 - DRG: instrada il traffico destinato alla VCN backend nel gateway DRG.
Facciamo la sicurezza ora. Andare alla pagina Dettagli subnet e fare clic sulla lista di sicurezza assegnata.
Consenti traffico in entrata: traffico DNS (TCP/port 53 e UDP/port 53) da DNS-VCN, VCN frontend e VCN backend.
Consentire tutto il traffico in uscita.

Task 1.3: Configurare l'instradamento e la sicurezza per la rete DNS-VCN

Passare alla pagina VCN e fare clic su DNS-VCN.
Fare clic sulla subnet privata.
Fare clic su Tabella di instradamento, che è una tabella di instradamento assegnata.
Aggiungere le seguenti regole.
- 10.3.0.0/16: DRG: instrada il traffico destinato a LSN-VCN nel gateway DRG.
Le regole di sicurezza necessarie sono già state aggiunte. Per ulteriori informazioni, vedere l'Esercitazione 1: Task 1.4 - Configurare l'instradamento e la sicurezza per la DNS-VCN.

Task 1.4: Configura instradamento e sicurezza per VCN frontend

Ripetere i passi eseguiti nel task 1.3 per la rete VCN frontend.

Task 1.5: Configurare l'instradamento e la sicurezza per la rete VCN backend

Ripetere i passi eseguiti nel task 1.3 per la VCN backend.

Task 2: configurare i componenti DNS privati OCI

Task 2.1: Aggiungi viste private a resolver VCN LSN

Passare a LSN-VCN e fare clic su Risolutore DNS.
1. Scorrere verso il basso e fare clic su Viste private associate.
2. Fare clic su Gestisci viste private.
3. Selezionare le viste private di DNS-VCN, VCN frontend e VCN backend.
4. Fare clic su Salva modifiche.
5. Aggiunta delle viste private riuscita.
Al momento, il resolver LSN-VCN ha visibilità su tutti i record DNS creati nelle altre zone private. Pertanto, quando il listener riceve qualsiasi query nei nomi FQDN FE-VM e BE-VM, verrà risolto direttamente utilizzando le viste private associate.

Task 2.2: Configurare l'endpoint di ascolto nel resolver VCN LSN

Andare a OCI Console.
1. Nello stesso resolver, fare clic su Endpoint.
2. Fare clic su Crea endpoint.
3. Nome: immettere un nome per l'endpoint.
4. Subnet: selezionare la subnet privata della VCN LSN.
5. Tipo di endpoint: selezionare Ascolto.
6. Indirizzo IP di ascolto: immettere 10.3.0.6.
7. Fare clic su Crea endpoint.
8. Creazione dell'endpoint di ascolto riuscita.

Task 2.3: configurare la regola di inoltro nel resolver VCN frontend

Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Networking.
2. Fare clic su Reti cloud virtuali.
Fare clic su VCN frontend.

immagine

Fare clic sul resolver DNS della VCN.

immagine

scorrere in Basso.
1. Fare clic su Regole.
2. Fare clic su Gestisci regole.
3. Aggiungere un'altra regola con le seguenti informazioni, come mostrato nello screenshot.
4. Fare clic su Salva modifiche.
5. Creazione della regola di inoltro riuscita.

Task 2.4: Configurare la regola di inoltro nel resolver VCN backend

Clicca sul menu hamburger (≡) dall'angolo in alto a sinistra.
1. Fare clic su Networking.
2. Fare clic su Reti cloud virtuali.
Fare clic su VCN backend.
Fare clic sul resolver DNS della VCN.
scorrere in Basso.
1. Fare clic su Regole.
2. Fare clic su Gestisci regole.
3. Aggiungere un'altra regola con le seguenti informazioni, come mostrato nello screenshot.
4. Fare clic su Salva modifiche.
5. Creazione della regola di inoltro riuscita.
L'architettura dovrebbe essere così.

Task 3: Esegui test e convalida

Scenario di test 1: FE-VM per eseguire una query sul listener per il dominio nativo BE-VM

Il computer client FE-VM deve essere in grado di risolvere be-vm.beprivatesubnet.backendvcn.oraclevcn.com. La seguente immagine illustra lo scenario di test che intendiamo raggiungere.
Andare alla console OCI, andare all'istanza VM_BE e copiare FQDN interno per utilizzarlo nel test.
Accedi a FE-VM ed esegui un test di query utilizzando il servizio OCI Bastion come Esercitazione 2: Test scenario 1 - DNS primario risponde alle query FE-VM quando il DNS secondario è inattivo. Una volta connessa, eseguire le query oraclevcn.com da FE-VM a be-vm.beprivatesubnet.backendvcn.oraclevcn.com e convalidare la configurazione. È possibile utilizzare vari metodi per verificare che l'impostazione funzioni correttamente.
1. Eseguire il comando host.
2. Eseguire il comando ping.
3. Eseguire il comando dig.

Come mostrato nello scenario di test, è possibile recuperare l'indirizzo IP del dominio nativo BE-VM e il ping funziona utilizzando il nome FQDN, il che significa che il test è riuscito.

Scenario di test 2: BE-VM per eseguire query sul listener per il dominio nativo FE-VM

Il computer client BE-VM deve essere in grado di risolvere fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com. La seguente immagine illustra lo scenario di test che intendiamo raggiungere.
Andare alla console OCI, andare all'istanza FE-VM e copiare il FQDN interno per utilizzarlo nel test.
Accedere a VM_BE ed eseguire un test delle query utilizzando il servizio Bastion OCI. Una volta stabilita la connessione, eseguire le query oraclevcn.com da VM_BE a fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com e convalidare la configurazione. È possibile utilizzare vari metodi per verificare che l'impostazione funzioni correttamente.
1. Eseguire il comando host.
2. Eseguire il comando ping.
3. Eseguire il comando dig.

Come mostrato nello scenario di test, è possibile recuperare l'indirizzo IP del dominio nativo BE-VM e il ping funziona utilizzando il nome FQDN, il che significa che il test è riuscito.

Passi successivi

In questa esercitazione sono state utilizzate le viste private, gli endpoint e regole di inoltro e gli endpoint di ascolto OCI che offrono una gestione DNS flessibile e affidabile all'interno di una rete cloud virtuale. Insieme, questi componenti semplificano le operazioni DNS, garantendo una risoluzione dei nomi efficiente e scalabile all'interno degli ambienti OCI, in particolare per uno scenario DNS ibrido che include ambienti multicloud e on-premise integrati.

Nella prossima e ultima esercitazione di questa serie, Aggiungi sicurezza all'architettura DNS utilizzando il firewall pfSense, miglioreremo la sicurezza della nostra infrastruttura DNS configurando il firewall pfSense per ispezionare e controllare tutte le query DNS, ciò includerà le richieste di monitoraggio e filtro sia per i domini OCI interni (oraclevcn.com e oraclecloud.com) che per i domini personalizzati gestiti in BIND9, ad esempio orastage.com.

Conferme

Autore - Anas abdallah (esperto di cloud networking)

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti gratuiti sulla formazione su Oracle Learning YouTube channel. Inoltre, visita education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.

Per la documentazione del prodotto, visita l'Oracle Help Center.

Titolo e informazioni sul copyright

Use Oracle Cloud Infrastructure DNS to Resolve Native Domains

G16585-02