Documentazione dell'infrastruttura Oracle Cloud

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

Risorse DNS

  • 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.
  • Resolver DNS privato: un resolver DNS privato dedicato alla VCN contiene la configurazione che serve le risposte alle query DNS all'interno della VCN. Le viste sul resolver determinano la zona e i dati dei record applicabili per la risoluzione. Il resolver esegue la ricorsione a Internet e alla convalida DNSSEC per le zone firmate DNSSEC. Gli endpoint resolver sul resolver forniscono un'altra entrata e uscita oltre all'ingresso predefinito su 169.254.169.254. Per ulteriori informazioni, vedere Resolver 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.

Risorse VCN:

  • 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

Alcune risorse DNS private, ad esempio zone e viste, sono protette. Le risorse protette vengono gestite automaticamente da Oracle. È possibile visualizzare le risorse protette, ma la modifica è limitata. Le risorse protette non vengono conteggiate ai fini dei limiti o delle quote del servizio.

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

Il resolver ascolta su 169.254.169.254 per impostazione predefinita. Puoi decidere di definire gli endpoint del resolver per un maggior numero di ingressi e uscite. Un endpoint risolutore di ascolto utilizza un indirizzo IP per l'ascolto all'interno della subnet specificata. Un endpoint del resolver di inoltro utilizza due indirizzi IP, un indirizzo non viene utilizzato e il secondo viene utilizzato per l'inoltro. Prima di creare un endpoint del resolver, assicurarsi che nella subnet siano disponibili un numero sufficiente di indirizzi IP.
Importante

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.

Le risposte DNS in una VCN vengono valutate utilizzando la configurazione del resolver dedicato in un ordine specifico:

  1. Ogni vista allegata viene valutata in ordine. La vista predefinita viene valutata per ultima, se non inclusa esplicitamente nell'elenco.
  2. 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.
  3. La query viene risolta su Internet.

Il primo elemento in sequenza in grado di fornire una risposta lo fa. Dopo aver fornito una risposta, non vengono valutati altri elementi, anche se la risposta è negativa.

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

L'ingresso e l'uscita tra le reti VCN o tra le reti VCN e le reti on premise richiedono connettività. Per stabilire una connessione potrebbe essere necessario un peering gateway locale (LPG ), con entrambe le reti VCN collegate allo stesso DRG o una connessione peering remota (RPC ) tra le reti VCN. La connessione tra una rete VCN e reti in locale richiede FastConnect o un tunnel IPSec (VPN da sito a sito).

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.

Per ulteriori informazioni, vedere l'esercitazione Configura viste e risolutori delle zone DNS private.

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 risolutore 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. Vedere anche Trasparenza delle zone DNS privata.

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.

Trasparenza delle zone DNS private

Per le zone DNS private, è possibile impostare la modalità di risoluzione DNS per modificare il funzionamento della risoluzione delle query quando un nome di query corrisponde a un nome di zona. Un caso d'uso comune per la trasparenza è quando un nome di zona esiste in più posizioni, ad esempio in OCI e on-premise. La trasparenza consente l'esistenza dello stesso nome di zona in entrambe le ubicazioni con record di zona diversi. Sono disponibili tre modalità:

  • Statico: si tratta del comportamento predefinito. Se una zona privata copre un nome query, viene restituito un NXDOMAIN se il nome query non è presente nella zona. Viene restituita una risposta NoData se il nome è presente, ma non sono presenti dati per il tipo di query specifico richiesto.
  • Trasparente: se il dominio sottoposto a query è coperto dalla zona, ma il dominio non esiste nella zona o il dominio sottoposto a query corrisponde al nome della zona, ma non esistono record del tipo sottoposto a query, continuare con la valutazione successiva per il risolutore seguendo la sequenza normale per il controllo della risoluzione delle query. Questo aggira efficacemente le risposte NXDOMAIN in tutti i domini e le risposte NoData specificamente all'apice.
  • RTypeTransparent: se il dominio sottoposto a query è coperto dalla zona, ma il dominio sottoposto a query non esiste nella zona o il dominio sottoposto a query esiste nella zona ma non per il tipo di record richiesto, continuare con la valutazione successiva per il resolver seguendo la sequenza normale per il controllo della risoluzione delle query. Questo aggira efficacemente le risposte NXDOMAIN e NoData in tutti i domini.
Nota

Se la trasparenza attiva una sequenza per continuare, la valutazione della risoluzione inizia alla vista successiva della sequenza, se esistente. Si verificano al massimo 2 continuazioni di trasparenza. Se si verifica una terza corrispondenza di trasparenza, viene restituita una risposta SERVFAIL.
Esempi

