Gestisci i criteri di routing DNS e i controlli di integrità

I criteri di routing DNS indirizzano il traffico in base al tipo di query (ad esempio, round robin ponderato o geolocalizzazione). Puoi configurare questi criteri creando set di record di risorse che contengono valori specifici dei criteri di routing. Questi valori determinano il modo in cui viene instradato il traffico. Ad esempio, in un criterio round robin ponderato, ogni set di record di risorse ha una ponderazione assegnata che influisce sulla distribuzione del traffico.

Questa pagina fornisce informazioni su come creare, modificare ed eliminare i criteri di routing DNS e su come abilitare i controlli di integrità utilizzando Cloud DNS. Prima di utilizzare questa pagina, consulta la panoramica dei criteri DNS.

Per utilizzare i criteri di routing DNS, crea un set di record di risorse e scegli uno dei seguenti criteri di routing DNS da applicare al set di record di risorse:

  • Criterio di routing WRR (Round robin ponderato): utilizza WRR per specificare ponderazioni diverse per set di record di risorse per il nome DNS. I criteri di routing DNS assicurano che il traffico venga distribuito in base alle ponderazioni configurate. La combinazione di un criterio di routing WRR con un criterio di routing di geolocalizzazione non è supportata.

  • Criterio di routing della geolocalizzazione (GEO): utilizza l'opzione GEO per specificare le geolocalizzazioni di origine e per fornire risposte corrispondenti a queste aree geografiche. Il criterio per i percorsi di geolocalizzazione applica una corrispondenza più vicina per la località di origine quando la sorgente del traffico non corrisponde esattamente a nessun elemento della norma.

    Il campo geografico mappa l'origine per i DNS pubblici e privati nei seguenti modi:

    • Per il DNS pubblico: viene utilizzato l'indirizzo IP di origine o la subnet client del meccanismo di estensione per DNS (EDNS) della query.
    • Per il DNS privato, la subnet client EDNS non viene utilizzata. La posizione della query è invece quella del sistema che invia i pacchetti per la query:
      • Per le query da un'istanza di macchina virtuale (VM) con un'interfaccia di rete in una rete VPC, la località della query è la regione che contiene la VM.
      • Per le query ricevute da un punto di ingresso dei criteri del server in entrata, la località della query corrisponde alla regione del tunnel Cloud VPN, del collegamento VLAN di Cloud Interconnect o dell'appliance router che ha ricevuto i pacchetti per la query. La regione dell'indirizzo IP del punto di ingresso non è pertinente. Per ulteriori informazioni, consulta Rete e regione per le query in entrata nella pagina "Criteri del server DNS".
  • Criterio di routing geografico: usa il geofencing per limitare il traffico a una specifica geolocalizzazione, anche se tutti gli endpoint in quella geolocalizzazione non sono integri. Per informazioni dettagliate sul geofencing, consulta i Criteri di routing tramite recinto virtuale.

  • Criterio di routing del failover: utilizza il failover per impostare configurazioni di backup attive. Per maggiori dettagli, consulta Criteri di routing del failover.

I criteri di routing DNS supportano inoltre più indirizzi IP per ogni posizione geografica. Se specificato per una determinata posizione geografica, vengono restituiti più indirizzi IP in base a un criterio WRR di uguale peso. La combinazione di un criterio di routing basato su dati geografici con un criterio WRR ponderato in modo personalizzato non è supportata.

Controlli di integrità

Cloud DNS supporta i controlli di integrità per bilanciatori del carico di rete passthrough interni, Application Load Balancer interni con accesso globale abilitato e bilanciatori del carico delle applicazioni interni tra regioni.

Dopo aver configurato un bilanciatore del carico di rete passthrough interno, configura il criterio di routing appropriato in Cloud DNS utilizzando la console Google Cloud, gcloud CLI o l'API, specificando il bilanciatore del carico di rete passthrough interno. Questo passaggio prevede la configurazione di più bucket WRR o GEO e ogni bucket può contenere più bilanciatori del carico di rete passthrough interni.

Per i bilanciatori del carico di rete passthrough interni, Cloud DNS controlla le informazioni di integrità sulle singole istanze di backend del bilanciatore del carico per determinare se il bilanciatore del carico è integro o non integro. Cloud DNS applica una soglia predefinita del 20% e, se almeno il 20% delle istanze di backend è in stato integro, l'endpoint del bilanciatore del carico viene considerato integro. I criteri di routing DNS contrassegnano l'endpoint come integro o non integro in base a questa soglia, instradando il traffico di conseguenza.

