Domini di primo, secondo e terzo livello: architettura DNS, TLD e sottodomini

Il termine “dominio” in ambito web indica molto più di un semplice indirizzo digitato nella barra del browser. È il punto di ingresso di un’architettura gerarchica distribuita — il Domain Name System (DNS) — governata da standard IETF (RFC 1034, RFC 1035, RFC 2181) e da una catena di responsabilità che coinvolge ICANN, IANA, registry di TLD e registrar.

Questa guida affronta l’architettura dei domini dal livello protocollare fino alle implicazioni SEO, chiarendo gerarchie (TLD, SLD, sottodomini), lifecycle di registrazione, record DNS, transizione da WHOIS a RDAP, IDN e criteri tecnici di scelta. Ogni sezione include riferimenti alle specifiche ufficiali e implicazioni operative per chi gestisce infrastrutture web di produzione.

Anatomia di un nome di dominio: FQDN, label e gerarchia DNS

Un nome di dominio completo — Fully Qualified Domain Name (FQDN) — è una sequenza di etichette (label) separate da punti, letta da destra verso sinistra nella gerarchia DNS. Ogni label corrisponde a un nodo nell’albero del namespace globale, la cui radice è la root zone gestita da IANA.

Prendendo come esempio shop.evemilano.com. — notare il punto finale, che chiude la gerarchia al nodo radice ed è spesso implicito — l’albero si legge così:

1. Root (label vuota, rappresentata dal punto finale) — gestita dai 13 root server logici (A-M), operati da 12 organizzazioni tra cui Verisign, ICANN, RIPE NCC, NASA.
2. TLD → com — dominio di primo livello, registry Verisign.
3. SLD → evemilano — dominio di secondo livello, il nome effettivamente registrato.
4. Sottodominio / terzo livello → shop — label aggiuntiva pubblicata nella zona authoritative di evemilano.com.

Limiti tecnici definiti dagli RFC

RFC 1035 sezione 2.3.4 fissa vincoli precisi che qualsiasi implementazione DNS deve rispettare. Violarli provoca rifiuti al momento della registrazione o errori di risoluzione downstream.

Vincolo	Limite	Riferimento
Lunghezza massima di una singola label	63 ottetti	RFC 1035 §2.3.4
Lunghezza totale di un FQDN (rappresentazione wire)	255 ottetti (≈253 caratteri visibili)	RFC 1035 §2.3.4
Caratteri ammessi in una label (LDH rule)	lettere a-z, cifre 0-9, trattino -	RFC 952 / RFC 1123
Trattino iniziale o finale in una label	vietato	RFC 1123 §2.1
Case sensitivity	insensitive	RFC 4343

I caratteri non ASCII (alfabeti non latini, accenti) sono supportati tramite punycode — codifica ASCII-compatibile definita da RFC 3492 — di cui si parla nella sezione dedicata agli IDN.

Dominio di primo livello (TLD): tipologie e governance

Il Top Level Domain è la label più a destra nell’FQDN e rappresenta il livello immediatamente sotto la root. La zona radice è amministrata da IANA (funzione svolta da ICANN tramite PTI — Public Technical Identifiers) e al momento della stesura include oltre 1.500 TLD attivi. Non sono tutti equivalenti: si distinguono in categorie con policy e pricing model molto diversi.

Categoria	Esempi	Registry	Eligibility
gTLD (generic)	.com, .net, .org, .info, .biz	Verisign, PIR, Identity Digital	Aperta
new gTLD (round 2012, round 2026)	.app, .dev, .cloud, .ai, .shop	Varie (Google Registry, Identity Digital, ecc.)	Variabile, alcune ristrette
ccTLD (country code)	.it, .de, .fr, .uk, .us	Registry nazionale (Registro.it per .it)	Spesso ristretta per cittadinanza/residenza
IDN ccTLD	.рф, .中国, .한국	Registry nazionali	Variabile
sTLD (sponsored)	.edu, .gov, .mil, .aero, .museum	Sponsor community	Molto ristretta
Brand TLD	.google, .apple, .bmw	Il brand stesso	Solo interno al brand
infrastructure TLD	.arpa	IAB / IANA	Uso tecnico (reverse DNS)

ccTLD e gerarchia di secondo livello: il caso .uk, .co.uk, .ac.uk

