Criteri server DNS

Puoi configurare un criterio del server DNS per ogni rete Virtual Private Cloud (VPC). Il criterio può specificare l'inoltro DNS in entrata, l'inoltro DNS in uscita o entrambi. In questa sezione, il criterio del server in entrata fa riferimento a un criterio che consente l'inoltro DNS in entrata. Il criterio del server in uscita fa riferimento a un possibile metodo per implementare l'inoltro DNS in uscita. Un criterio può essere sia un criterio del server in entrata che un criterio del server in uscita se implementa le funzionalità di entrambi.

Per ulteriori informazioni, consulta Applicare i criteri dei server Cloud DNS.

Criteri del server in entrata

Ogni rete VPC fornisce servizi di risoluzione dei nomi Cloud DNS alle istanze di macchine virtuali (VM) dotate di un'interfaccia di rete (vNIC) collegata alla rete VPC. Quando una VM utilizza il proprio server di metadati 169.254.169.254 come server dei nomi, Google Cloud cerca le risorse Cloud DNS in base all'ordine di risoluzione dei nomi di rete VPC.

Per rendere disponibili i servizi di risoluzione dei nomi di una rete VPC alle reti on-premise collegate alla rete VPC tramite tunnel Cloud VPN, collegamenti VLAN di Cloud Interconnect o appliance router, puoi utilizzare un criterio del server in entrata.

Quando crei un criterio del server in entrata, Cloud DNS crea i punti di ingresso dei criteri del server in entrata nella rete VPC a cui viene applicato il criterio del server. I punti di ingresso dei criteri del server in entrata sono indirizzi IPv4 interni provenienti dall'intervallo di indirizzi IPv4 principali di ogni subnet nella rete VPC applicabile, tranne le subnet con dati --purpose specifici, come le subnet solo proxy per determinati bilanciatori del carico e le subnet utilizzate da Cloud NAT per Private NAT.

Ad esempio, se hai una rete VPC che contiene due subnet nella stessa regione e una terza subnet in una regione diversa, quando configuri un criterio del server in entrata per la rete VPC, Cloud DNS utilizza un totale di tre indirizzi IPv4 come punti di ingresso dei criteri del server in entrata, uno per subnet.

Per informazioni su come creare un criterio del server in entrata per un VPC, vedi Creare un criterio del server in entrata.

Rete e regione per le query in entrata