Per gli Application Load Balancer interni e gli Application Load Balancer interni tra regioni, Cloud DNS controlla l'integrità complessiva dell'Application Load Balancer interno e consente allo stesso bilanciatore del carico delle applicazioni interno di verificare l'integrità delle istanze di backend.

Quando l'endpoint è contrassegnato come non integro, possono verificarsi le seguenti condizioni:

  • Se sono presenti più indirizzi VIP programmati sulla base di un criterio, vengono restituiti solo gli indirizzi VIP integri.
  • Se tutti gli indirizzi VIP programmati in un bucket di criteri non sono integri, la riga del criterio ha esito negativo. Si applica il seguente comportamento:

    • Per un criterio WRR, Cloud DNS distribuisce il traffico al successivo bucket di ponderazione integro.
    • Per un criterio GEO in cui non è attivata la recinzione, il traffico passa all'area geografica immediatamente più vicina.
    • Per un criterio con recinti virtuali in cui è abilitata la recinzione, gli indirizzi VIP nel bucket geografico più vicino vengono restituiti così come sono.
    • Per un criterio di failover, Cloud DNS trasferisce il traffico al bucket di failover.
    • Se tutti i bucket dei criteri non sono integri, Cloud DNS si comporta come se tutti gli endpoint fossero integri.

Prima di iniziare

Questa procedura presuppone che tu abbia completato quanto segue:

  1. Hai creato una zona gestita e hai completato i prerequisiti per la creazione di una zona.
  2. Configura uno dei seguenti bilanciatori del carico interni:
  3. Regole di forwarding create per il bilanciatore del carico interno.
  4. Configura il controllo di integrità per il bilanciatore del carico interno.

Crea criteri di routing DNS

Per creare un set di record di risorse e applicarvi un criterio di routing, segui questi passaggi.

Console

Avvia la configurazione

  1. Nella console Google Cloud, vai alla pagina Zone Cloud DNS.

    Vai a Zone Cloud DNS

  2. Fai clic sul nome della zona gestita a cui vuoi aggiungere il record.

  3. Nella pagina Dettagli zona, fai clic su Aggiungi con criterio di routing.

Dati di base

  1. Nella pagina Crea set di record con criterio di routing, nel campo Nome DNS, inserisci il sottodominio della zona DNS, ad esempio mail. Il punto finale viene aggiunto automaticamente alla fine.

  2. Seleziona il Tipo di record di risorse, ad esempio A.

  3. Nel campo TTL, inserisci un valore numerico per la durata del record di risorse, ovvero la quantità di tempo per cui può essere memorizzato nella cache. Questo valore deve essere un numero intero positivo.

  4. Nel menu Unità TTL, seleziona l'unità di tempo, ad esempio 30 minutes.

  5. Tocca Avanti.

Tipo di criterio di routing

  1. Nell'elenco Criterio di routing, seleziona Round robin ponderato, Geolocalizzazione o Failover.
  2. Tocca Avanti.