Alcuni registry di ccTLD introducono una gerarchia di secondo livello semantica. Nel namespace .uk, ad esempio, la label .ac.uk è riservata a istituzioni accademiche, .co.uk a entità commerciali, .gov.uk al governo. Queste sono tecnicamente Second Level Domains dal punto di vista DNS ma funzionano come namespace di registrazione — il nome effettivamente registrato (es. bbc.co.uk) è quindi un SLD sotto un ccSLD.

Lo stesso pattern si applica a .com.au, .co.jp, .pvt.k12.ma.us (scuole pubbliche K-12 del Massachusetts). La lista completa di questi suffissi registrabili è mantenuta come Public Suffix List da Mozilla (publicsuffix.org) — riferimento autoritativo usato da browser e framework per determinare il confine tra dominio registrabile e sottodominio (fondamentale per cookie scope e same-origin policy).

Scelta del TLD e impatti SEO internazionali

Google tratta i ccTLD come segnale geografico esplicito e non configurabile in Search Console (non è possibile impostare un target geografico diverso per un .it). I gTLD e i new gTLD sono geo-neutrali e permettono di dichiarare target geografici via hreflang o impostando il targeting per directory. Per approfondire le strategie di gestione multi-lingua e multi-country rimando a ccTLD o gTLD? SEO internazionale e gestione siti multi lingua.

Dominio di secondo livello (SLD): il nome registrabile

Il Second Level Domain è la label immediatamente a sinistra del TLD e coincide, nella stragrande maggioranza dei casi, con il nome effettivamente registrato dal registrant presso un registrar. In evemilano.com, la stringa evemilano è l’SLD sotto il TLD .com.

Dal punto di vista DNS, il bundle SLD+TLD costituisce la zone apex (o naked domain, root domain, bare domain): il nodo in cui devono risiedere i record SOA e NS authoritative della zona. Qui si manifesta un limite tecnico ben noto: il record CNAME non può essere pubblicato al vertice della zona, perché confliggerebbe con i record SOA/NS (RFC 1912 §2.4). Soluzioni operative includono ALIAS / ANAME (record proprietari di alcuni DNS provider come Cloudflare, Route 53, DNSimple) o CNAME flattening.

La scelta dell’SLD è la decisione più visibile del processo: determina brand, memorabilità, esposizione a typo-squatting e cybersquatting. Per un’analisi economica e reputazionale dell’SLD come asset aziendale rimando alle guide Valutazione di domini: come si calcola il valore di un dominio web e Valutare la storia e la salute di un dominio.

Dominio di terzo livello e sottodomini: chiariamo la confusione

La letteratura divulgativa italiana tende a distinguere “dominio di terzo livello” da “sottodominio” come se fossero entità diverse. È una distinzione artificiale. Dal punto di vista DNS non esiste differenza ontologica: qualsiasi label pubblicata a sinistra dell’apex è un sottodominio, indipendentemente dal livello gerarchico.

• www.evemilano.com — sottodominio di 3° livello (la label www è un sottodominio di evemilano.com)
• shop.evemilano.com — sottodominio di 3° livello
• api.v2.evemilano.com — sottodominio di 4° livello (e v2 è a sua volta un sottodominio di 3° livello)
• edge.pop-mil-1.cdn.evemilano.com — sottodominio di 5° livello, pattern tipico delle infrastrutture CDN

Ogni registrazione include implicitamente uno spazio di naming illimitato sulla parte sinistra: il registrant di evemilano.com può pubblicare nella propria zona authoritative quanti sottodomini desidera, senza bisogno di registrare nulla presso il registrar. L’unico limite concreto è la lunghezza totale dell’FQDN (255 ottetti).

Il caso speciale di www

La label www è storicamente il sottodominio canonico per il servizio HTTP, ereditato dalla convenzione anni ’90 che raccomandava un sottodominio dedicato per ogni servizio (ftp., mail., www.). Tecnicamente oggi non ha alcuna funzione speciale: evemilano.com e www.evemilano.com sono due nomi distinti che devono essere normalizzati via redirect 301 a un’unica forma canonica per evitare content duplication e dispersione di segnali. Per l’implementazione lato server vedi Redirezione 301 dominio da www a non www su Nginx.

Registry, Registrar e Registrant: la catena di controllo

Un dominio non si “compra”: si affitta ottenendo il diritto di delega DNS per un periodo determinato (tipicamente 1-10 anni, con rinnovi illimitati). La catena di responsabilità definita dal modello ICANN/IANA coinvolge tre attori distinti.

