

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Le migliori pratiche per VPC Resolver
<a name="best-practices-resolver"></a>

Questa sezione fornisce le best practice per ottimizzare Amazon Route 53 VPC Resolver, trattando i seguenti argomenti:

1. **Evitare configurazioni di loop con Resolver Endpoints:**
   + Previeni i loop di routing assicurandoti che lo stesso VPC non sia associato sia a una regola Resolver che al relativo endpoint in ingresso.
   + Utilizzalo per condividere tra account mantenendo le configurazioni AWS RAM di routing corrette VPCs .

   Per ulteriori informazioni, consulta [Evitare configurazioni loop con endpoint di Resolver](best-practices-resolver-endpoints.md)

1. **Scalabilità degli endpoint Resolver:**
   + Implementa regole di gruppo di sicurezza che consentano il traffico in base allo stato della connessione per ridurre il sovraccarico di tracciamento della connessione
   + Segui le regole consigliate sui gruppi di sicurezza per gli endpoint Resolver in entrata e in uscita per massimizzare la velocità di trasmissione delle query.
   + Monitora le combinazioni uniche di indirizzi IP e porte che generano traffico DNS per evitare limiti di capacità. 

   Per ulteriori informazioni, consulta [Dimensionamento dell'endpoint di Resolver](best-practices-resolver-endpoint-scaling.md)

1. **Alta disponibilità per gli endpoint Resolver:**
   + Crea endpoint in entrata con indirizzi IP in almeno due zone di disponibilità per la ridondanza.
   + Fornisci interfacce di rete aggiuntive per garantire la disponibilità durante la manutenzione o i picchi di traffico

   Per ulteriori informazioni, consulta [Alta disponibilità di endpoint di Resolver](best-practices-resolver-endpoint-high-availability.md)

1. **Prevenzione degli attacchi DNS Zone Walking:**
   + Fai attenzione ai potenziali attacchi DNS zone walking, in cui gli aggressori tentano di recuperare tutti i contenuti dalle zone DNS con firma DNSSEC.
   + Se i tuoi endpoint subiscono un rallentamento dovuto alla sospetta camminata in zona, contatta il Supporto AWS per ricevere assistenza. 

   Per ulteriori informazioni, consulta [Zona DNS](best-practices-resolver-zone-walking.md)

 Seguendo queste best practice, puoi ottimizzare le prestazioni, la scalabilità e la sicurezza delle tue implementazioni VPC Resolver, garantendo una risoluzione DNS affidabile ed efficiente per le tue applicazioni e risorse.

# Evitare configurazioni loop con endpoint di Resolver
<a name="best-practices-resolver-endpoints"></a>

Non associare lo stesso VPC a una regola del Resolver e al relativo endpoint in entrata (sia che si tratti di una destinazione diretta dell'endpoint o tramite un server DNS on-premise). Quando l'endpoint in uscita in una regola Resolver punta a un endpoint in ingresso che condivide un VPC con la regola, può causare un ciclo in cui la query viene continuamente passata tra gli endpoint in entrata e in uscita.

La regola di inoltro può ancora essere associata ad altre regole VPCs condivise con altri account utilizzando (). AWS Resource Access Manager AWS RAM Le zone ospitate private associate all'hub o a un VPC centrale verranno comunque risolte dalle query agli endpoint in ingresso perché una regola del resolver di inoltro non modifica questa risoluzione.

# Dimensionamento dell'endpoint di Resolver
<a name="best-practices-resolver-endpoint-scaling"></a>

I gruppi di sicurezza dell'endpoint di Resolver utilizzano il monitoraggio delle connessioni per raccogliere informazioni sul traffico da e verso gli endpoint. Ogni interfaccia di endpoint dispone di un numero massimo di connessioni che possono essere monitorate e un volume elevato di query DNS può superare le connessioni e causare limitazione e perdita di query. Il tracciamento delle connessioni AWSè il comportamento predefinito per il monitoraggio dello stato del traffico che scorre attraverso i gruppi di sicurezza (). SGs L'utilizzo del tracciamento delle connessioni SGs ridurrà la velocità effettiva del traffico, tuttavia è possibile implementare connessioni non tracciate per ridurre il sovraccarico e migliorare le prestazioni. [Per ulteriori informazioni, consulta Connessioni non tracciate.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#untracked-connections)

Se il tracciamento delle connessioni viene applicato utilizzando regole restrittive dei gruppi di sicurezza o le query vengono instradate tramite Network Load Balancer (vedere [Connessioni tracciate automaticamente](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#automatic-tracking)), il numero massimo complessivo di query al secondo per indirizzo IP per un endpoint può essere pari a 1500.

**Raccomandazioni sulle regole del Security Group in ingresso e in uscita per l'endpoint Resolver in entrata**


****  

| 
| 
| **Regole di ingresso** | 
| --- |
| Tipo di protocollo | Numero della porta | IP di origine | 
| TCP  | 53 | 0.0.0.0/0 | 
| UDP | 53 | 0.0.0.0/0 | 
| **Regole di uscita** | 
| --- |
| Tipo di protocollo | Numero della porta | IP di destinazione | 
| TCP | Tutti | 0.0.0.0/0 | 
| UDP | Tutti | 0.0.0.0/0 | 

**Raccomandazioni sulle regole del gruppo di sicurezza in ingresso e in uscita per l'endpoint Resolver in uscita**


****  

| 
| 
| **Regole di ingresso** | 
| --- |
| Tipo di protocollo | Numero della porta | IP di origine | 
| TCP  | Tutti | 0.0.0.0/0 | 
| UDP | Tutti | 0.0.0.0/0 | 
| **Regole di uscita** | 
| --- |
| Tipo di protocollo | Numero della porta | IP di destinazione | 
| TCP | 53 | 0.0.0.0/0 | 
| UDP | 53 | 0.0.0.0/0 | 

**Nota**  
**Requisiti delle porte del gruppo di sicurezza:**  
**Gli endpoint in entrata** richiedono regole di ingresso che consentano a TCP e UDP sulla porta 53 di ricevere query DNS dalla rete. Le regole di uscita possono consentire tutte le porte poiché l'endpoint potrebbe dover rispondere alle query provenienti da varie porte di origine.
Gli **endpoint in uscita** richiedono regole di uscita che consentano l'accesso TCP e UDP alle porte utilizzate per le query DNS sulla rete. La porta 53 è mostrata nell'esempio precedente perché è la porta DNS più comune, ma la rete potrebbe utilizzare porte diverse. Le regole di ingresso possono consentire a tutte le porte di accogliere le risposte dei server DNS.

**Endpoint di Resolver in entrata**

Per i client che utilizzano un endpoint di Resolver in ingresso, la capacità dell'interfaccia di rete elastica sarà influenzata se si dispone di oltre 40.000 combinazioni di indirizzi IP e porte univoche che generano il traffico DNS.

# Alta disponibilità di endpoint di Resolver
<a name="best-practices-resolver-endpoint-high-availability"></a>

Quando crei gli endpoint in entrata VPC Resolver, Route 53 richiede la creazione di almeno due indirizzi IP a cui i resolver DNS della tua rete inoltreranno le query. Devi inoltre specificare gli indirizzi IP in almeno due zone di disponibilità per assicurare la ridondanza. 

Se necessiti che siano sempre disponibili più endpoint dell'interfaccia di rete elastica, ti suggeriamo di creare almeno un'interfaccia di rete in più del necessario, così da disporre di capacità aggiuntiva per gestire eventuali picchi di traffico. L'interfaccia di rete aggiuntiva garantisce inoltre la disponibilità durante le operazioni di servizio, come la manutenzione o gli aggiornamenti.

Per ulteriori informazioni, consulta questo articolo dettagliato del blog: [Come](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-achieve-dns-high-availability-with-route-53-resolver-endpoints/) ottenere un'elevata disponibilità DNS con gli endpoint Resolver e. [Valori specificati durante la creazione o la modifica di endpoint in entrata](resolver-forwarding-inbound-queries-values.md)

# Zona DNS
<a name="best-practices-resolver-zone-walking"></a>

Un attacco di zona DNS prova a ottenere tutto il contenuto dalle zone DNS firmate da DNSSEC. Se il team di VPC Resolver rileva uno schema di traffico che corrisponde a quello generato quando si visitano zone DNS sul tuo endpoint, il team di assistenza limiterà il traffico sull'endpoint. Di conseguenza, potresti osservare un'alta percentuale di query DNS che scadono.

Se osservi una capacità ridotta sui tuoi endpoint e ritieni che l'endpoint sia stato limitato erroneamente, vai su home\$1/ per creare una richiesta di assistenza. https://console.aws.amazon.com/support/ 