Stai configurando il DNS del sito aziendale e ti chiedono di inserire il nome completo del server: `www.impresa.it` può bastare, ma in certi campi serve una forma più esplicita. FQDN significa *Fully Qualified Domain Name*, cioè nome di dominio completo; per capire se lo è davvero bisogna considerare anche la radice della gerarchia DNS.
Un FQDN identifica un nome completo nella gerarchia DNS
- Struttura: hostname, eventuali sottodomini e dominio di primo livello, come `www.negozio.it`.
- Punto finale: nella notazione DNS completa indica la radice, anche se spesso viene omesso nell’uso quotidiano.
- Risoluzione: il nome può portare a più indirizzi IP o a un alias, quindi non identifica necessariamente un solo server fisico.
- Certificati TLS: il nome usato dal servizio deve corrispondere a quello indicato nel certificato.
Da `www.negozio.it` alla radice, ogni etichetta completa il nome
In `www.negozio.it`, le parti separate dai punti sono le etichette DNS: `www` indica spesso un host o un servizio, `negozio` identifica il dominio registrato e `.it` è il dominio di primo livello. L’FQDN raccoglie le etichette necessarie a collocare quel nome nella gerarchia DNS.
La sigla non impone che il nome inizi con `www`. Anche `negozio.it` può essere un FQDN; `api.negozio.it` può identificare un servizio distinto. A dire il vero, questa distinzione aiuta a evitare un errore comune: `www` è una scelta di configurazione, non una parte obbligatoria del nome completo.
Il punto finale rende esplicita la radice DNS
La forma `www.negozio.it.` termina con un punto perché include anche la radice DNS, rappresentata da un’etichetta vuota. La RFC 1034 distingue così un nome assoluto, completo, da un nome relativo che un resolver può completare usando il dominio di ricerca locale.
Nel browser e in molti strumenti il punto finale viene omesso per comodità; nei file di zona DNS può invece evitare interpretazioni sbagliate. Per esempio, un record scritto come `api` può essere completato con il nome della zona, mentre `api.negozio.it.` è già assoluto. In una configurazione DNS, quindi, quel piccolo punto può cambiare il nome cercato.
Un nome breve può ricevere il suffisso della rete aziendale
Se digiti `stampante` e il computer trova `stampante.sede.negozio.it`, il resolver potrebbe aver aggiunto un suffisso di ricerca DNS configurato nella rete. È utile per i nomi interni, ma rende ambigua una diagnosi fatta solo guardando ciò che è stato digitato.
| Situazione | Possibile causa | Cosa fare |
|---|---|---|
| Il nome breve funziona solo in ufficio | La rete aggiunge un suffisso DNS interno | Verifica il nome completo assegnato al servizio e prova la risoluzione tramite DNS aziendale. |
| Il nome completo non restituisce un indirizzo | Manca un record DNS o si sta interrogando il resolver sbagliato | Controlla il record e interroga il server DNS autorevole o quello previsto dalla rete. |
| Il sito risponde, ma il browser segnala un errore TLS | Il nome richiesto non corrisponde a quello coperto dal certificato | Confronta il nome nella barra del browser con i nomi elencati nel certificato. |
Per distinguere il nome inserito da quello che il resolver sta effettivamente cercando, puoi usare `nslookup api.negozio.it` oppure `dig api.negozio.it.`. Il punto finale in `dig` chiede il nome assoluto e impedisce che venga completato con un suffisso locale; se il problema riguarda una rete interna, però, il test va eseguito con il DNS aziendale.
I limiti DNS contano quando generi nomi per servizi e dispositivi
Un nome può sembrare leggibile e restare comunque troppo lungo per il DNS. La RFC 1035 fissa un limite di 63 ottetti per etichetta e di 255 ottetti per il nome DNS codificato; quest’ultimo conteggio include anche i byte che descrivono la lunghezza delle etichette.
Perciò un nome costruito automaticamente concatenando reparto, sede, ambiente e identificativo del servizio può superare il limite anche se ogni singola parte sembra accettabile. Nei sistemi aziendali conviene definire uno schema compatto prima di distribuire nomi a server, API e dispositivi: rinominare un host dopo averlo inserito in DNS, monitoraggio e certificati richiede aggiornamenti coordinati.
Il certificato deve coprire lo stesso nome usato dal servizio
Un server può risolvere correttamente nel DNS e mostrare comunque un avviso di sicurezza. Succede, per esempio, quando il browser apre `portale.negozio.it`, ma il certificato è valido solo per `negozio.it`: per la connessione TLS sono due nomi distinti.
La RFC 9525 indica di verificare i nomi DNS del servizio tramite l’estensione Subject Alternative Name (SAN), nel campo `dNSName`; il vecchio `Common Name` non basta per identificare il servizio secondo questa specifica. Quando si pubblicano indirizzi diversi per sito, API e posta, ciascun nome usato dai client deve essere coperto dal certificato appropriato.
Per le configurazioni aziendali, annota sempre il nome completo
Io terrei distinti nei documenti interni il nome breve del dispositivo, il suo FQDN e l’indirizzo del servizio. Così un collega può capire subito se `gestionale` è un’etichetta locale, `gestionale.sede.negozio.it` è il nome DNS completo o se il client deve connettersi a un endpoint diverso.
Quando un’applicazione richiede un FQDN, inserisci il nome completo previsto dal DNS e verifica che risolva dalla rete in cui verrà usato. Se il collegamento è protetto da TLS, controlla anche che lo stesso nome compaia nel SAN del certificato: è il passaggio che evita che DNS e browser sembrino contraddirsi.