Per elaborare le query DNS inviate ai punti di ingresso dei criteri del server in entrata, Cloud DNS associa la query a una rete VPC e a una regione:

  • La rete VPC associata a una query DNS è la rete VPC che contiene il tunnel Cloud VPN, il collegamento VLAN Cloud Interconnect o l'interfaccia di rete dell'appliance router che riceve i pacchetti per la query DNS.

    • Google consiglia di creare un criterio del server in entrata nella rete VPC che si connette alla rete on-premise. In questo modo, i punti di ingresso dei criteri del server in entrata si trovano nella stessa rete VPC dei tunnel Cloud VPN, dei collegamenti VLAN di Cloud Interconnect o delle appliance router che si connettono alla rete on-premise.

    • Una rete on-premise può inviare query ai punti di ingresso dei criteri del server in entrata in una rete VPC diversa, ad esempio se la rete VPC contenente i tunnel Cloud VPN, i collegamenti VLAN di Cloud Interconnect o le appliance router che si connettono alla rete on-premise è connessa anche a una rete VPC diversa tramite peering di rete VPC. Tuttavia, non è consigliabile utilizzare questa configurazione perché la rete VPC associata per le query DNS non corrisponde alla rete VPC contenente i punti di ingresso dei criteri dei server in entrata. Ciò significa che le query DNS non vengono risolte utilizzando le zone private e i criteri di risposta di Cloud DNS nella rete VPC contenente il criterio del server in entrata. Per evitare confusione, ti consigliamo invece di seguire questi passaggi di configurazione:

      1. Crea un criterio del server in entrata nella rete VPC che si connetta alla rete on-premise utilizzando tunnel Cloud VPN, collegamenti VLAN di Cloud Interconnect o appliance router.
      2. Configura i sistemi on-premise per l'invio di query DNS agli entry point dei criteri del server in entrata configurati nel passaggio precedente.
      3. Configura le risorse Cloud DNS autorizzate per la rete VPC che si connette alla rete on-premise. Utilizza uno o più dei seguenti metodi:

        • Aggiungi la rete VPC che si connette alla rete on-premise all'elenco delle reti autorizzate per le zone private di Cloud DNS autorizzate per l'altra rete VPC: se una zona privata di Cloud DNS e la rete VPC che si connette alla rete on-premise si trovano in progetti diversi della stessa organizzazione, utilizza l'URL di rete completo quando autorizzi la rete. Per maggiori informazioni, consulta Configurare l'associazione tra progetti.
        • Zone di peering Cloud DNS autorizzate per la rete VPC che si connette alla rete on-premise: imposta la rete di destinazione della zona di peering sull'altra rete VPC. Non è importante se la rete VPC che si connette alla rete on-premise è connessa alla rete VPC di destinazione della zona di peering utilizzando il peering di rete VPC, poiché le zone di peering Cloud DNS non si basano sul peering di rete VPC per la connettività di rete.
  • La regione associata a una query DNS è sempre quella che contiene il tunnel Cloud VPN, il collegamento VLAN di Cloud Interconnect o l'interfaccia di rete dell'appliance router che riceve i pacchetti per la query DNS, non la regione della subnet contenente il punto di ingresso dei criteri del server in entrata.

    • Ad esempio, se i pacchetti per una query DNS vengono inseriti in una rete VPC utilizzando un tunnel Cloud VPN situato nella regione us-east1 e vengono inviati a un punto di ingresso dei criteri del server in entrata nell'area geografica us-west1, la regione associata alla query DNS è us-east1.
    • Come best practice, invia query DNS all'indirizzo IPv4 di un punto di ingresso dei criteri del server in entrata nella stessa regione del tunnel Cloud VPN, del collegamento VLAN Cloud Interconnect o dell'appliance router.
    • La regione associata a una query DNS è importante se utilizzi i criteri di routing di geolocalizzazione. Per ulteriori informazioni, consulta Gestire i criteri di routing e i controlli di integrità del DNS.

Annuncio di route del punto di ingresso del criterio del server in entrata

Poiché gli indirizzi IP del punto di ingresso dei criteri del server in entrata vengono presi dagli intervalli di indirizzi IPv4 principali delle subnet, i router Cloud pubblicizzano questi indirizzi IP quando la sessione BGP (Border Gateway Protocol) per un tunnel Cloud VPN, un collegamento VLAN Cloud Interconnect o un'appliance router sono configurati in modo da utilizzare la modalità annuncio predefinita del router Cloud. Puoi anche configurare una sessione BGP per pubblicizzare gli indirizzi IP dei punti di ingresso dei criteri del server in entrata se utilizzi la modalità di pubblicità personalizzata del router Cloud in uno dei seguenti modi:

  • Pubblichi intervalli di indirizzi IP di subnet oltre ai tuoi prefissi personalizzati.
  • Includi gli indirizzi IP del punto di ingresso dei criteri del server in entrata nei tuoi annunci con prefisso personalizzati.

Criteri del server in uscita

Puoi modificare l'ordine di risoluzione dei nomi di Cloud DNS di una rete VPC creando un criterio del server in uscita che specifichi un elenco di server dei nomi alternativi. Quando una VM utilizza il proprio server di metadati 169.254.169.254 come server dei nomi e se hai specificato server dei nomi alternativi per una rete VPC, Cloud DNS invia tutte le query ai server dei nomi alternativi a meno che le query non vengano abbinate a un criterio di risposta con ambito cluster di Google Kubernetes Engine o a una zona privata con ambito cluster GKE.

Quando in un criterio del server in uscita sono presenti due o più server dei nomi alternativi, Cloud DNS classifica i server dei nomi alternativi ed esegue le query come descritto nel primo passaggio dell'ordine di risoluzione dei nomi del VPC.

Per informazioni su come creare criteri per il server in uscita, consulta Creazione di un criterio per il server in uscita.

Tipi di server dei nomi, metodi di routing e indirizzi alternativi

Cloud DNS supporta tre tipi di server dei nomi alternativi e offre metodi di routing standard o privati per la connettività.

Tipo di server dei nomi alternativo Il routing standard supporta Il routing privato supporta Intervallo di indirizzi di origine della query