Attore	Ruolo	Esempi
Registry	Gestisce l’intero TLD: mantiene il database authoritative delle registrazioni, pubblica la zona del TLD nella root, fissa policy e wholesale price.	Verisign (.com, .net), PIR (.org), Registro.it (.it), Identity Digital (molti new gTLD)
Registrar	Intermediario accreditato ICANN (per i gTLD) o dal registry nazionale (per i ccTLD). Fornisce interfaccia utente, fatturazione, customer service e inoltra le operazioni al registry via EPP (RFC 5730).	GoDaddy, Namecheap, Cloudflare Registrar, OVHcloud, Gandi
Registrant	Titolare legale della registrazione. Ha diritti di utilizzo ma non di proprietà permanente. Obblighi: dati di contatto validi, pagamento dei rinnovi.	Persona fisica o giuridica

Il protocollo tecnico di comunicazione tra registrar e registry è EPP (Extensible Provisioning Protocol), definito da RFC 5730 e successivi. Tutte le operazioni — create, update, delete, transfer, renew — passano attraverso messaggi EPP sul canale registrar-registry.

Transfer tra registrar e Auth-Code

Il trasferimento di un dominio tra registrar richiede l’Auth-Code (detto anche EPP code, authInfo): una stringa generata dal registrar corrente che funge da credenziale di autorizzazione al transfer. La procedura ICANN standard impone un’attesa di 60 giorni dopo la registrazione o dopo un precedente transfer (ICANN Transfer Policy) durante i quali il dominio è bloccato in uscita.

Lifecycle di un dominio: dalla registrazione al drop

Il ciclo di vita di una registrazione gTLD segue fasi definite da ICANN (Expired Registration Recovery Policy, ERRP) e descritte in modo simile per la maggior parte dei ccTLD. Conoscerle è critico per chi gestisce portafogli di domini, migrazioni, acquisizioni e per chi valuta domini scaduti in ottica drop-catch.

1. Available — il dominio non è registrato ed è disponibile per la registrazione.
2. Registered / Active — registrazione attiva, il dominio risolve normalmente.
3. Expired / Auto-Renew Grace Period (AGP) — 0-45 giorni dopo la scadenza. Il registrar può rinnovare automaticamente o sospendere la risoluzione (tipicamente viene puntato a una parking page). Il registrant può ancora rinnovare al prezzo standard.
4. Redemption Grace Period (RGP) — 30 giorni successivi. Il dominio è rimosso dal DNS (non risolve più) ma può essere recuperato con un restore, tipicamente a costo elevato (80-200 €).
5. Pending Delete — 5 giorni finali. Nessun recupero possibile. Il dominio è in coda per il rilascio definitivo.
6. Released / Dropped — il dominio torna available. Servizi di drop-catch (SnapNames, DropCatch, NameJet) tentano la registrazione nei millisecondi successivi al rilascio tramite connessioni EPP multiple.

Nota: i domini con backlink profile o traffic history interessante vengono raramente “dropped” — sono catturati prima dai servizi di drop-catch e rivenduti all’asta. L’acquisto di domini scaduti è pratica legittima ma comporta rischi reputazionali: se il dominio era stato usato per spam, PBN o attività in violazione delle policy Google, i segnali negativi persistono. Approfondimento sul tema nelle policy antispam ufficiali di Google.

Quanto costa un dominio: prezzi reali per tipologia TLD

Il costo di registrazione dipende dal TLD (wholesale fissato dal registry), dal registrar (margine commerciale e servizi inclusi) e da promozioni di primo anno. I prezzi seguenti sono indicativi al netto di IVA, rilevati su registrar at-cost (Cloudflare Registrar, Porkbun, Namecheap) per fornire un benchmark di riferimento — evitano i tipici markup pesanti di GoDaddy e simili.

Tipologia	Prezzo annuale tipico	Note
.com legacy	9-13 €	Wholesale Verisign ~10,26 $ (dal 2024). Rinnovo simile al primo anno.
gTLD classici (.net, .org, .info)	10-15 €	Prezzi stabili.
ccTLD europei (.it, .de, .fr)	6-15 €	Talvolta restrizioni di eligibility.
New gTLD lifestyle (.shop, .blog, .club)	15-50 €	Spesso promo aggressive al primo anno, rinnovo molto più caro.
New gTLD premium tech (.io, .ai, .dev, .app)	30-90 €	.ai è un ccTLD di Anguilla con prezzi registry elevati.
Premium names (tier pricing del registry)	100-50.000+ €/anno	Alcuni registry classificano nomi “di valore” con prezzi multipli. Attenzione ai rinnovi.
Domini aftermarket	100 € – 10M+ €	Prezzo di mercato deciso dal reseller (Sedo, Dan, Afternic).

