Blocco del registrar o difesa a strati: quale scegliere

Immagina di svegliarti e trovare ogni dominio della tua azienda (produzione, staging, quello che ospita i record MX) sospeso dal tuo registrar di domini durante la notte. Nessun deploy si è rotto. Nessun server è andato giù. Qualcuno di un team trust-and-safety (o, più probabilmente, una pipeline automatica di gestione degli abusi) ha girato un interruttore, e la tua intera presenza su internet è sparita. Non è un'ipotesi: succede abbastanza spesso da riempire i forum sysadmin di storie dell'orrore su registrar che disattivano account per segnalazioni di abuso non verificate, tweet ambigui o un'unica immagine segnalata tra milioni di upload degli utenti.

Lavoro da anni nella risposta agli incidenti per team infrastrutturali, e lo schema è sempre lo stesso. Gli ingegneri progettano ridondanze elaborate per il calcolo (multi-AZ, multi-regione, runbook di failover) e poi lasciano l'unico asset che non si può ridistribuire, il nome di dominio stesso, in un singolo account protetto da una password e magari da un codice SMS. Questo articolo confronta due filosofie per gestire questo rischio: l'approccio tradizionale registrar lockdown (scegli un registrar solido, blinda l'account, fidati di loro) contro un approccio a difesa a strati (assumi che il registrar ti tradirà e progetta attorno a questo). Spoiler: servono entrambi, ma il secondo è quello che ti salva davvero alle 3 di notte.

Perché il tuo registrar è un tipo diverso di single point of failure

La maggior parte dei single point of failure nel tuo stack sono cose che controlli tu. Un primary di database, un NAT gateway, un message broker: puoi replicarli, e il piano di failover l'hai scritto tu. Il registrar è diverso per tre motivi. Primo, è una dipendenza del control plane che non puoi replicare. Non puoi avere due registrar per lo stesso dominio: il registry riconosce un solo sponsor. Secondo, i guasti del registrar sono lenti. Un trasferimento di dominio in condizioni normali richiede da cinque a sette giorni, e se il registrar attuale ha disattivato il tuo account potresti non riuscire nemmeno a ottenere il codice di autorizzazione per avviarlo. Terzo, il guasto è in un certo senso avversariale in modo strano: non è un attaccante, è il provider stesso che agisce contro di te in base a una segnalazione di abuso che non hai mai visto.

Anche il raggio d'azione è peggiore di quanto si pensi. Quando un registrar sospende un dominio, di solito punta i record NS a una pagina di takedown oppure smette semplicemente di rispondere. Questo uccide il tuo sito, certo. Ma uccide anche la posta (i record MX vivono nel DNS), il tuo SSO se le callback fanno riferimento al tuo dominio, i tuoi client API, la status page se sta sullo stesso dominio e, la mia preferita, l'indirizzo email su cui dovresti ricevere le istruzioni di recupero. Se l'email dell'account presso il registrar è admin@yourdomain.com e yourdomain.com è sospeso, ora stai cercando di dimostrare la tua identità al supporto da un indirizzo di cui non si fideranno. Ho visto questo loop esatto mangiarsi un'intera giornata di incidente.

E gli incentivi economici giocano contro di te. Quando un registrar viene acquisito da un private equity, come è successo a diversi grandi operatori, il copione è prevedibile: tagliare il supporto umano, automatizzare la gestione degli abusi, alzare i prezzi. I sistemi automatici di gestione degli abusi ottimizzano per il loro rischio, non per il tuo. Sospendere un dominio che poi risulta innocente non costa nulla a loro. Lasciare online un dominio che poi risulta colpevole costa problemi con il registry e cattiva stampa. Indovina in quale direzione sbaglia l'automazione.

Primo approccio: Registrar Lockdown, rafforzare il single point

La filosofia del lockdown dice: accetta che il registrar sia un single point of failure, e rendi quel punto il più solido possibile. È la strategia che la maggior parte delle aziende adotta davvero, che l'abbiano formulata o no. Fatta bene, appare così:

• Scegli il registrar in base alla qualità del supporto, non al prezzo. I 3 dollari l'anno che risparmi per dominio non valgono nulla rispetto a un giorno di downtime. Ti servono supporto telefonico, un referente dedicato per portfolio grandi e un'azienda che potresti citare in giudizio nella tua giurisdizione, se mai dovesse servire.
• Attiva il registrar lock (clientTransferProhibited) su ogni dominio e il registry lock su quelli critici. Il registry lock richiede una verifica fuori banda, di solito una telefonata con una passphrase, prima di qualsiasi modifica ai nameserver o ai trasferimenti. È fastidioso, ed è proprio questo il punto.
• Usa l'autenticazione a due fattori con chiave hardware o TOTP, mai SMS. Le storie di agenti del supporto che rimuovono il 2FA dopo una chat convincente sono innumerevoli; alcuni registrar oggi offrono politiche del tipo 'nessuna modifica all'account senza la chiave hardware'. Approfittane.
• Usa un indirizzo email dedicato e basato sui ruoli per l'account presso il registrar, che NON sia su un dominio registrato presso lo stesso registrar. Ad esempio domains-admin@example.org, registrato altrove.
• Limita l'accesso. Due o tre persone nominative, credenziali in un vault aziendale, non un login condiviso in un foglio di calcolo.
• Documenta tutto: numero di account, PIN, percorsi di escalation del supporto, i documenti esatti con cui l'account è verificato. Inseriscilo nel tuo runbook di incidente.

Il lockdown ha punti di forza concreti. Previene il disastro più comune con i registrar, che non è il sequestro ma il dirottamento. Trasferimenti ottenuti con social engineering e takeover di account hanno sottratto domini di valore per anni, e il registry lock più il 2FA hardware blocca quasi tutto. Inoltre è economico e non richiede lavoro ingegneristico continuativo.

Ma la verità scomoda è questa: il lockdown ti protegge dagli attaccanti, non dal registrar stesso. Ogni controllo elencato sopra è un controllo che il registrar gestisce. Se la loro automazione antiabuso disattiva il tuo account, il registrar lock ti sta bloccando fuori, il PIN di supporto si trova in un sistema a cui non puoi accedere, e la persona che potrebbe sbloccare tutto potrebbe non esistere più, perché il supporto è stato 'ottimizzato' il trimestre scorso. I professionisti segnalano tempi di ripristino di oltre sei ore anche nei casi semplici di falso positivo, e vicende di più giorni quando la sospensione attraversa un weekend. Il lockdown è necessario. Non è sufficiente.

Secondo approccio: Difesa a strati, presupponi che il registrar ti tradirà

La filosofia a strati parte da una premessa più cupa: un giorno, per dolo, automazione o errore, il tuo registrar porterà giù i tuoi domini, e dovrai essere di nuovo online prima che la loro coda di supporto arrivi a te. È la stessa mentalità alla base della progettazione difensiva contro i guasti catastrofici: non eviti il disastro, lo rendi sopravvivibile.

La tecnica centrale è separare i livelli che di solito sono raggruppati. La maggior parte delle piccole aziende compra il dominio, usa il DNS del registrar, ospita sul servizio di hosting dello stesso registrar e prende anche la posta. Sono quattro single point of failure impilati in un solo account. Separali:

• Registrazione: presso il registrar A, scelto per stabilità e supporto.
• DNS autoritativo: presso un provider DNS indipendente B (o due provider in configurazione dual-primary), gestito come codice.
• Hosting: dove ha senso per il workload, senza legami con nessuno dei due.
• Email: un provider dedicato, con gli indirizzi di recupero account per A e B su un altro dominio ancora.
• Dominio di riserva: un dominio di fallback preconfigurato presso un registrar diverso, con certificati TLS emessi e una versione minima dei servizi più critici già in ascolto su di esso.

Il dominio di riserva merita attenzione perché quasi nessuno lo fa, ed è la mossa con il miglior rapporto impatto/sforzo. Quando i domini principali vengono sospesi, TTL del DNS e cache dei resolver fanno sì che non puoi semplicemente 'passare al backup': il backup deve essere esistito, essere stato scaldato ed essere risolvibile prima dell'incidente. Un fallback come example-status.net, registrato altrove, che ospita la tua status page, le comunicazioni di incidente e un record MX di emergenza, trasforma un'interruzione che potrebbe uccidere l'azienda in un martedì imbarazzante.

DNS come codice: il livello che tutti saltano

Ecco un guasto che ho visto due volte in incidenti reali: il team recupera il dominio dopo la sospensione del registrar, riattiva tutto, e il DNS è sbagliato, perché la 'fonte di verità' della zona era l'interfaccia web del registrar, inaccessibile durante l'incidente e già distante da chiunque ne ricordasse i dettagli. Ricostruire a memoria un file di zona da 200 record durante un'interruzione è una forma particolare di sofferenza. Come abbiamo già scritto, gli errori di configurazione DNS continuano a rompere la produzione anche in condizioni normali; durante un incidente con il registrar sono catastrofici.

La soluzione è noiosa: gestisci la zona DNS come codice, sotto controllo di versione, distribuita dalla CI. Strumenti come dnscontrol o i provider DNS di Terraform ti permettono di descrivere la zona in modo dichiarativo e di spingerla su più provider. Così lo stato del DNS sopravvive alla perdita del control plane di qualsiasi provider, e 'passa al provider DNS B' diventa una modifica di una riga e un deploy, non una sessione eroica di copia-incolla.

# dnsconfig.js — one zone, two providers, deployed by CI
var REG_NONE = NewRegistrar('none');
var DSP_CLOUDFLARE = NewDnsProvider('cloudflare');
var DSP_ROUTE53 = NewDnsProvider('route53');
D('example.com', REG_NONE,
DnsProvider(DSP_CLOUDFLARE),
DnsProvider(DSP_ROUTE53),   // dual-authoritative: either can die
A('@', '203.0.113.10'),
A('www', '203.0.113.10'),
MX('@', 10, 'mail.example.net.'),   // MX on a DIFFERENT TLD/provider domain
TXT('@', 'v=spf1 include:_spf.example.net -all'),
CNAME('status', 'statuspage.example.net.')
);

Il DNS autoritativo doppio è sottovalutato. La maggior parte dei resolver prova volentieri tutti i nameserver elencati, quindi se un provider va in outage (e i grandi provider DNS ne hanno), la risoluzione continua. Il problema è tenere sincronizzati entrambi i provider, ed è esattamente ciò che il DNS-as-code ti dà gratis. Senza, il DNS a doppio provider genera disallineamenti ed è probabilmente peggio di un provider singolo.

Una precisazione sui TTL: ai team piace alzarli a 86400 'per le prestazioni', per poi scoprire durante un incidente che un quarto di internet tiene in cache per un intero giorno i vecchi record dei nameserver. Per i record legati ai nameserver e per tutto ciò che potresti dover cambiare in emergenza, tieni i TTL tra 300 e 900 secondi. Il costo in volume di query è trascurabile rispetto alla reattività.

Testa a testa: quando vince ciascun approccio

Diciamolo chiaramente sul compromesso, perché le due strategie ottimizzano per minacce diverse e per organizzazioni diverse.

• Modello di minaccia: il lockdown vince contro dirottamenti e social engineering, i disastri statisticamente più comuni. La difesa a strati vince contro i guasti lato registrar: automazione antiabuso, sequestro dell'account, insolvenza o collasso del supporto.
• Costo: il lockdown costa quasi nulla: tariffe del registry lock, una chiave hardware, disciplina. La difesa a strati costa la fattura di un secondo provider, un dominio di riserva, la plumbing della CI e attenzione continua per prevenire i disallineamenti.
• Tempo di ripristino: in caso di sequestro, i team con solo lockdown dipendono da una coda di supporto (da ore a giorni, secondo tutte le storie che ho sentito). I team con un dominio di riserva già pronto tornano online in minuti o ore.
• Carico operativo: il lockdown si imposta e si dimentica. La difesa a strati marcisce se non viene mantenuta: un dominio di fallback mai testato con un certificato scaduto è security theater.
• Adattamento organizzativo: una startup di cinque persone con un solo prodotto SaaS dovrebbe fare il lockdown completo più le due mosse a strati più economiche (DNS come codice esterno, email di recupero fuori dal dominio). Un'azienda il cui fatturato dipende dal dominio ha bisogno dello stack a strati completo.

Il lockdown protegge i tuoi domini dagli attaccanti. La difesa a strati protegge il tuo business dal tuo registrar. Sei esposto a entrambi, quindi ti servono entrambi.

Il runbook di recupero che nessuno scrive finché non è troppo tardi

Qualunque postura tu scelga, scrivi adesso il runbook per il sequestro. Gli incidenti andati bene che ho visto ne avevano uno; i disastri erano improvvisati. Il tuo dovrebbe coprire, in ordine: confermare l'ambito (è un dominio solo o tutto l'account? controlla i codici di stato di whois come clientHold o serverHold), aprire il ticket di supporto con gli identificativi dell'account documentati, attivare il dominio di fallback e aggiornare le comunicazioni di stato, avvisare i clienti tramite canali che non dipendono dal dominio morto, e avviare in parallelo il processo di trasferimento in uscita. Non aspettare che la situazione si risolva per decidere di andartene.