Server dei nomi Type 1

Un indirizzo IP interno di una VM Google Cloud nella stessa rete VPC in cui è definito il criterio del server in uscita.

Solo indirizzi IP RFC 1918: traffico sempre instradato attraverso una rete VPC autorizzata. Qualsiasi indirizzo IP interno, ad esempio un indirizzo privato RFC 1918, un indirizzo IP privato non RFC 1918 o un indirizzo IP pubblico riutilizzato privatamente, ad eccezione di un indirizzo IP alternativo del server dei nomi vietato: il traffico viene sempre instradato attraverso una rete VPC autorizzata. 35.199.192.0/19

Server dei nomi Type 2

Un indirizzo IP di un sistema on-premise, connesso alla rete VPC con il criterio del server in uscita, utilizzando Cloud VPN o Cloud Interconnect.

Solo indirizzi IP RFC 1918: traffico sempre instradato attraverso una rete VPC autorizzata. Qualsiasi indirizzo IP interno, ad esempio un indirizzo privato RFC 1918, un indirizzo IP privato non RFC 1918 o un indirizzo IP pubblico riutilizzato privatamente, ad eccezione di un indirizzo IP del server dei nomi alternativo vietato: il traffico viene sempre instradato attraverso una rete VPC autorizzata. 35.199.192.0/19

Server dei nomi Type 3

Un indirizzo IP esterno di un server dei nomi DNS accessibile a internet o l'indirizzo IP esterno di una risorsa Google Cloud, ad esempio l'indirizzo IP esterno di una VM in un'altra rete VPC.

Solo indirizzi IP esterni con routing a internet; traffico sempre instradato verso internet o verso l'indirizzo IP esterno di una risorsa Google Cloud. Il routing privato non è supportato. Intervalli di origine DNS pubblico di Google

Cloud DNS offre due metodi di routing per eseguire query su server dei nomi alternativi:

  • Routing standard: Cloud DNS determina il tipo di server dei nomi alternativo utilizzando il relativo indirizzo IP, quindi utilizza il routing privato o pubblico:

    • Se il server dei nomi alternativo è un indirizzo IP RFC 1918, Cloud DNS classifica il server dei nomi come server dei nomi di Tipo 1 o Tipo 2 e instrada le query attraverso una rete VPC autorizzata (routing privato).

    • Se il server dei nomi alternativo non è un indirizzo IP RFC 1918, Cloud DNS classifica il server dei nomi come Type 3 e si aspetta che il server dei nomi alternativo sia accessibile da internet. Cloud DNS instrada le query su internet (routing pubblico).

  • Routing privato: Cloud DNS considera il server dei nomi alternativo come Tipo 1 o Tipo 2. Cloud DNS instrada sempre il traffico attraverso una rete VPC autorizzata, indipendentemente dall'indirizzo IP del server dei nomi alternativo (RFC 1918 o meno).

Indirizzi IP del server dei nomi alternativi vietati

Non puoi utilizzare i seguenti indirizzi IP per i server dei nomi alternativi di Cloud DNS:

  • 169.254.0.0/16
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/4
  • 240.0.0.0/4
  • ::1/128
  • ::/128
  • 2001:db8::/32
  • fe80::/10
  • fec0::/10
  • ff00::/8

Requisiti di rete dei server dei nomi alternativi

I requisiti di rete per i server dei nomi alternativi variano in base al tipo di server dei nomi alternativo. Per determinare il tipo di server dei nomi alternativo, vedi Tipi di server dei nomi, metodi di routing e indirizzi alternativi. Quindi, fai riferimento a una delle seguenti sezioni per i requisiti di rete.

Requisiti di rete per i server dei nomi alternativi di Tipo 1

Cloud DNS invia i pacchetti le cui origini provengono dall'intervallo di indirizzi IP 35.199.192.0/19 all'indirizzo IP del server dei nomi alternativo di Tipo 1. Google Cloud instrada i pacchetti per le query utilizzando route di subnet locali nella rete VPC. Assicurati di non aver creato route basate su criteri le cui destinazioni includono indirizzi IP del server dei nomi alternativi di tipo 1.