Per illustrare il funzionamento della trasparenza, le tabelle riportate di seguito forniscono una configurazione di esempio ed esempi relativi alla modalità di risoluzione delle query con le diverse modalità di risoluzione.

Configurazione per le zone private e pubbliche: example.us-ashburn-1.oraclecloud.com
Nome interrogazione Tipo di record RDATA
Zona privata
esempio.us-ashburn-1.oraclecloud.com A 1.2.3.4
bla.example.us-ashburn-1.oraclecloud.com A 5.6.7.8
api.example.us-ashburn-1.oraclecloud.com CNAME esempio.us-ashburn-1.oraclecloud.com
Zona pubblica
esempio.us-ashburn-1.oraclecloud.com A 100.100.100.100
esempio.us-ashburn-1.oraclecloud.com TXT "Salve!"
foo.example.us-ashburn-1.oraclecloud.com A 200.200.200.200
bla.example.us-ashburn-1.oraclecloud.com TXT "Mondo!"
api.example.us-ashburn-1.oraclecloud.com CNAME esempio.us-ashburn-1.oraclecloud.com

Comportamenti per la zona: example.us-ashburn-1.oraclecloud.com
Esempio Nome/tipo query Static Trasparente RTypeTransparent Note
1 esempio.us-ashburn-1.oraclecloud.com/a 1.2.3.4 1.2.3.4 1.2.3.4 Si verifica una corrispondenza sul nome esatto e sul tipo di query, che fornisce il nome privato (quindi 100.100.100.100 non viene mai visualizzato da questo resolver).
2 esempio.us-ashburn-1.oraclecloud.com/txt Nessun dato "Salve!" "Salve!" L'override riguarda il nome, ma non il tipo di query, quindi una zona Static indica NoData (nome esistente, ma non qtype) mentre RtypeTransparent continua su Internet. Poiché si tratta dell'apice della zona, anche Transparent passa in Internet.
3 bla.example.us-ashburn-1.oraclecloud.com/txt Nessun dato Nessun dato "Mondo!" L'override riguarda il nome, ma non il tipo di query, pertanto le zone Static e Transparent indicano NoData (nome esistente, ma non qtype) mentre RtypeTransparent continua a Internet. A differenza di #2, questo non è l'apice, quindi la zona Trasparente non cade attraverso.
4 foo.example.us-ashburn-1.oraclecloud.com/a NXDOMINIO 200.200.200.200 200.200.200.200 Esiste una zona privata corrispondente, pertanto l'impostazione statica indica che "foo" non esiste, ma poiché non esiste una corrispondenza nome, entrambi i campi Transparent e RtypeTransparent continuano su Internet.
5 api.example.us-ashburn-1.oraclecloud.com/a 1.2.3.4 1.2.3.4 1.2.3.4 Poiché CNAME esiste sia nelle zone private che in quelle Internet, tutte e tre le modalità Statico, Trasparente e RtypeTransparent risolvono il record A in 1.2.3.4 dalla zona privata. La modalità Trasparente torna a Internet solo se il tipo di record manca nella zona privata.
6 api.example.us-ashburn-1.oraclecloud.com/txt Nessun dato Nessun dato "Salve!" Per una query TXT CNAME in cui il record esiste solo nella zona Internet, le modalità Statico e Trasparente restituiscono NoData, poiché la zona privata non contiene il tipo di record. RtypeTransparent torna all'area Internet e restituisce il valore TXT.

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 peering gateway locale o remoto (LPG /RPG ). Per inviare traffico dalla VCN A alla VCN B, aggiungere un endpoint di ascolto al resolver della VCN B. Aggiungere quindi 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 VCN, aggiungere un endpoint resolver di inoltro e ascolto a ogni resolver dedicato e aggiungere una regola su ogni resolver dedicato.

Connettività tra una VCN e i server dei nomi in locale

Le richieste possono essere inviate tra una VCN e i name server on premise in entrambe le direzioni. Questa soluzione richiede la connettività tra la VCN e la rete in locale 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 resolver dedicato e una regola che inoltra il traffico attraverso l'endpoint all'indirizzo del name server in locale.

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 . Nell'elenco seguente viene fornita una breve spiegazione dello scopo di ciascun tipo di record supportato per il DNS privato. Per il DNS pubblico, vedere Record delle risorse supportate per il DNS pubblico. Evitare di fornire informazioni riservate durante l'immissione di 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:

RDATA per i tipi di record CNAME, DNAME e MX può contenere uno o più nomi di dominio assoluti. Se l'RDATA specificato per uno di questi tipi di record non termina in un punto o in un punto per rappresentare la radice, il periodo 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 Locator servizio viene utilizzato dagli amministratori per impostare un singolo dominio per più server. 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