Dati dei criteri di routing

  1. Se hai selezionato Round robin ponderato, nella sezione Dati di routing per criteri round robin ponderati, segui questi passaggi:

    1. Nel campo Peso, inserisci la ponderazione corrispondente a questa sottosezione dei dati del record di risorse (RR). Questa ponderazione deve essere un numero non negativo compreso tra 0,0 e 1000,0. Il rapporto del traffico instradato al target viene calcolato in base al rapporto tra la ponderazione individuale e il totale di tutte le ponderazioni.
    2. Nella sezione Aggiungi target con controllo di integrità, procedi nel seguente modo:

      1. Nell'elenco Progetto, seleziona il progetto in cui è presente la regola di forwarding.
      2. Nell'elenco Tipo, seleziona Bilanciatore del carico di rete passthrough interno, Bilanciatore del carico delle applicazioni interno o Application Load Balancer interno tra regioni.
      3. Nell'elenco Regola di forwarding, seleziona una regola di forwarding.

        La regola di forwarding specifica un indirizzo IP interno, una porta e un servizio di backend regionale o un proxy HTTP(S). Affinché Cloud DNS funzioni con i controlli di integrità, devi abilitare l'accesso globale per il bilanciatore del carico interno.

    3. Per consentire gli indirizzi IPv4 senza controllo di integrità, seleziona Consenti indirizzi IPv4 senza controllo di integrità.

    4. Nel campo Indirizzo IPv4, inserisci un indirizzo IPv4.

  2. Se hai selezionato Geolocalizzazione:

    1. Per Geofencing, seleziona Disattivato o Attivato. L'abilitazione del geofencing limita il traffico a una geolocalizzazione specifica, anche se tutti gli endpoint in quella geolocalizzazione non sono integri.
    2. Nel menu Regione di origine, seleziona una regione di origine di Google Cloud valida, ad esempio asia-east1.
    3. Nella sezione Aggiungi target con controllo di integrità, procedi nel seguente modo:

      1. Nell'elenco Progetto, seleziona il progetto in cui è presente la regola di forwarding.
      2. Nell'elenco Tipo, seleziona Bilanciatore del carico di rete passthrough interno, Bilanciatore del carico delle applicazioni interno o Application Load Balancer interno tra regioni.
      3. Nell'elenco Regola di forwarding, seleziona una regola di forwarding.

        La regola di forwarding specifica un indirizzo IP interno, una porta e un servizio di backend regionale o un proxy HTTP(S). Affinché Cloud DNS funzioni con i controlli di integrità, devi abilitare l'accesso globale per il bilanciatore del carico interno.

    4. Per consentire gli indirizzi IPv4 senza controllo di integrità, seleziona Consenti indirizzi IPv4 senza controllo di integrità.

    5. Nel campo Indirizzo IPv4, inserisci un indirizzo IPv4.

  3. Se hai selezionato Failover:

    1. Nel campo Traffico ridotto (%), inserisci la percentuale di traffico inviata alle destinazioni di failover, indipendentemente dallo stato del controllo di integrità dei target principali.
    2. Nella sezione Target principali, procedi nel seguente modo:

      1. Nell'elenco Progetto, seleziona il progetto in cui è presente la regola di forwarding.
      2. Nell'elenco Tipo, seleziona Bilanciatore del carico di rete passthrough interno, Bilanciatore del carico delle applicazioni interno o Application Load Balancer interno tra regioni.
      3. Nell'elenco Regola di forwarding, seleziona una regola di forwarding.

        La regola di forwarding specifica un indirizzo IP interno, una porta e un servizio di backend regionale o un proxy HTTP(S). Affinché Cloud DNS funzioni con i controlli di integrità, devi abilitare l'accesso globale per il bilanciatore del carico interno.

    3. Nella sezione Criterio di geolocalizzazione per il backup, procedi nel seguente modo:

      1. Per Geofencing, seleziona Disattivato o Attivato. L'abilitazione del geofencing limita il traffico a una geolocalizzazione specifica, anche se tutti gli endpoint in quella geolocalizzazione non sono integri.
      2. Nel menu Regione di origine, seleziona una regione di origine di Google Cloud valida, ad esempio asia-east1.
      3. Nella sezione Aggiungi target con controllo di integrità, procedi nel seguente modo:

        1. Nell'elenco Progetto, seleziona il progetto in cui è presente la regola di forwarding.
        2. Nell'elenco Tipo, seleziona Bilanciatore del carico di rete passthrough interno, Bilanciatore del carico delle applicazioni interno o Application Load Balancer interno tra regioni.
        3. Nell'elenco Regola di forwarding, seleziona una regola di forwarding.

        Quando tutti gli indirizzi IP principali non sono integri, il traffico viene gestito automaticamente in base al criterio di geolocalizzazione di backup.

    4. Per consentire gli indirizzi IPv4 senza controllo di integrità, seleziona Consenti indirizzi IPv4 senza controllo di integrità.

    5. Nel campo Indirizzo IPv4, inserisci un indirizzo IPv4.

  4. Tocca Avanti.

Rivedi e crea

  1. Fai clic su Esamina.
  2. Esamina il set di record Cloud DNS con la configurazione dei criteri di routing.
  3. (Facoltativo) Fai clic su Riga di commento equivalente per visualizzare il comando gcloud CLI per creare questo set di record con il criterio di routing.
  4. Fai clic su Crea.

gcloud

Un elemento ResourceRecordSet può contenere routingPolicy o rrdatas, ma non entrambi. Il passaggio da rrdatas a routingPolicy è supportato durante l'aggiornamento di ResourceRecordSets. Ad esempio, se vuoi aggiornare un elemento ResourceRecordSet contenente rrdatas, puoi eliminare rrdatas e aggiungere un routingPolicy allo stesso ResourceRecordSet.

Per creare un ResourceRecordSet e applicarvi un criterio di routing, segui questi passaggi.

Esegui il comando gcloud dns record-sets create.

