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à.
Protezione dai registri di deleghe con strascichi in Route 53
Con Route 53, un cliente può creare una zona ospitata, ad esempio example.com per ospitare i propri record DNS. Ogni zona ospitata è dotata di un «set di delega», ovvero un set di quattro name server che un cliente può utilizzare per configurare i record NS nel dominio principale. Questi record NS possono essere denominati «record NS di delega» o «record di delega».
Affinché la zona ospitata di example.com Route 53 diventi autorevole, il legittimo proprietario del example.com dominio deve configurare i record di delega nel proprio dominio principale «.com» tramite il registrar di domini. Nei casi in cui un cliente perda l'accesso ai quattro name server configurati nel dominio principale, ad esempio perché la zona ospitata associata viene eliminata, può creare un rischio che un utente malintenzionato possa sfruttare. Si tratta del rischio di «perdita di dati di delega».
Route 53 protegge dal rischio di perdita dei record di delega nel caso in cui una zona ospitata venga eliminata. Dopo l'eliminazione, se viene creata una nuova zona ospitata con lo stesso nome di dominio, Route 53 controllerà se i record di delega che puntano alla zona ospitata eliminata sono ancora presenti nel dominio principale. In tal caso, Route 53 impedirà l'assegnazione di nameserver sovrapposti. Questo è lo scenario 1 negli esempi seguenti.
Tuttavia, ci sono altri rischi legati al record di delega, dai quali Route 53 non è in grado di proteggersi, come descritto negli scenari da 2 a 5 negli esempi seguenti. Per proteggerti da questa serie più ampia di rischi, assicurati che i record NS principali corrispondano al set di delega impostato per la zona ospitata di Route 53. Puoi trovare il set di delega di una zona ospitata tramite la console di Route 53 o. AWS CLI Per ulteriori informazioni, consulta Elencazione di record o get-hosted-zone
Inoltre, abilitare la firma DNSSEC per una zona ospitata su Route 53 può fungere da ulteriore livello di protezione oltre alle best practice sopra menzionate. Il DNSSEC autentica che le risposte DNS provengano dalla fonte autorevole, proteggendo efficacemente da questo rischio. Per ulteriori informazioni, consulta Configurazione della firma DNSSEC in Amazon Route 53.
Esempi
Nei seguenti esempi, supponiamo che tu abbia un dominio e il relativo dominio figlio. example.com child.example.com Spiegheremo come in vari scenari è possibile creare record di delega sospesi, come Route 53 protegge il dominio dagli abusi e come mitigare efficacemente i rischi associati ai record di delega sospesi.
- Scenario 1:
<ns1><ns2><ns3><ns4>Crei una zona ospitata
child.example.comcon quattro name server:,, e. <ns4>Si configura correttamente la delega nella zona ospitataexample.com, creando record NS di delegachild.example.comcon quattro name server<ns1>, <ns2><ns3>, e. Quando una zonachild.example.comospitata viene eliminata senza rimuovere i record NS della delegaexample.com, Route 53 proteggechild.example.comdal rischio di perdita dei record di delega impedendo <ns1><ns2><ns3>e <ns4>impedendo l'assegnazione a zone ospitate di nuova creazione con lo stesso nome di dominio.- Scenario 2:
Simile allo scenario 1, ma questa volta si eliminano la zona ospitata secondaria E i record NS della delega nella zona ospitata.
example.comTuttavia, si aggiungono nuovamente i record NS della delega<ns1>, <ns2><ns3>, e <ns4>senza creare una zona ospitata secondaria. Qui, <ns1><ns2><ns3>, e <ns4>restano in sospeso i record delle deleghe, perché Route 53 rimuove il blocco, che impediva<ns1>, <ns2><ns3>, e non <ns4>veniva assegnato e ora consentirà alle zone ospitate appena create di utilizzare i server di nomi sopra elencati. Per ridurre il rischio <ns1><ns2><ns3>, rimuovi e <ns4>dai record di delega e aggiungili nuovamente solo dopo aver creato la zona ospitata secondaria.- Scenario 3:
<ns2><ns3><ns4>In questo scenario, si crea un set di delega riutilizzabile di Route 53 con i name server<ns1>,, e. Quindi, si delega il dominio
example.coma questi name server nel dominio principale..comTuttavia, non hai ancora creato la zona ospitata perexample.comil set di delega riutilizzabile. Qui,, <ns1><ns2><ns3>, e <ns4>sono sospesi i record delle deleghe. <ns1><ns2><ns3><ns4>Per mitigare il rischio, crea la zona ospitata utilizzando il set di delega riutilizzabile con i name server,, e.- Scenario 4:
Si creano zone ospitate sia
child.example.comcon name server <ns1><ns2>,<ns3>, <ns4>e, siagrandchild.child.example.comcon name server <ns5><ns6>,<ns7>, e<ns8>. Tuttavia, si delegano entrambe direttamente nellaexample.comzona, il che crea un rischio di delega irreversibile. Per assicurarvi che le deleghe seguano la corretta gerarchia DNS, delegate i sottodomini solo attraverso le loro zone principali immediate. Ad esempio, se desideri delegaregrandchild.child.example.com: delega primachild.example.comcon i server dei nomi,, <ns1><ns2><ns3>e <ns4>nellaexample.comzona, quindi delegagrandchild.child.example.comcon i server dei nomi, <ns5><ns6><ns7>, e <ns8>nella zona e rimuovi tutte le deleghe dirette per dallachild.example.comzona.grandchild.child.example.comexample.com- Scenario 5:
Se si delega un dominio o un sottodominio ai name server Route 53 prima di creare una zona ospitata corrispondente, si creano record di delega sospesi. Questo è simile al caso dello Scenario 3, ma il rischio si applica anche quando non viene creato alcun set di delega riutilizzabile. Ad esempio, si delega il dominio
example.comai name server<ns1>,<ns2>, <ns3>e <ns4>nel dominio principale.com, ma nessuno di questi name server è mai stato ospitato.example.comRoute 53 non può proteggersi da questo problema perché non è mai esistita alcuna zona ospitata in grado di stabilire un blocco su quei server di nomi per quel nome di dominio. Per ridurre il rischio, delega solo i name server di Route 53 che appartengono a una zona pubblica ospitata da te.
