Cloud DNS supporta diversi tipi di criteri. In questa pagina vengono fornite informazioni dettagliate sui diversi tipi di criteri e su quando puoi utilizzare l'uno o l'altro.
- I criteri del server applicano la configurazione del DNS privato a una rete VPC (Virtual Private Cloud) (inoltro DNS, logging).
- I criteri di risposta sostituiscono le risposte DNS private in base al nome della query.
- I criteri di routing gestiscono il traffico in base a una query (ad esempio round robin, geolocalizzazione).
Puoi utilizzare tutti e tre i criteri contemporaneamente, a seconda delle esigenze.
Criteri del server
Utilizza i criteri del server per configurare deployment ibridi per risoluzioni DNS. Puoi configurare un criterio del server in entrata a seconda della direzione delle risoluzioni DNS. Se i tuoi carichi di lavoro prevedono di utilizzare un resolver DNS on-premise, puoi configurare zone di forwarding DNS utilizzando un criterio del server in uscita. D'altra parte, se vuoi che i carichi di lavoro on-premise risolvano i nomi su Google Cloud, puoi configurare un criterio del server in entrata.
Per informazioni dettagliate sui criteri dei server, consulta la panoramica sui criteri server.
Per configurare e applicare i criteri del server DNS, vedi Applicare i criteri del server DNS.
Criteri di risposta
Un criterio di risposta è un concetto di zona privata di Cloud DNS che contiene regole anziché record. Queste regole possono essere utilizzate per ottenere effetti simili al concetto di bozza di zona dei criteri di risposta (RPZ) DNS (IETF). La funzionalità dei criteri di risposta consente di introdurre regole personalizzate nei server DNS all'interno della rete che il resolver DNS consulta durante le ricerche. Se una regola nel criterio di risposta influisce sulla query in entrata, questa viene elaborata. In caso contrario, la ricerca procede normalmente. Per ulteriori informazioni, consulta Gestire i criteri di risposta e le regole.
Un criterio di risposta è diverso da un RPZ, che è una zona DNS normale con dati formattati in modo speciale che fa sì che i resolver compatibili eseguano operazioni speciali. I criteri di risposta non sono zone DNS e vengono gestiti separatamente nell'API. Per creare e modificare i criteri di risposta in Cloud DNS, utilizza l'API ResponsePolicies. I criteri di risposta sono
separati da ManagedZones e non possono essere gestiti utilizzando
l'API ManagedZones o l'API
RRSet.
Criteri di routing
I criteri di routing DNS ti consentono di indirizzare il traffico in base a criteri specifici. Cloud DNS supporta anche il controllo di integrità e i failover automatici incorporati in ogni criterio di routing. Il controllo di integrità è disponibile per gli Application Load Balancer e gli Application Load Balancer interni con accesso globale abilitato, nonché per gli Application Load Balancer interni tra regioni.
Cloud DNS supporta i seguenti criteri di routing:
- Criterio di routing round robin ponderato
- Criterio di routing per geolocalizzazione
- Criterio di routing per recinto virtuale
- Criterio di routing per il failover
A un set di record di risorse può essere applicato un solo tipo di criterio di routing alla volta. Non puoi combinare criteri di routing se non durante la configurazione di un criterio di routing di failover, in cui puoi impostare un criterio di routing di geolocalizzazione come backup.
Criteri di routing round robin ponderati
Un criterio di routing round robin ponderato (WRR) consente di specificare ponderazioni diverse per ogni target DNS e Cloud DNS garantisce che il traffico venga distribuito in base alle ponderazioni. Puoi utilizzare questo criterio per supportare le configurazioni manuali active-active o active-passive. Puoi anche suddividere il traffico tra le versioni di produzione
e sperimentali del software.
Il controllo di integrità è disponibile per impostazione predefinita se i target sono bilanciatori del carico di rete passthrough interni. Ciò consente il failover automatico quando gli endpoint non superano i controlli di integrità. In caso di failover, la suddivisione del traffico viene regolata automaticamente tra gli endpoint integri rimanenti. Per maggiori dettagli, consulta Controlli di integrità.
Criteri di routing per geolocalizzazione
Un criterio di routing per la geolocalizzazione consente di mappare il traffico proveniente da aree geografiche di origine (regioni di Google Cloud) a target DNS specifici. Utilizza questo criterio per distribuire le richieste in entrata a diverse istanze di servizio in base all'origine del traffico. Puoi utilizzare questa funzionalità con internet, con traffico esterno o con traffico proveniente da Google Cloud e associato a bilanciatori del carico di rete passthrough interni. Cloud DNS utilizza la regione in cui le query entrano in Google Cloud come area geografica di origine.
Il controllo di integrità è disponibile per impostazione predefinita se il target è un bilanciatore del carico di rete passthrough interno, un Application Load Balancer interno o un Application Load Balancer interno tra regioni. Ciò consente il failover automatico quando gli endpoint non superano i controlli di integrità. Nel caso della geolocalizzazione, il traffico viene trasferito alla successiva geolocalizzazione più vicina al traffico di origine.
Criteri di routing per recinto virtuale
Il controllo di integrità attiva il tipo di criterio di routing con recinto virtuale in cui è possibile limitare il traffico a una geolocalizzazione specifica, anche se tutti gli endpoint in quella località non sono integri. In un criterio di geolocalizzazione, quando vengono rilevati errori nel controllo di integrità per un bucket geografico specifico, il traffico ha esito negativo automaticamente per la successiva geolocalizzazione più vicina. Quando è abilitato il geofencing, il failover automatico non avviene. In qualità di server autorevole, Cloud DNS deve restituire un valore e, in questo scenario, Cloud DNS restituisce tutti gli indirizzi IP inalterati se non superano i controlli di integrità.
Criteri di routing per il failover
Il criterio di routing di failover consente di impostare configurazioni di backup attive.
Durante il normale funzionamento, vengono sempre restituiti gli indirizzi IP di cui è stato eseguito il provisioning nel set active. Quando tutti gli indirizzi IP nel set attivo non vanno a buon fine (lo stato di integrità diventa non integro), Cloud DNS inizia a gestire gli indirizzi IP nel set di backup. Puoi configurare il set di backup come criteri di geolocalizzazione in modo che funzionino come descritto nella sezione dei criteri di geolocalizzazione. Se configurati come bilanciatore del carico di rete passthrough interno, Application Load Balancer interno o Application Load Balancer interno tra regioni, vengono sottoposti a controllo di integrità anche tutti gli indirizzi IP virtuali (VIP) di backup.
Inoltre, Cloud DNS supporta il traffico inclinato verso gli indirizzi VIP di backup in modo che tu possa assicurarti che gli indirizzi VIP di backup funzionino. Puoi configurare la percentuale di traffico visualizzata come frazione da 0 a 100. I valori tipici devono essere inferiori a 10, anche se Cloud DNS consente di indirizzare il 100% del traffico al backup. La configurazione di questo trucco può essere utilizzata come metodo manuale per attivare il failover. Un avvertimento è che, poiché il controllo di integrità può essere applicato solo a un bilanciatore del carico interno, tutti gli indirizzi VIP configurati devono essere un bilanciatore del carico di rete passthrough interno, un Application Load Balancer interno o un Application Load Balancer interno tra regioni.
Controlli di integrità
Cloud DNS supporta i controlli di integrità per bilanciatori del carico di rete passthrough interni e Application Load Balancer interni con l'accesso globale abilitato.
I controlli di integrità per i bilanciatori del carico privati sono disponibili solo nelle zone gestite private. I controlli di integrità non sono disponibili per le zone di forwarding, peering e ricerca inversa gestita.
Per informazioni dettagliate sui controlli di integrità per i bilanciatori del carico, consulta la panoramica sui controlli di integrità.
Controllo di integrità per i bilanciatori del carico di rete passthrough interni
Cloud DNS determina lo stato di integrità di un bilanciatore del carico di rete passthrough interno utilizzando la configurazione integrata del controllo di integrità del bilanciatore del carico. Cloud DNS considera il bilanciatore del carico di rete passthrough interno in stato integro e idoneo a ricevere traffico quando almeno il 20% dei controlli di integrità ha esito positivo.
Per un bilanciatore del carico di rete passthrough interno, Cloud DNS riceve segnali di integrità diretti dalle singole istanze di backend e viene applicato un algoritmo di soglia per determinare se un endpoint è integro o meno.
Un singolo indirizzo IP virtuale del bilanciatore del carico di rete passthrough interno può avere più servizi in esecuzione. Cloud DNS cerca segnali di integrità dal protocollo e dalla porta specificati nella configurazione del controllo di integrità per il bilanciatore del carico. Per informazioni dettagliate sui controlli di integrità, consulta Panoramica dei controlli di integrità.
Per l'Application Load Balancer interno e l'Application Load Balancer interno tra regioni, Cloud DNS considera l'integrità del bilanciatore del carico stesso durante la decisione di routing. Quando un bilanciatore del carico riceve una query, distribuisce il traffico solo ai servizi di backend integri. Per assicurarti che esistano backend integri, puoi gestire il ciclo di vita dei backend utilizzando servizi come gruppi di istanze gestite (MIG). Cloud DNS non deve necessariamente conoscere lo stato di integrità dei singoli backend, poiché è il bilanciatore del carico a gestire questa attività.
Criteri round robin ponderati e controlli di integrità
Cloud DNS supporta ponderazioni da 0 a 1000, incluse entrambe. Quando vengono inclusi i controlli di integrità, si verifica quanto segue:
- Se configuri più target, tutti con ponderazione 0, il traffico viene distribuito equamente tra i target.
- Se configuri un nuovo target ponderato diverso da zero, questo diventa il target principale e tutto il traffico viene spostato verso quel target.
- Man mano che aggiungi altri target con ponderazioni diverse da zero, Cloud DNS calcola dinamicamente la suddivisione del traffico tra i target (con ogni richiesta) e distribuisce il traffico in modo appropriato. Ad esempio, se hai configurato tre target con ponderazioni pari a 0, 25 e 75, il target con ponderazione 0 non riceve traffico, il target con ponderazione 25 riceve un quarto del traffico e il target rimanente riceve tre quarti del traffico in entrata.
- Se i controlli di integrità sono associati a target ponderati diversi da zero ma non a target ponderati pari a zero, questi ultimi vengono sempre considerati integri. Se tutti i record diversi da zero non sono integri, Cloud DNS restituisce i record con ponderazione zero.
- Se i controlli di integrità sono associati a record con ponderazione non pari a zero e zero e se tutti i record non superano i controlli di integrità, Cloud DNS restituisce eventuali target ponderati diversi da zero ed evita completamente i target con ponderazione pari a zero.
- Quando Cloud DNS sceglie un bucket di ponderazione da restituire al richiedente (un singolo elemento del criterio), viene restituito solo l'indirizzo IP in quel bucket di ponderazione. Se specifichi un solo indirizzo IP nel bucket di ponderazione, solo quell'indirizzo IP verrà incluso nella risposta. Se nel bucket di ponderazione è presente più di un indirizzo IP, Cloud DNS restituisce tutti gli indirizzi IP in ordine casuale.
Criterio di geolocalizzazione con controllo di integrità
Per i criteri di geolocalizzazione con i controlli di integrità abilitati, si verifica quanto segue:
- Quando in un bucket geografico sono configurati più indirizzi IP e tutti gli indirizzi IP dispongono del controllo di integrità, vengono restituiti solo gli indirizzi IP integri.
- Se vengono combinati controlli di integrità e nessun controllo di integrità e tutti gli indirizzi IP sottoposti a controllo di integrità non vanno a buon fine, Cloud DNS restituisce tutti gli indirizzi IP per i quali non è stato configurato il controllo di integrità. In questo scenario, non si verifica il failover automatico all'area geografica più vicina successiva.
- Questo criterio instrada automaticamente il traffico al bucket geografico più vicino
quando:
- Il controllo di integrità è abilitato per tutti gli indirizzi IP in un bucket geografico.
- La scherma è disattivata per il criterio.
- Tutti gli indirizzi IP non superano i controlli di integrità. Questo consente di eseguire il failover automatico al successivo targeting geografico più vicino.
Logging del controllo di integrità
Cloud DNS supporta il logging del controllo di integrità e registra lo stato del controllo di integrità di qualsiasi modifica del backend. Ti consente di svolgere le seguenti operazioni:
- Convalida se i criteri di routing funzionano come previsto. Ad esempio:
- Per i criteri
GEO, ti consente di verificare se i criteri rilevano l'area geografica corretta e restituiscono il set di dati RR corretto. - Per i criteri
WRR, consente di verificare se i criteri restituiscono gli indirizzi IP con la ponderazione corretta.
- Per i criteri
- Identifica i problemi dell'infrastruttura con backend e indirizzi IP specifici che presentano errori.
- Risolvi i problemi per cui i backend specifici non vengono mai inclusi o sono gli unici a essere restituiti.
Per creare, modificare o eliminare i criteri di routing DNS, vedi Gestire i criteri di routing DNS e i controlli di integrità.
Tipi di record supportati per i criteri di routing DNS
I criteri di routing DNS non supportano tutti i tipi di record supportati da Cloud DNS. I criteri di routing DNS supportano i seguenti tipi di record.
| Tipo di record | Description |
|---|---|
| A | Indirizzi IPv4 |
| AAAA | Indirizzi IPv6 |
| CNAME | Nomi canonici |
| MX | Record Mail Exchange |
| Valore di ricarica suggerito | Host/porta (<aclass="external" l10n-attrs-original-order="href,class" l10n-encrypted-href="fbj0fi6rS3pPqxfn3YD3etONK6A9Q8tQ5MUfKCg7jl5ONxJ2KV+27oDWYJ43g//2">RFC 278 |
| TXT | Dati di testo |