Per i criteri relativi all'area geografica

gcloud dns record-sets create RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=GEO \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-health-checking

Per le norme relative a WRR

gcloud dns record-sets create RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=WRR \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-health-checking

Per i criteri sottoposti a recinto virtuale

gcloud dns record-sets create RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=GEO \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-geo-fencing
    --enable-health-checking

Per i criteri di failover

gcloud dns record-sets create RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=FAILOVER \
    --enable-geo-fencing \
    --routing-policy-primary-data=ROUTING_POLICY_PRIMARY_DATA \
    --routing-policy-backup-data-type=ROUTING_POLICY_BACKUP_DATA_TYPE \
    --routing-policy-backup-data=ROUTING_POLICY_BACKUP_DATA \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO \
    --enable-health-checking

Sostituisci quanto segue:

  • RRSET_NAME: il nome DNS che corrisponde alle query in entrata con il nome DNS di questa zona come suffisso, ad esempio service.example.com
  • TTL: il TTL in secondi in cui il resolver memorizza nella cache questo ResourceRecordSet, ad esempio 30
  • RRSET_TYPE: il tipo di record di risorse di questo ResourceRecordSet, ad esempio A

    Per un elenco dei tipi di record supportati, consulta Selezionare i tipi di record di risorse.

  • MANAGED_ZONE: la zona gestita a cui è affiliato ResourceRecordSet, ad esempio service-zone. Il nome di questo ResourceRecordSet deve avere come suffisso il nome DNS della zona gestita

  • ROUTING_POLICY_TYPE: il tipo di criterio di routing

    Inserisci WRR per il round robin ponderato, GEO per la geolocalizzazione o FAILOVER per i criteri di failover. Non puoi modificare questo campo dopo che un criterio è stato scelto; puoi solo eliminare il criterio e aggiungerne uno nuovo di tipo diverso.

  • ROUTING_POLICY_DATA: i dati del criterio di routing

    • Per --routing-policy-type=WRR, inserisci un elenco delimitato da punti e virgola nel formato ${weight_percent}:${rrdatas}, ad esempio .8=203.0.113.1;.2=198.51.100.1. Specifica la ponderazione come un numero decimale non negativo. Il rapporto del traffico instradato al target viene calcolato in base al rapporto tra la ponderazione individuale e il totale di tutte le ponderazioni. I nomi delle regole di forwarding sono valori accettabili e comportano il controllo di integrità.
    • Per --routing-policy-type=GEO, inserisci un elenco delimitato da punti e virgola nel formato ${region}=${IP_address}, ad esempio asia-east1=198.51.100.1;us-central1=203.0.113.1. Puoi specificare più indirizzi IP per una singola regione aggiungendo indirizzi IP separati da una virgola. I nomi delle regole di forwarding sono valori accettabili e comportano il controllo di integrità.
    • Per --routing-policy-type=FAILOVER, inserisci il nome della regola di forwarding creata nel formato ${region}=${Forwarding rule name}.

    Devi specificare sia il tipo di criterio di routing che i dati del criterio di routing. Se ne specifichi uno, non puoi lasciare vuoto l'altro flag.

  • --enable-geo-fencing: per i criteri di routing GEO, determina se il traffico deve eseguire il failover tra regioni se tutti gli endpoint in un'area geografica non sono integri. Se impostato, Cloud DNS indirizza sempre le query alla regione più vicina, anche se tutti gli endpoint in quella regione non sono integri. Usa --no-enable-geo-fencing per disattivare il geofencing. Se non viene configurato, Cloud DNS indirizza le query alla successiva area geografica più vicina quando tutti gli endpoint in una regione non sono integri. Il valore predefinito è false.

  • ROUTING_POLICY_PRIMARY_DATA: il target principale da utilizzare per i criteri di routing FAILOVER. Questa destinazione deve essere un riferimento a una o più regole di forwarding, come forwarding-rule-1. Finché almeno una di queste regole di forwarding è integro, gli indirizzi IP di tutte le regole di forwarding integri vengono utilizzati per rispondere alle query per questo nome.

  • ROUTING_POLICY_BACKUP_DATA: la destinazione di backup da utilizzare per i criteri di routing FAILOVER. Questi target vengono utilizzati quando tutte le regole di forwarding specificate in --routing-policy-primary-data non sono integri. Cloud DNS supporta solo destinazioni di backup basate su dati geografici. Il formato di questo campo corrisponde a quello di --routing-policy-data quando --routing-policy-type = 'GEO', ad esempio asia-east1=forwarding-rule-2.

  • ROUTING_POLICY_BACKUP_DATA_TYPE: per i criteri di routing FAILOVER, il tipo di criterio di routing utilizzato dai dati di backup. Deve essere GEO.

  • BACKUP_DATA_TRICKLE_RATIO: il rapporto di traffico da inviare alle destinazioni di backup, anche quando le entità primarie sono integri. Il rapporto deve essere compreso tra 0 e 1, ad esempio 0.1. Il valore predefinito è 0.

  • --enable-health-checking: il flag per abilitare il controllo di integrità. Quando utilizzi questo flag, devi fornire il nome della regola di forwarding anziché l'indirizzo IP nel campo --routing-policy-data.