Nota operativa: prima di registrare, verificare sempre il prezzo di rinnovo e non solo quello promo del primo anno. Registry come Donuts/Identity Digital applicano tier pricing su molti new gTLD: un dominio apparentemente generico può essere classificato premium e costare 10-100× il prezzo standard.

Risoluzione DNS: come il nome diventa un IP

La traduzione da FQDN a indirizzo IP (IPv4 o IPv6) è un processo distribuito che coinvolge tre classi di server DNS e un meccanismo di caching multi-livello. Per una trattazione completa del DNS rimando alla guida Cos’è il DNS e come funziona; qui riassumo il flusso di una query ricorsiva dall’inizio alla fine.

1. Stub resolver (libreria di sistema nel client) invia una query al recursive resolver configurato (DHCP, statico o DoH/DoT: 1.1.1.1, 8.8.8.8, 9.9.9.9).
2. Recursive resolver verifica la cache locale. Cache miss → avvia la risoluzione iterativa.
3. Query ai root server (.) → risposta con i NS authoritative del TLD richiesto (es. a.gtld-servers.net per .com).
4. Query ai TLD server → risposta con i NS authoritative della zona (es. i name server pubblicati dal registrant per evemilano.com).
5. Query agli authoritative NS della zona → risposta con il record finale (A, AAAA, CNAME, ecc.).
6. Il recursive resolver mette in cache la risposta rispettando il TTL dichiarato e la restituisce allo stub resolver.

L’intero processo, dopo il primo miss, è accelerato dal caching: risoluzioni successive di nomi già interrogati avvengono dal recursive resolver in pochi millisecondi. Le modifiche ai record DNS si propagano quindi non istantaneamente ma entro il TTL configurato (tipicamente 300-86400 secondi). Per migrazioni pianificate è best practice abbassare il TTL a 60-300s nelle 24-48 ore precedenti al cutover.

DNSSEC e integrità della catena

DNSSEC (DNS Security Extensions, RFC 4033-4035) estende il protocollo con firme crittografiche per garantire autenticità e integrità delle risposte. Richiede coordinamento tra registry, registrar e DNS hosting: il record DS pubblicato nella zona del TLD contiene l’hash della chiave DNSKEY dell’authoritative, creando una chain of trust dalla root alla zona foglia. Senza DNSSEC, attacchi di tipo cache poisoning e man-in-the-middle DNS restano tecnicamente possibili.

Record DNS essenziali: A, AAAA, CNAME, MX, NS, SOA, TXT, CAA

La zona authoritative di un dominio contiene un insieme di Resource Record (RR) che definiscono il comportamento del dominio. Ogni RR è una tupla (name, class, type, TTL, rdata). Riepilogo dei tipi che un SEO o un sysadmin incontra quotidianamente.

Record	RFC	Funzione
A	RFC 1035	Mappa un nome a un indirizzo IPv4 a 32 bit.
AAAA	RFC 3596	Mappa un nome a un indirizzo IPv6 a 128 bit.
CNAME	RFC 1035	Alias canonico verso un altro nome. Non convivibile con altri record sullo stesso nome. Vietato all’apex.
NS	RFC 1035	Delega l’autorità di una zona ad un name server.
SOA	RFC 1035	Start of Authority — metadati della zona (master NS, email admin, serial, refresh, retry, expire, minimum TTL).
MX	RFC 1035, RFC 7505	Mail eXchanger — priorità + FQDN dei server email entranti.
TXT	RFC 1035	Testo libero. Usato per SPF, DKIM, DMARC, domain verification (Google, Microsoft, ecc.), proof of ownership.
CAA	RFC 8659	Certificate Authority Authorization — limita quali CA possono emettere certificati TLS per il dominio.
SRV	RFC 2782	Service location (XMPP, SIP, Kerberos, LDAP).
PTR	RFC 1035	Reverse DNS: IP → nome. Pubblicato nella zona in-addr.arpa o ip6.arpa.
DS, DNSKEY, RRSIG, NSEC/NSEC3	RFC 4033-4035	Infrastruttura DNSSEC.
HTTPS, SVCB	RFC 9460	Service Binding — permette signaling di HTTPS/QUIC, ALPN, ECH al resolver prima della connessione.

Per debugging operativo usare dig (preferibile) o nslookup. Esempio di interrogazione authoritative e tracing completo:

dig evemilano.com A +short
dig evemilano.com NS +short
dig evemilano.com MX +short
dig +trace evemilano.com
dig @1.1.1.1 evemilano.com ANY
dig evemilano.com CAA
dig evemilano.com TXT
dig +dnssec evemilano.com DS

WHOIS e RDAP: chi possiede un dominio dopo il GDPR

WHOIS (RFC 3912) è il protocollo storico di interrogazione sui dati di registrazione. Dal maggio 2018, con l’entrata in vigore del GDPR, ICANN ha imposto ai registrar europei (e nella pratica a tutti, per uniformità operativa) la redazione dei dati personali del registrant dalle risposte WHOIS pubbliche. Si leggono normalmente solo registrar, date (created, updated, expires), NS, stato EPP e un contatto generico (spesso via form).

RDAP (Registration Data Access Protocol, RFC 7480-7484 e 9082-9083) è il successore moderno di WHOIS. Differenze chiave:

• Output strutturato in JSON, parsabile programmaticamente senza regex fragili sul testo libero WHOIS.
• Transport HTTPS con autenticazione e rate limiting standardizzati.
• Supporto nativo per accesso differenziato (tiered access): utenti autenticati (law enforcement, proprietari IP) possono ottenere dati non redatti.
• Internazionalizzazione: supporto UTF-8 e IDN.

Dal gennaio 2025 ICANN ha reso RDAP il protocollo obbligatorio per tutti i gTLD (consultazione via rdap.org o bootstrap IANA). WHOIS sopravvive per ccTLD legacy e per tool di interrogazione che fanno da wrapper. Esempio di query RDAP:

curl -s https://rdap.verisign.com/com/v1/domain/evemilano.com | jq .
curl -s https://rdap.org/domain/example.com | jq '.events'

Sottodomini vs sottocartelle: implicazioni SEO e tecniche

La scelta tra blog.example.com (sottodominio) e example.com/blog/ (sottocartella) è una delle decisioni architetturali che torna ciclicamente in qualsiasi migrazione o lancio. Google ha dichiarato più volte (John Mueller, public Office Hours) che entrambe le soluzioni sono trattate in modo equivalente dal punto di vista del ranking, purché correttamente configurate. La decisione va presa sugli altri fattori tecnici e organizzativi.

Dimensione	Sottodominio	Sottocartella
Consolidamento segnali SEO (link equity, brand authority)	Parziale — Google tratta il sottodominio come host distinto nei suoi indici	Totale — stesso host, segnali condivisi al 100%
Cookie scope (default, senza Domain= esplicito)	Isolato per host	Condiviso con il dominio principale
Same-origin policy (CORS, localStorage, ServiceWorker)	Origin diversa — serve CORS esplicito	Stessa origin
Certificato TLS	Richiede SAN aggiuntivo o wildcard (*.example.com)	Nessun setup aggiuntivo
Infrastruttura/hosting separati (es. SaaS per blog, Shopify per shop)	Facile: NS o A/CNAME dedicati	Difficile: richiede reverse proxy
Internazionalizzazione (de.example.com vs example.com/de/)	Isolamento chiaro, configurazione server semplice	Consolidamento sul dominio principale
Crawl budget e discovery	Ogni host ha il proprio robots.txt e la propria sitemap	Unico perimetro di crawling

Raccomandazione operativa: in assenza di vincoli tecnici specifici (stack SaaS separati, blog gestito da team/tecnologia diversa, isolamento di sicurezza), la sottocartella è la scelta di default per ragioni di consolidamento dei segnali e semplicità di gestione. Il sottodominio resta giustificato quando l’isolamento infrastrutturale, di autenticazione o di sicurezza pesa più del consolidamento SEO.

Per il tracking di sottodomini distinti con un unico account GA4 vedi Monitorare i sottodomini con un solo account Google Analytics.

IDN e punycode: domini internazionalizzati e homograph attack

Il DNS a livello protocollare accetta solo ASCII (LDH rule). Per supportare caratteri Unicode — alfabeti cirillici, CJK, accenti, lettere greche — la specifica IDNA2008 (RFC 5890-5895) definisce un meccanismo di transcodifica: la label Unicode viene convertita in una stringa ASCII-compatibile tramite Punycode (RFC 3492) con prefisso xn--.

Forma Unicode (U-label)	Forma ASCII Punycode (A-label)
café.com	xn--caf-dma.com
münchen.de	xn--mnchen-3ya.de
中国.cn	xn--fiqs8s.cn
рф (TLD)	xn--p1ai