Prova anche le parti noiose. Riesci davvero ad accedere al registrar da un dispositivo pulito, con la chiave hardware, senza il password manager che sta dietro SSO sul dominio sospeso? La passphrase del registry lock è dove l'on-call può trovarla? I team testano il failover dei database ogni trimestre, e il ripristino del registrar mai. Visto che il guasto del registrar abbatte proprio l'SSO con cui raggiungi tutto il resto, queste priorità sono capovolte.

La mia raccomandazione

Fai il lockdown completo: è un pomeriggio di lavoro e blocca l'attacco più probabile. Poi implementa esattamente tre componenti di difesa a strati, in quest'ordine: sposta il DNS autoritativo fuori dal registrar e gestiscilo come codice; sposta l'email di recupero dell'account del registrar su un dominio presso un registrar diverso; e predisponi un dominio di fallback caldo con certificati, status page e MX di emergenza. Questi tre coprono le modalità di guasto dominanti con qualche centinaio di euro l'anno. Riserva l'architettura completa a doppio registrar e doppio DNS alle organizzazioni che sanno dire quanto costa loro un giorno di perdita totale dei domini: se quella cifra ha sei zeri, sai già cosa fare.

E se stai ancora scegliendo un registrar principalmente in base al prezzo, fermati. Il mercato dei registrar low-cost si sta consolidando sotto proprietari che hanno interesse a sostituire il giudizio umano con automazione che ti sospenderà volentieri per un falso positivo e arriverà al tuo ticket giovedì. Il tuo dominio è l'unico pezzo di infrastruttura che non puoi ridistribuire da un'immagine container. Trattalo di conseguenza.