API

Utilizza il metodo resourceRecordSets.create.

Per i criteri relativi all'area geografica

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
            "name": "RRSET_NAME",
            "type": "RRSET_TYPE",
            "ttl": TTL,
            "routingPolicy": {
          "geo": {
              "items": [
              {
                  "location": "LOCATION",
                  "healthCheckedTargets": {
                     "internalLoadBalancers": [
                      {
                       "loadBalancerType": "LOAD_BALANCER_TYPE"
                       "ipAddress": "IP_ADDRESS"
                       "port" : "PORT_NUMBER"
                       "ipProtocol": "IP_PROTOCOL"
                       "networkUrl": "NETWORK_URL"
                       "project": "PROJECT"
                       "region": "REGION"
                      }
                     ]
                  }
              },
              {
                  "location": "LOCATION",
                  "healthCheckedTargets": {
                     "internalLoadBalancers": [
                      {
                       "loadBalancerType": "LOAD_BALANCING_TYPE"
                       "ipAddress": "IP_ADDRESS"
                       "port" : "PORT_NUMBER"
                       "ipProtocol": "IP_PROTOCOL"
                       "networkUrl": "NETWORK_URL"
                       "project": "PROJECT"
                       "region": "REGION"
                      }
                     ]
                  }
              },
              }
           ]

        }
     }
}

Per le norme relative a WRR

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
  "name": "RRSET_NAME",
        "type": "RRSET_TYPE",
        "ttl": TTL,
  "routingPolicy": {
    "wrr": {
      "items": [
        {
          "weight": WEIGHT,
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port" : "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT"
                "region": "REGION"
              }
            ]
          }
        },
        {
          "weight": WEIGHT,
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port" : "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT"
                "region": "REGION"
              }
            ]
          }
        },
      ]
    }
  }
}

Per i criteri di FAILOVER per i dati geografici

Nell'opzione di failover, Cloud DNS supporta solo i criteri GEO.

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
  "name": "RRSET_NAME",
        "type": "RRSET_TYPE",
        "ttl": TTL,
  "routingPolicy": {
    "primaryBackup": {
      "trickleTraffic": TRICKLE_TRAFFIC,
      "primaryTargets": {
        "internalLoadBalancers": [
          {
            "ipAddress": "IP_ADDRESS"
            "ipProtocol": "IP_PROTOCOL"
            "loadBalancerType": "LOAD_BALANCER_TYPE"
            "networkUrl": "NETWORK_URL"
            "port": "PORT_NUMBER"
            "project": "PROJECT"
            "region": "REGION"
           }
         ]
       },
       "backupGeoTargets": {
         "enableFencing": ENABLE_FENCING,
         "items": [
           {
             "location": "LOCATION",
             "rrdatas": [
               "RRDATA"
             ]
           },
           {
             "location": "LOCATION",
             "rrdatas": [
               "RRDATA"
             ]
           }
         ]
       }
     },
   }
}

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto
  • MANAGED_ZONE: la zona gestita a cui è affiliato questo ResourceRecordSet, ad esempio service-zone; il nome di questa ResourceRecordSet deve avere il nome DNS della zona gestita come suffisso
  • RRSET_NAME: il nome DNS che corrisponde alle query in entrata con il nome DNS di questa zona come suffisso, ad esempio service.example.com
  • RRSET_TYPE: il tipo di record di risorse di questo ResourceRecordSet, ad esempio A
  • TTL: il TTL in secondi in cui il resolver memorizza nella cache questo ResourceRecordSet, ad esempio 30
  • TRICKLE_TRAFFIC: il rapporto di traffico da inviare alle destinazioni di backup anche quando le unità principali sono integri; il rapporto deve essere compreso tra 0 e 1, ad esempio 0.1
  • ENABLE_FENCING: per i criteri di routing GEO, determina se il traffico deve eseguire il failover tra regioni se tutti gli endpoint in una regione sono in stato non integro. Se impostato, Cloud DNS indirizza sempre le query alla regione più vicina, anche se tutti gli endpoint in quella regione non sono integri. Se non viene configurato, Cloud DNS indirizza le query alla successiva regione più vicina quando tutti gli endpoint in una regione non sono integri. Il valore predefinito è false.
  • LOCATION: per i criteri GEO, la geolocalizzazione per cui è necessario creare il criterio, ad esempio asia-east1
  • WEIGHT: per i criteri WRR, un elenco delimitato da punto e virgola nel formato ${weight_percent}=${rrdatas}, come .8=10.128.1.1;.2=10.130.1.1; specifica la ponderazione come qualsiasi decimale non negativo
  • RR_DATA: un valore arbitrario associato al set di record di risorse, come 198.51.100.5; puoi anche inserire più valori, rrdata1 rrdata2 rrdata3, ad esempio 198.51.100.1 203.0.113.1...
  • LOAD_BALANCER_TYPE: il tipo di bilanciatore del carico, ad esempio regionalL4ilb
  • IP_ADDRESS: l'indirizzo IP fornito dalla regola di forwarding
  • PORT_NUMBER: il numero della porta
  • IP_PROTOCOL: definisce il protocollo utilizzato per il controllo di integrità; le opzioni valide sono tcp e udp
  • NETWORK_URL: l'URL di rete a cui si applica la regola di forwarding
  • REGION: la regione in cui hai creato la regola di forwarding