La conversione è deterministica e reversibile. Browser e OS moderni gestiscono la rappresentazione visuale: la barra URL mostra la U-label quando la lingua del dominio è coerente con la locale dell’utente, la A-label altrimenti (mitigazione base degli homograph attack).

Homograph attack: il rischio degli IDN

Caratteri di alfabeti diversi possono essere visivamente identici (confusable characters): la a latina (U+0061), la а cirillica (U+0430) e la α greca (U+03B1) sono indistinguibili a occhio ma producono FQDN completamente diversi. Un attaccante può registrare xn--pypl-53d.com (che appare come paypal.com con una а cirillica) per attacchi di phishing. Browser moderni applicano heuristics anti-homograph (stessa script Unicode, whitelist di TLD) e mostrano la A-label nei casi ambigui.

Implicazioni SEO: gli IDN sono indicizzabili e rankabili, ma Google Search Console, molti tool di terze parti e vari reporting interni rappresentano i domini in forma punycode. Quando si lavora con IDN è fondamentale tenere conto della doppia rappresentazione per evitare discrepanze nei dati.

Checklist operativa per la scelta di un dominio professionale

La decisione di registrazione di un dominio ha impatti pluriennali e costi di reversibilità alti (migrazione SEO, rebrand, redirect permanenti, aggiornamento link building). Questa checklist condensa i controlli che applico prima di consigliare un dominio in contesto consulenziale — sia per nuove registrazioni sia per acquisizioni aftermarket.

Verifica legale e reputazionale

• Ricerca marchi registrati (UIBM, EUIPO, USPTO, WIPO Global Brand Database) per conflitti con trademark attivi.
• Verifica storia del dominio via Wayback Machine e Web Archive per identificare usi pregressi potenzialmente tossici.
• Controllo backlink profile con tool specialistici (Ahrefs, Majestic, Semrush) per rilevare profili spam o penalizzazioni residue.
• Verifica blacklist pubbliche (Spamhaus, URIBL, SURBL) e safe browsing status (Google Safe Browsing, VirusTotal).

Verifica tecnica

• Lunghezza ragionevole (≤15 caratteri per SLD) e assenza di trattini multipli — riducono typo rate e migliorano memorabilità.
• Assenza di numeri o caratteri che generano ambiguità fonetica (zero/O, uno/l/I).
• Registrazione difensiva delle varianti typo-squatting principali e dei TLD correlati (almeno .com se si registra un ccTLD principale).
• Verifica prezzo di rinnovo (non solo promo primo anno) e assenza di tier pricing premium sul TLD scelto.
• Valutazione del registry di destinazione: stabilità finanziaria, policy di rinnovo, track record (alcuni new gTLD hanno avuto aumenti di prezzo retroattivi del 100-400%).

Setup post-registrazione

• Abilitare Registrar Lock (clientTransferProhibited) per bloccare transfer non autorizzati.
• Attivare 2FA sull’account registrar — è il single point of failure più frequentemente attaccato.
• Impostare auto-renew e monitorare le scadenze con almeno due canali indipendenti (email + calendar).
• Pubblicare record CAA per vincolare le CA autorizzate a emettere certificati TLS.
• Valutare attivazione di DNSSEC (richiede DNS provider compatibile e configurazione DS record presso il registrar).
• Configurare record SPF, DKIM, DMARC anche se il dominio non invia email — blocca spoofing in outbound.
• Se si tratta di dominio per un progetto esistente, pianificare redirect 301 e migrazione SEO completa con mapping URL 1-a-1.

Protezione della registrazione nel tempo

• Registrazione pluriennale (3-10 anni) quando possibile: segnale positivo a terze parti e riduzione rischio mancato rinnovo.
• Intestazione a entità stabile (persona giuridica meglio di persona fisica volatile).
• Dati di contatto WHOIS/RDAP accurati e monitorati — email di contatto sul dominio stesso è rischioso se il dominio scade.
• Per domini business-critical: valutare servizi di premium DNS (Cloudflare, NS1, Dyn) con Anycast multi-region, DDoS protection e SLA contrattuali.

Conclusione

Padroneggiare la struttura dei domini — TLD, SLD, sottodomini, record DNS, lifecycle — non è un esercizio accademico: impatta direttamente decisioni di migrazione, gestione multi-country, architettura tecnica, sicurezza perimetrale e continuità operativa. Le scelte prese al momento della registrazione hanno conseguenze che durano anni e sono spesso costose da invertire. Un approccio rigoroso, basato su specifiche ufficiali e non su divulgazione semplificata, è la base per qualsiasi strategia infrastrutturale seria.