Per consentire i pacchetti in entrata su VM alternative del server dei nomi, devi creare regole firewall VPC di autorizzazione in entrata o regole nei criteri firewall con le seguenti caratteristiche:

  • Destinazioni: devono includere le VM alternative del server dei nomi
  • Fonti: 35.199.192.0/19
  • Protocolli: TCP e UDP
  • Porta: 53

Cloud DNS richiede che ogni server dei nomi alternativo invii pacchetti di risposte all'indirizzo IP di Cloud DNS in 35.199.192.0/19 da cui ha avuto origine la query. L'origine dei pacchetti di risposta deve corrispondere all'indirizzo IP del server dei nomi alternativo a cui Cloud DNS invia la query originale. Cloud DNS ignora le risposte se provengono da un'origine di indirizzo IP imprevista, ad esempio l'indirizzo IP di un altro server dei nomi a cui un server dei nomi alternativo potrebbe inoltrare una query.

Quando un server dei nomi alternativo di Tipo 1 invia pacchetti di risposta a 35.199.192.0/19, utilizza un percorso di routing speciale.

Requisiti di rete per i server dei nomi alternativi di Tipo 2

Cloud DNS invia i pacchetti le cui origini provengono dall'intervallo di indirizzi IP 35.199.192.0/19 ai server dei nomi alternativi di Tipo 2. Cloud DNS utilizza i seguenti tipi di route all'interno della rete VPC a cui si applica il criterio del server in uscita:

Per consentire i pacchetti in entrata sui server dei nomi alternativi di Tipo 2, assicurati di configurare le regole firewall di autorizzazione in entrata applicabili ai server dei nomi alternativi e a qualsiasi apparecchiatura di rete on-premise pertinente con funzionalità firewall. La configurazione efficace del firewall deve consentire sia i protocolli TCP che UDP con origini 53 e 35.199.192.0/19 della porta di destinazione.

Cloud DNS richiede che ogni server dei nomi alternativo invii pacchetti di risposte all'indirizzo IP di Cloud DNS in 35.199.192.0/19 da cui ha avuto origine la query. L'origine dei pacchetti di risposta deve corrispondere all'indirizzo IP del server dei nomi alternativo a cui Cloud DNS invia la query originale. Cloud DNS ignora le risposte se provengono da un'origine di indirizzo IP imprevista, ad esempio l'indirizzo IP di un altro server dei nomi a cui un server dei nomi alternativo potrebbe inoltrare una query.

La rete on-premise deve avere route per la destinazione 35.199.192.0/19 i cui hop successivi sono tunnel Cloud VPN, collegamenti VLAN di Cloud Interconnect o router Cloud situati nella stessa rete VPC e nella stessa regione da cui Cloud DNS invia la query. Se gli hop successivi soddisfano questi requisiti di rete e regione, Google Cloud non richiede un percorso di ritorno simmetrico. Le risposte dai server dei nomi alternativi di tipo 2 non possono essere instradate utilizzando uno dei seguenti hop successivi:

  • Passaggi successivi su internet
  • Hop successivi in una rete VPC diversa dalla rete VPC da cui hanno avuto origine
  • Hop successivo nella stessa rete VPC ma in una regione diversa da quella da cui hanno avuto origine le query

Per configurare le route 35.199.192.0/19 nella rete on-premise, utilizza la modalità pubblicità personalizzata del router Cloud e includi 35.199.192.0/19 come prefisso personalizzato nelle sessioni BGP dei tunnel Cloud VPN pertinenti, degli allegati VLAN di Cloud Interconnect o dei router Cloud che connettono la rete VPC alla rete on-premise che contiene il server dei nomi alternativo di Tipo 2. In alternativa, puoi configurare route statiche equivalenti nella tua rete on-premise.

Requisiti di rete per i server dei nomi alternativi di Tipo 3

Cloud DNS invia i pacchetti le cui origini corrispondono agli intervalli di origine di Google Public DNS ai server dei nomi alternativi di Tipo 3. Cloud DNS utilizza il routing pubblico non si basa su nessuna route all'interno della rete VPC a cui si applica il criterio del server in uscita.

Per consentire i pacchetti in arrivo sui server dei nomi alternativi di tipo Type 3, assicurati che la configurazione del firewall effettiva applicabile al server dei nomi alternativo consenta i pacchetti dagli intervalli di origine del DNS pubblico di Google.