Aggiorna i criteri di routing DNS

Per aggiornare il criterio di routing di un set di record di risorse:

Console

  1. Nella console Google Cloud, vai alla pagina Zone Cloud DNS.

    Vai a Zone Cloud DNS

  2. Fai clic sulla zona per la quale vuoi aggiornare il criterio di routing del set di record di risorse.

  3. Nella pagina Dettagli zona, accanto al set di record di risorse che vuoi aggiornare, fai clic su Modifica.

  4. Dopo aver apportato gli aggiornamenti necessari, fai clic su Salva.

gcloud

Esegui il comando gcloud dns record-sets update:

Per i criteri relativi all'area geografica

gcloud dns record-sets update RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=GEO \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-health-checking

Per le norme relative a WRR

gcloud dns record-sets update RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=WRR \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-health-checking

Per i criteri sottoposti a recinto virtuale

gcloud dns record-sets update RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=GEO \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-geo-fencing
    --enable-health-checking

Per i criteri di failover

gcloud dns record-sets update RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=FAILOVER \
    --enable-geo-fencing \
    --routing-policy-primary-data=ROUTING_POLICY_PRIMARY_DATA \
    --routing-policy-backup-data=ROUTING_POLICY_BACKUP_DATA \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO \
    --enable-health-checking

Sostituisci quanto segue:

  • RRSET_NAME: il nome DNS che corrisponde alle query in entrata con il nome DNS di questa zona come suffisso, ad esempio service.example.com
  • TTL: il TTL in secondi in cui il resolver memorizza nella cache questo ResourceRecordSet, ad esempio 30
  • RRSET_TYPE: il tipo di record di risorse di questo ResourceRecordSet, ad esempio A

    Per un elenco dei tipi di record supportati, consulta Selezionare i tipi di record di risorse.

  • MANAGED_ZONE: la zona gestita a cui è affiliato ResourceRecordSet, ad esempio service-zone. Il nome di questo ResourceRecordSet deve avere come suffisso il nome DNS della zona gestita

  • ROUTING_POLICY_TYPE: il tipo di criterio di routing

    Inserisci WRR per il round robin ponderato, GEO per la geolocalizzazione o FAILOVER per i criteri di failover. Non puoi modificare questo campo dopo che un criterio è stato scelto; puoi solo eliminare il criterio e aggiungerne uno nuovo di tipo diverso.

  • ROUTING_POLICY_DATA: i dati del criterio di routing

    • Per --routing-policy-type=WRR, inserisci un elenco delimitato da punti e virgola nel formato ${weight_percent}:${rrdatas}, ad esempio .8=203.0.113.1;.2=198.51.100.1. Specifica la ponderazione come un numero decimale non negativo. Il rapporto del traffico instradato al target viene calcolato in base al rapporto tra la ponderazione individuale e il totale di tutte le ponderazioni. I nomi delle regole di forwarding sono valori accettabili e comportano il controllo di integrità.
    • Per --routing-policy-type=GEO, inserisci un elenco delimitato da punti e virgola nel formato ${region}=${IP_address}, ad esempio asia-east1=198.51.100.1;us-central1=203.0.113.1. Puoi specificare più indirizzi IP per una singola regione aggiungendo indirizzi IP separati da una virgola. I nomi delle regole di forwarding sono valori accettabili e comportano il controllo di integrità.
    • Per --routing-policy-type=FAILOVER, inserisci il nome della regola di forwarding creata nel formato ${region}=${Forwarding rule name}.

    Devi specificare sia il tipo di criterio di routing che i dati del criterio di routing. Se ne specifichi uno, non puoi lasciare vuoto l'altro flag.

  • --enable-geo-fencing: per i criteri di routing GEO, determina se il traffico deve eseguire il failover tra regioni se tutti gli endpoint in un'area geografica non sono integri. Se impostato, Cloud DNS indirizza sempre le query alla regione più vicina, anche se tutti gli endpoint in quella regione non sono integri. Usa --no-enable-geo-fencing per disattivare il geofencing. Se non viene configurato, Cloud DNS indirizza le query alla successiva area geografica più vicina quando tutti gli endpoint in una regione non sono integri. Il valore predefinito è false.

  • ROUTING_POLICY_PRIMARY_DATA: il target principale da utilizzare per i criteri di routing FAILOVER. Questa destinazione deve essere un riferimento a una o più regole di forwarding, come forwarding-rule-1. Finché almeno una di queste regole di forwarding è integro, gli indirizzi IP di tutte le regole di forwarding integri vengono utilizzati per rispondere alle query per questo nome.

  • ROUTING_POLICY_BACKUP_DATA: la destinazione di backup da utilizzare per i criteri di routing FAILOVER. Questi target vengono utilizzati quando tutte le regole di forwarding specificate in --routing-policy-primary-data non sono integri. Cloud DNS supporta solo destinazioni di backup basate su dati geografici. Il formato di questo campo corrisponde a quello di --routing-policy-data quando --routing-policy-type = 'GEO', ad esempio asia-east1=forwarding-rule-2.

  • BACKUP_DATA_TRICKLE_RATIO: il rapporto di traffico da inviare alle destinazioni di backup anche quando le entità primarie sono integri. Il rapporto deve essere compreso tra 0 e 1, ad esempio 0.1. Il valore predefinito è 0.

  • --enable-health-checking: attiva il controllo di integrità delle regole di forwarding fornite come rrdata a --routing-policy-data.

