DNS privato
Creare e gestire le zone del sistema dei nomi di dominio privato (DNS).
Usare le zone DNS (Private Domain Name Service) per creare le zone private con i nomi di dominio specificati. È possibile gestire completamente le zone e registrare per fornire la risoluzione del nome host per le applicazioni in esecuzione all'interno e tra le reti cloud virtuali (VCN ) e le reti on premise o private. La gestione del traffico è disponibile solo per il DNS pubblico e non è supportata sul DNS privato.
Il DNS privato fornisce anche la risoluzione DNS tra le reti (ad esempio, un'altra VCN all'interno della stessa area, tra più aree o rete esterna). Il DNS privato può essere gestito nell'API e nella console DNS OCI.
Risorse utilizzate in DNS privato
- Zone DNS private: le zone DNS private contengono dati DNS accessibili solo dall'interno di una rete cloud virtuale (VCN), ad esempio gli 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.
- Record di zona DNS privati: per il DNS globale e privato sono supportati tipi di record diversi. Vedere Record risorse supportate.
- Viste DNS private: una vista DNS privata è una raccolta di zone private. Lo stesso nome di zona può essere utilizzato in molte viste, ma i nomi di zona all'interno di una vista devono essere univoci.
-
Risolutore DNS privato: un risolutore DNS privato dedicato alla VCN contiene la configurazione che fornisce risposte alle query DNS all'interno della VCN. Le viste sul resolver decidono i dati di zona e record applicabili per la risoluzione. Gli endpoint del resolver nel resolver forniscono un'altra entrata e uscita oltre all'entrata predefinita in 169.254.169.254. Per ulteriori informazioni, vedere Risolutori DNS privati.
- Endpoint del resolver DNS privato: utilizzare le risorse endpoint del resolver per impostare l'ingresso e l'uscita nella VCN. Gli endpoint del resolver utilizzano gli indirizzi IP nella subnet in cui vengono creati. Viene creata una VNIC corrispondente per ogni endpoint del resolver.
- VCN: quando si crea una VCN, viene creato automaticamente anche un resolver dedicato.
- Subnet: quando si creano gli endpoint del resolver, viene utilizzata una subnet all'interno di una VCN. Gli indirizzi IP della subnet vengono utilizzati per l'ascolto e l'inoltro degli indirizzi.
- Gruppo di sicurezza di rete (NSG): facoltativamente, è possibile configurare una lista di gruppi di sicurezza di rete per gli endpoint del resolver. I gruppi NSG controllano il traffico in entrata e in uscita verso e dall'endpoint del resolver.
Per ulteriori informazioni sulle risorse VCN, consulta la sezione relativa ai resolver DNS privati nella documentazione relativa al networking.
Risorse protette
- Tutti i resolver dedicati alla VCN
- Viste predefinite: ogni resolver dedicato alla VCN dispone di una vista predefinita protetta. È possibile aggiungere altre zone alla vista predefinita, ma si applicano limitazioni ai nomi delle zone per evitare conflitti con le zone protette. Se un resolver viene eliminato e la relativa vista predefinita contiene zone non protette, la vista predefinita viene convertita in una vista non protetta invece di essere eliminata. Puoi creare e collegare una vista a un resolver oltre alla vista predefinita in modo che le relative zone siano risolvibili nella VCN.
Configurazione e risoluzione
DNS
È possibile creare una struttura dominio completa o parziale. Una vista può essere utilizzata da qualsiasi numero di resolver e condividere dati DNS privati tra le VCN all'interno della stessa area. È possibile utilizzare queste zone per il DNS split-horizon perché lo stesso nome di zona può essere utilizzato in una zona privata e in una zona Internet. È possibile fornire risposte diverse per le query pubbliche e private all'interno di una VCN.
La subnet per gli endpoint DNS privati deve essere solo IPv4. La richiesta di creare un endpoint DNS privato in una subnet abilitata per IPv6 non riesce.
Aggiungere regole per definire la logica per la risposta alle query. L'unico tipo di regola supportato è FORWARD. Questa regola inoltra in modo condizionale una query a un IP di destinazione in base all'IP client o al target QNAME . L'indirizzo IP di destinazione può essere relativo a un'impostazione in locale, a una rete privata o a un endpoint del resolver di ascolto in una VCN diversa. La regola resolver qnameCoverConditions copre le corrispondenze esatte e anche i sottodomini.
- Ogni vista allegata viene valutata in ordine. La vista predefinita viene valutata per ultima, se non inclusa esplicitamente nell'elenco.
- Le regole resolver vengono valutate in ordine. Viene applicata la prima regola del resolver che corrisponde alla vista. Qualsiasi regola più in basso nell'elenco con condizioni duplicate (incluse le condizioni) rispetto a una precedente non viene mai valutata. Un esempio di regola irraggiungibile è una regola qnameCoverCondition o clientAddressConditions più specifica dopo una più generale; se la regola più generale è una corrispondenza, la regola più specifica non viene mai valutata.
- La query viene risolta su Internet.
Ad esempio, se un nome di query è incluso da una zona in una vista privata e il nome non esiste nella zona, la zona restituisce una risposta NXDOMAIN affidabile.
VCN
I collegamenti in entrata e in uscita tra le reti VCN o tra le reti VCN e le reti on premise richiedono connettività. La creazione di una connessione potrebbe richiedere un Local Peering Gateway (LPG ) o un Remote Peering Gateway (RPG ) tra VCN. La connessione tra una VCN e le reti in locale richiede FastConnect o un tunnel IPSec (IPSec VPN).
Gli elenchi di sicurezza VCN e qualsiasi NSG di riferimento devono consentire il traffico richiesto. È necessario abilitare DHCP nella lista di sicurezza per l'ingresso e l'uscita e includere l'indirizzo IP dell'endpoint del resolver corrispondente. Le regole di sicurezza per gli endpoint di ascolto devono consentire l'ingresso UDP senza connessione sulla porta di destinazione 53, l'uscita UDP senza connessione sulla porta di origine 53 e l'ingresso TCP sulla porta di destinazione 53. Le regole di sicurezza per gli endpoint di inoltro devono consentire l'uscita UDP senza connessione sulla porta di destinazione 53, l'ingresso UDP senza connessione sulla porta di origine 53 e l'uscita TCP sulla porta di destinazione 53.
Casi d'uso
Zone DNS personalizzate all'interno di una VCN
Le zone DNS private sono raggruppate in viste . Tutti i resolver dedicati alla VCN dispongono di una vista predefinita creata automaticamente. Per creare una zona DNS personalizzata che si risolve dall'interno di una VCN, creare la zona privata nella vista predefinita del resolver dedicato oppure creare la zona in una nuova vista e aggiungerla alla lista di viste collegate del resolver dedicato. Per una guida dettagliata su come impostare questa impostazione, vedere Help Center/Configure private DNS zones views and resolver.
Fraziona orizzonte
Creare zone private con gli stessi nomi dei nomi pubblici su Internet. Quindi, aggiungere le zone a una delle viste del resolver VCN . All'interno della VCN, i nomi vengono risolti in base alla configurazione DNS privata. Gli stessi nomi forniscono risposte diverse a seconda dell'origine della richiesta.
Zone DNS private condivise all'interno di un'area
Le reti VCN all'interno della stessa area possono risolvere le richieste dalle rispettive viste private. Si supponga, ad esempio, di voler implementare questa soluzione con la VCN A e la VCN B. Aggiungi la vista predefinita del resolver dedicato della VCN A alle viste collegate del resolver dedicato della VCN B. Quindi, aggiungi la vista predefinita del resolver dedicato della VCN B alle viste collegate del resolver dedicato della VCN A.
È possibile riutilizzare la stessa zona privata o la stessa raccolta di zone private in più VCN. Questa soluzione può ridurre la duplicazione della configurazione DNS. Creare una vista e aggiungere una o più zone private alla vista. Per ogni VCN, aggiungere la nuova vista alla lista di viste collegate del resolver dedicato della VCN. Per una guida dettagliata su come impostare questa impostazione, vedere Help Center/Configure private DNS zones views and resolver.
Risoluzione DNS tra VCN
Invia richieste tra VCN utilizzando gli endpoint del resolver. Le reti VCN possono esistere in aree diverse. Questa soluzione richiede un Local o Remote Peering Gateway (LPG /RPG ). Per inviare traffico dalla VCN A alla VCN B, aggiungere un endpoint di ascolto al resolver della VCN B. Quindi, aggiungi un endpoint di inoltro al resolver dedicato della VCN A. Crea una regola sul resolver dedicato della VCN A che inoltra il traffico attraverso l'endpoint di inoltro della VCN A all'indirizzo dell'endpoint di ascolto della VCN B. Per inviare traffico in entrambe le direzioni tra le reti VCN, aggiungere un endpoint del resolver di inoltro e di ascolto a ogni resolver dedicato e aggiungere una regola a ogni resolver dedicato. Vedere A-Team Chronicles/Implementazione DNS privata per una guida dettagliata su come impostare questa impostazione.
Connettività tra una VCN e i server dei nomi in locale
Le richieste possono essere inviate tra una VCN e i name server in locale in entrambe le direzioni. Questa soluzione richiede la connettività tra la VCN e la rete on premise utilizzando FastConnect o un tunnel IPSec (IPSec VPN). Per inviare traffico a una VCN, aggiungere un endpoint di ascolto al resolver dedicato e inviare traffico al relativo indirizzo. Per inviare traffico da una VCN, aggiungere un endpoint di inoltro al relativo resolver dedicato e una regola che inoltra il traffico attraverso l'endpoint all'indirizzo del name server in locale. Vedere A-Team Chronicles/Implementazione DNS privata per una guida dettagliata su come impostare questa impostazione.
Casi d'uso avanzati
È possibile impostare le reti VCN per più casi d'uso. Una singola VCN può essere sottoposta a peering con un'altra VCN e configurata per connettersi a un name server in locale. L'inoltro può anche essere incatenato in molti VCN.
Record risorse supportate
Il servizio Oracle Cloud Infrastructure DNS supporta molti tipi di risorse record . L'elenco seguente fornisce una breve spiegazione dello scopo di ciascun tipo di record supportato per il DNS privato. Per il DNS pubblico, vedere Record di risorse supportate dal DNS pubblico. Evitare di inserire informazioni riservate quando si immettono i dati dei record. I collegamenti RFC consentono di ottenere ulteriori informazioni sui tipi di record e sulla struttura dei dati.
Nota su RDATA
OCI normalizza tutte le RDATA nel formato più leggibile dal computer. La presentazione restituita di RDATA può differire dal suo input iniziale.
Ad esempio:
L'RDATA per i tipi di record CNAME, DNAME e MX può contenere uno o più nomi dominio assoluti. Se il valore RDATA specificato per uno di questi tipi di record non termina con un punto o un punto per rappresentare la radice, il punto viene aggiunto.
www.example.com --> www.example.com.
È possibile utilizzare varie librerie DNS per normalizzare RDATA prima dell'input.
| Linguaggio di programmazione | libreria |
|---|---|
| Esegui | Libreria DNS in movimento |
| Java | dnsjava |
| Python | dnspython |
Tipi di record risorsa DNS privato
- A
- Un record di indirizzo utilizzato per puntare un nome host a un indirizzo IPv4. Per ulteriori informazioni sui record A, vedere RFC 1035.
- AAAA
- Un record indirizzo utilizzato punta un nome host a un indirizzo IPv6. Per ulteriori informazioni sui record AAAA, vedere RFC 3596.
- CAA
- Un record Autorizzazione autorità di certificazione viene utilizzato da un titolare del nome di dominio per specificare una o più autorità di certificazione autorizzate a rilasciare certificati per tale dominio. Per ulteriori informazioni sui record CAA, vedere RFC 6844.
- CNAME
- Un record Nome canonico identifica il nome canonico di un dominio. Per ulteriori informazioni sui record CNAME, vedere RFC 1035.
- DNAME
- Un record Nome delega ha un funzionamento simile a quello di un record CNAME, ma mappa un'intera struttura secondaria sotto un'etichetta a un altro dominio. Per ulteriori informazioni sui record DNAME, vedere RFC 6672.
- MX
- Un record Mail Exchanger definisce il server di posta che accetta la posta per un dominio. I record MX devono puntare a un nome host. I record MX non devono puntare a un CNAME o a un indirizzo IP. Per ulteriori informazioni sui record MX, vedere RFC 1035.
- PTR
- Un record Pointer esegue il mapping inverso di un indirizzo IP a un nome host. Questo comportamento è l'opposto di un record A, che mappa in avanti un nome host a un indirizzo IP. I record PTR si trovano in genere nelle zone DNS inverse. Per ulteriori informazioni sui record PTR, vedere RFC 1035.
- SRV
- Un record Service Locator consente agli amministratori di utilizzare più server per un singolo dominio. Per ulteriori informazioni sui record SRV, vedere RFC 2782.
- TXT
- Un record di testo contiene testo descrittivo leggibile dall'utente e può includere anche contenuti non leggibili dall'utente per usi specifici. Questo tipo di record viene in genere utilizzato per i record SPF e DKIM che richiedono elementi di testo non leggibili dall'utente. Per ulteriori informazioni sui record TXT, vedere RFC 1035.
Criteri IAM necessari
Per utilizzare il DNS privato, un utente ha bisogno di un'autorità sufficiente (mediante un criterio IAM). Gli utenti del gruppo Amministratori dispongono dell'autorità necessaria. Se un utente non si trova nel gruppo Administrators, un criterio come questo consente a un gruppo specifico di gestire il DNS privato:
Allow group <GroupName> to manage dns in tenancy where target.dns.scope = 'private'Se non si ha familiarità con i criteri, vedere Introduzione ai criteri e Criteri comuni. Per ulteriori informazioni sui criteri per il DNS privato, vedere Riferimento ai criteri DNS.
Task DNS privati
Impostazione del DNS privato
Task DNS privati
Task VCN
Per creare una VCN con un resolver DNS dedicato, vedere Panoramica delle VCN e delle subnet e DNS nella rete cloud virtuale per ulteriori informazioni.