API

Utilizza il metodo resourceRecordSets.patch. Specifica solo un valore tra rrset.rrdatas o rrset.routingPolicy. Se specifichi routingPolicy, devi specificare il nuovo campo routingPolicy completamente.

Per i criteri GEO, utilizza il seguente metodo:

PATCH https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
            "name": "RRSET_NAME",
            "type": "RRSET_TYPE",
            "ttl": TTL,
            "routingPolicy": {
          "geo": {
              "items": [
              {
                  "location": "LOCATION",
                  "healthCheckedTargets": {
                     "internalLoadBalancers": [
                      {
                       "loadBalancerType": "LOAD_BALANCER_TYPE"
                       "ipAddress": "IP_ADDRESS"
                       "port" : "PORT_NUMBER"
                       "ipProtocol": "IP_PROTOCOL"
                       "networkUrl": "NETWORK_URL"
                       "project": "PROJECT"
                       "region": "REGION"
                      }
                     ]
                  }
              },
              {
                  "location": "LOCATION",
                  "healthCheckedTargets": {
                     "internalLoadBalancers": [
                      {
                       "loadBalancerType": "LOAD_BALANCING_TYPE"
                       "ipAddress": "IP_ADDRESS"
                       "port" : "PORT_NUMBER"
                       "ipProtocol": "IP_PROTOCOL"
                       "networkUrl": "NETWORK_URL"
                       "project": "PROJECT"
                       "region": "REGION"
                      }
                     ]
                  }
              },
              }
           ]

        }
     }
}

Per i criteri WRR, utilizza il seguente metodo:

PATCH https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
        "name": "RRSET_NAME.",
        "type": "RRSET_TYPE",
        "ttl": TTL,
        "routingPolicy": {
          "wrrPolicy": {
              "item": [
                    {
                        "weight": WEIGHT,
                        "rrdatas": ["RR_DATA"]
                    },
                    {
                        "weight": WEIGHT,
                        "rrdatas": ["RR_DATA"]
                     }
               ],
            }
      }
}

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto
  • MANAGED_ZONE: la zona gestita a cui è affiliato questo ResourceRecordSet, ad esempio service-zone; il nome di questa ResourceRecordSet deve avere il nome DNS della zona gestita come suffisso
  • RRSET_NAME: il nome DNS che corrisponde alle query in entrata con il nome DNS di questa zona come suffisso, ad esempio service.example.com
  • RRSET_TYPE: il tipo di record di risorse di questo ResourceRecordSet, ad esempio A
  • TTL: il TTL in secondi in cui il resolver memorizza nella cache questo ResourceRecordSet, ad esempio 30
  • TRICKLE_TRAFFIC: il rapporto di traffico da inviare alle destinazioni di backup anche quando le unità principali sono integri; il rapporto deve essere compreso tra 0 e 1, ad esempio 0.1
  • ENABLE_FENCING: per i criteri di routing GEO, determina se il traffico deve eseguire il failover tra regioni se tutti gli endpoint in una regione sono in stato non integro. Se impostato, Cloud DNS indirizza sempre le query alla regione più vicina, anche se tutti gli endpoint in quella regione non sono integri. Se non viene configurato, Cloud DNS indirizza le query alla successiva regione più vicina quando tutti gli endpoint in una regione non sono integri. Il valore predefinito è false.
  • LOCATION: per i criteri GEO, la geolocalizzazione per cui è necessario aggiornare il criterio, ad esempio asia-east1
  • WEIGHT: per i criteri WRR, un elenco delimitato da punto e virgola nel formato ${weight_percent}=${rrdatas}, come .8=10.128.1.1;.2=10.130.1.1; specifica la ponderazione come qualsiasi decimale non negativo
  • RR_DATA: un valore arbitrario associato al set di record di risorse, come 198.51.100.5; puoi anche inserire più valori, rrdata1 rrdata2 rrdata3, ad esempio 198.51.100.1 203.0.113.1...
  • LOAD_BALANCER_TYPE: il tipo di bilanciatore del carico, ad esempio regionalL4ilb
  • IP_ADDRESS: l'indirizzo IP fornito dalla regola di forwarding
  • PORT_NUMBER: il numero della porta
  • IP_PROTOCOL: definisce il protocollo utilizzato per il controllo di integrità; le opzioni valide sono tcp e udp
  • NETWORK_URL: l'URL di rete a cui si applica la regola di forwarding
  • REGION: la regione in cui hai creato la regola di forwarding

Elimina i criteri di routing DNS

Per eliminare un criterio di routing, devi eliminare il set di record di risorse che contiene il criterio di routing. Per farlo, segui questi passaggi.

Console

  1. Nella console Google Cloud, vai alla pagina Zone Cloud DNS.

    Vai a Zone Cloud DNS

  2. Fai clic sulla zona per la quale vuoi eliminare il set di record di risorse.

  3. Nella pagina Dettagli zona, seleziona la casella di controllo accanto al nome DNS del set di record di risorse che vuoi eliminare.

  4. Fai clic su Elimina set di record.

gcloud

Esegui il comando gcloud dns record-sets delete:

gcloud dns record-sets delete RRSET_NAME \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \

Sostituisci quanto segue:

  • RRSET_NAME: il nome DNS che corrisponde alle query in entrata con il nome DNS di questa zona come suffisso, ad esempio service.example.com
  • RRSET_TYPE: il tipo di record di risorse di questo ResourceRecordSet, ad esempio A

    Per un elenco dei tipi di record supportati, consulta Selezionare i tipi di record di risorse.

  • MANAGED_ZONE: la zona gestita a cui è affiliato questo ResourceRecordSet, ad esempio service-zone; il nome di questa ResourceRecordSet deve avere il nome DNS della zona gestita come suffisso

API

Utilizza il metodo resourceRecordSets.delete:

DELETE https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets/RRSET_NAME/RRSET_TYPE

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto
  • MANAGED_ZONE: la zona gestita a cui è affiliato questo ResourceRecordSet, ad esempio my-zone-name; il nome di questa ResourceRecordSet deve avere il nome DNS della zona gestita come suffisso
  • RRSET_NAME: il nome DNS che corrisponde alle query in entrata con il nome DNS di questa zona come suffisso, ad esempio test.example.com
  • RRSET_TYPE: il tipo di record di risorse di questo ResourceRecordSet, ad esempio A

Passaggi successivi