Impostare correttamente le impostazioni DNS di Hetzner - esempio di configurazione con hetzner dns configuration

Configurazione del DNS di Hetzner in modo che il sito web, i sottodomini e la posta elettronica funzionino senza interruzioni e che le modifiche abbiano effetto rapidamente. In questa guida vi mostro le impostazioni necessarie nel DNS di Hetzner, un esempio di configurazione collaudata e metodi di test pratici per evitare errori in anticipo e mantenere la zona pulita.

Punti centrali

I seguenti punti chiave forniranno una rapida panoramica di ciò che è importante per una zona DNS affidabile.

• Nameserver inserire correttamente con il registrar
• A/AAAA per il Web, MX/TXT per la posta
• TTL Selezionare in modo appropriato e attendere la propagazione
• SPF/DKIM contro lo spam e lo spoofing
• Monitoraggio e test dopo le modifiche

Il DNS in breve: ciò che serve davvero

Assegno un dominio tramite Registrazioni destinazioni specifiche, in modo che i browser e i server di posta possano trovare i miei servizi. A Record A punta a un indirizzo IPv4, un AAAA a un IPv6 e un MX definisce la consegna delle e-mail. Un CNAME forma un alias che punta a un nome diverso, mentre un TXT contiene informazioni per SPF o verifiche. Una linea di base pulita consiste in A/AAA per il dominio principale, CNAME per il www, MX per la posta e un SPF-TXT. In questo modo mantengo la zona chiara, rapidamente manutenibile e aperta a estensioni successive.

Aggiungere il dominio alla console DNS di Hetzner

Nella console DNS, creo prima un nuovo file Zona e controllo che l'ortografia del dominio sia esattamente corretta. Poi attivo il mantenimento manuale di Registrazioniin modo da poter creare e modificare voci specifiche. Suggerimento: prendo nota degli indirizzi IP e delle destinazioni di posta elettronica in anticipo, in modo da poter inserire tutto senza interruzioni. In questo modo evito errori di battitura e imposto le voci in ordine sparso. Non appena la zona è pronta, pianifico il cambio dei server dei nomi e i controlli successivi.

Inserire correttamente il server dei nomi con la società di registrazione

Dopo aver creato la zona, si inserisce il comando Nameserver di Hetzner, in modo che l'amministrazione sia centralizzata nella console DNS. Le voci abituali sono ns1.first-ns.de, robotns2.second-ns.de e robotns3.second-ns.com. Per i domini .de o .at, ho configurato i miei server di nomi con Registrazioni a collain modo da memorizzare i riferimenti e gli IP. Se non l'avete mai fatto prima, potete trovare i singoli passaggi nella guida a Impostazione dei registri della colla. Poi mi prendo un po' di tempo per il passaggio, dato che l'aggiornamento può arrivare a velocità diverse in tutto il mondo.

Esempio di configurazione: rendere eseguibili il sito web e la posta elettronica

Per una tipica presenza sul web utilizzo un Record A per il dominio principale, un CNAME per www e record di posta adeguati. Un SPF-TXT impedisce ai server esterni di inviare e-mail con il nome del dominio. Facoltativamente, aggiungo un record AAAA se il web server IPv6 fornisce. Per i servizi di posta esterni, come ForwardMX, personalizzo gli MX e ne memorizzo le specifiche. La tabella seguente mostra un solido punto di partenza per molte configurazioni.

Nome	Tipo	Valore	Suggerimento
@	A	195.201.210.43	Server web IPv4
@	AAAA	Facoltativo: 2a01:4f8:xxxx:xxxx::1	Server web IPv6
www	CNAME	@	Alias su root
@	MX	mx1.forwardmx.net	Prio 10
@	TXT	"v=spf1 include:_spf.forwardmx.net -all"	SPF contro lo spoofing

Attivare il protocollo DNSSEC e impostare il record DS

Se per me la sicurezza della manipolazione è importante, attivo DNSSEC per la zona. Nella console di Hetzner, genero le chiavi di firma per questo e poi ricevo la necessaria Dati DSche deposito presso la società di registrazione. Verifico che l'algoritmo e il digest siano stati trasferiti correttamente. Attendo quindi che la catena dalla società di registrazione alla zona venga convalidata correttamente. Prima di importanti rotazioni di chiavi, abbasso il TTL e pianifico una finestra temporale in modo che i risolutori vedano le nuove firme in tempo utile. Importante: se si verifica un errore durante la modifica, le convalide falliscono per i destinatari; per questo motivo ho pronto un rollback (non cancellare le vecchie chiavi troppo presto) e faccio un test con i resolver di convalida.

Impostare correttamente il TTL e comprendere la propagazione

Il sito TTL determina la durata della cache dei resolver per una voce. Per le conversioni, scelgo un tempo breve TTL (ad esempio 300 secondi) in modo che le modifiche siano visibili rapidamente. Dopo la configurazione finale, aumento nuovamente i valori per risparmiare richieste e ottenere una risoluzione coerente. Coloro che effettuano distribuzioni frequenti preferiscono attenersi a 600-1200 secondi, mentre coloro che effettuano modifiche raramente utilizzano 3600-14400. Una panoramica pratica della decisione è fornita dal mio sguardo al Selezione TTL ottimale.

Dominio Apex, CAA e certificati sotto controllo

Per gli obiettivi SaaS su Zona Apex Ricordo che CNAME non è consentito su @. Pertanto, utilizzo l'A/AAA del provider o imposto un reindirizzamento a www a livello di server web. Per l'assegnazione del certificato controllo con Record CAAquali CA sono autorizzate a emettere certificati. Ad esempio, mantengo solo la CA che uso effettivamente e aggiungo facoltativamente un indirizzo di posta per le segnalazioni. Se cambio la CA, aumento brevemente il TTL e aggiorno la CAA prima di emettere il certificato. Per quanto riguarda i caratteri jolly tramite ACME DNS-01, mi assicuro che i record TXT sotto _acme-challenge possono essere impostati rapidamente e ripuliti automaticamente, in modo che non rimangano vecchie sfide.

Creare sottodomini e servizi in modo pulito

Per ogni sottodominio creo un apposito A- o CNAME-a seconda che il sottodominio punti direttamente a un IP o a un nome. Esempio: blog.example.de come record A per la VM del blog, cdn.example.de come CNAME per un nome CDN. Per le API, faccio una distinzione rigorosa tra nomi interni e pubblici per evitare rischi. Nomi standardizzati come api, app, img aiutano la manutenzione e il monitoraggio. In questo modo, mantengo la zona strutturata e posso assegnare chiaramente le modifiche.

Caratteri jolly, SRV e tipi di record speciali

Uso Wildcard Records (*.example.de), ad esempio per le configurazioni con più client. Mi assicuro che le voci esatte abbiano sempre la precedenza sui caratteri jolly. Per i servizi come SIP, Matrix o Autodiscover, creo Registri SRV e controllare il formato e le priorità. Registrazioni TXT con contenuti lunghi (ad esempio, DKIM a 2048 bit) sono suddivisi in diversi segmenti di quote, in modo che i parser possano unirli correttamente. Evito i record SPF multipli e combino le voci in un SPF valido per non infrangere il limite di ricerca.

Consegna affidabile delle e-mail: SPF, DKIM e DMARC

Per la posta elettronica di fiducia, utilizzo la funzione MX un SPF-TXT pulito che copra i miei sistemi di invio. Attivo anche DKIM al servizio di posta utilizzato e pubblicare il selettore DKIM come TXT sotto selector._domainkey. Utilizzo il DMARC per definire il modo in cui i destinatari gestiscono le e-mail che non superano SPF/DKIM. Spesso inizio con "p=none", valuto le segnalazioni e successivamente passo a "quarantena" o "rifiuto". Questa sequenza riduce i rischi e aumenta gradualmente la qualità della consegna.

Approfondire SPF/DKIM/DMARC nella pratica

Mantengo l'SPF il più possibile ridotto: solo il necessario. includere-e mai più di un SPF per hostname. Per rispettare il limite dei 10 lookup DNS, riduco le catene o utilizzo i meccanismi IP4/IP6 se sono stabili. Per Rotazione DKIM Gestisco due selettori attivi (vecchio/nuovo), pubblico la nuova chiave, cambio il servizio di posta e cancello quella vecchia solo dopo qualche giorno. Con DMARC Inizialmente imposto gli indirizzi di segnalazione (rua/ruf) e controllo l'allineamento (aspf/adkim). Per i sottodomini posso usare sp= definire una politica separata se inviano separatamente. In questo modo reagisco ai dati di traffico reali invece che alle ipotesi.

DNS inverso (PTR) per la consegna della posta pulita

Oltre a MX, SPF e DKIM, ho configurato DNS inverso (PTR) per i server di posta in uscita. Il PTR dell'IP punta a un nome host, che a sua volta si risolve correttamente allo stesso IP tramite A/AAAA (Corrispondenza avanti/indietro). Imposto il PTR per IP direttamente con il proprietario dell'IP (ad esempio nell'interfaccia del server), non nella gestione delle zone del dominio. Utilizzo il formato nibble per IPv6. Un PTR adeguato riduce le classificazioni dello spam e aiuta la reputazione. Se la posta viene inviata tramite un servizio esterno, lascio il suo PTR così com'è ed evito fonti mittenti miste senza personalizzazione SPF.

Errori tipici e soluzioni rapide

Se un dominio non si risolve, controllo innanzitutto TTLle voci del server dei nomi e l'ortografia corretta dei record. Il secondo sguardo va al PropagazioneAlcuni resolver effettuano una cache più lunga, soprattutto dopo l'aumento del TTL. Confronto la risoluzione utilizzando diversi DNS checker per riconoscere le differenze regionali. In caso di problemi locali, passo temporaneamente a resolver pubblici come 1.1.1.1 o 8.8.8.8. Se l'errore si verifica solo nelle reti interne, controllo i resolver interni e le regole delle configurazioni dei container, di Kubernetes o di CoreDNS.

Metodi di test: dig, nslookup e end-to-end

Non mi limito a testare i record, ma l'intero percorso:

• scavare A/AAAA/CNAME/MX/TXT: controllo delle risposte, TTL e autorità
• scava +tracciaVedere catena di delegazione e comportamento del server dei nomi
• Test SMTPControllare HELO/EHLO, TLS e banner
• HTTPS realeCatena di certificati, nome host, reindirizzamenti

In questo modo, riconosco anche gli errori che non sono visibili nelle risposte DNS pure, come ad esempio mappature di VirtualHost errate o certificati in scadenza. Dopo aver apportato le modifiche, attendo almeno un TTL prima di trarre conclusioni definitive.

Lavorare in modo efficiente con la console Hetzner

Raggruppamento di elementi correlati Entrate tempo, imposto un breve TTL prima di apportare modifiche importanti e poi pubblico tutto in una volta sola. Prima di salvare, controllo di nuovo MX-priorità, la sintassi SPF e l'IP di destinazione del record A. Per l'amministrazione e i processi del server, le istruzioni compatte a Suggerimenti per i robot Hetzner. Dopo le implementazioni, verifico http, https e mail con richieste reali, non solo tramite ping. Questo mi permette di riconoscere gli errori che le semplici query DNS non mostrano.

Automazione: API, modelli e ACME

Risparmio tempo grazie all'automazione. Per le distribuzioni regolari, uso il metodo API della console DNS per creare, modificare o eliminare i record. Lavoro con i modelli per gli schemi ricorrenti (ad esempio, Web + Mail + DMARC) e inserisco solo i valori specifici del progetto. Per Let's Encrypt DNS-01, includo una scrittura automatica di record TXT e la integro nel flusso di lavoro di rinnovo. Importante: tratto i token API come password, li assegno a progetti specifici e revoco l'accesso quando non sono più necessari.

Configurazioni avanzate: Split-Horizon, CDN e ACME

Se necessario, separo gli utenti interni da quelli esterni DNS-in modo che l'applicazione interna punti a IP privati e i visitatori a destinazioni pubbliche. Devo utilizzare un CDNRiferisco i sottodomini al nome del CDN tramite CNAME e attivo il TLS. Per i certificati automatici tramite ACME/Let's Encrypt, imposto facoltativamente le sfide DNS-01 tramite TXT se HTTP-01 non corrisponde. L'automazione è importante in questo caso, in modo che i rinnovi avvengano in tempo utile. I registri e le notifiche aiutano a riconoscere tempestivamente gli errori.

Modelli di prestazioni e disponibilità

Aumento la disponibilità con mezzi semplici: Diversi Registri A/AAAA (round robin) condividono il carico senza servizi aggiuntivi, a condizione che i backend siano stateless o condividano sessioni. Durante la manutenzione, rimuovo temporaneamente singoli IP e poi rilancio la voce. Un TTL troppo breve può mettere a dura prova i resolver; trovo un equilibrio tra la velocità di risposta e la frequenza di accesso alla cache. Impostiamo processi chiari per i failover senza controlli sullo stato di salute: In caso di guasto, scambio le voci, le monitoro attivamente e le ripristino dopo il ripristino.

Sicurezza e igiene della zona

Disattivazione di un'attività non necessaria Trasferimenti di zona (AXFR) e pubblicare solo il NSche sono veramente autorevoli. Elimino regolarmente i sottodomini vecchi o orfani, in modo che non si creino superfici d'ombra. Per gli IDN, controllo il Punycode-per evitare errori di battitura e di caratteri speciali. L'accesso alla console basato sui ruoli assicura che solo le persone giuste modifichino le zone. E in modo molto pragmatico: documento brevemente le modifiche nello strumento del team, riducendo in modo significativo le interrogazioni durante le operazioni.

Strategia di migrazione e rollback

Prima di un trasloco, abbasso il TTL (24-48 ore prima), specchio tutte le Registrazioni nella nuova zona e verificare la risoluzione direttamente tramite i nuovi server dei nomi. Solo quando tutto è corretto, imposto il parametro Nameserver presso la società di registrazione. Dopo la delega, monitoro il traffico e gli errori. Se qualcosa va storto, eseguo un rollback controllato o correggo singole voci. Pianifico le migrazioni DNSSEC in modo particolarmente conservativo e lascio la vecchia catena di firme fino a quando la nuova non è stata installata in modo sicuro. Infine, ripristino il TTL a valori conformi alla produzione.

Breve confronto tra i fornitori per prestazioni e flessibilità

Prestazioni, funzioni e Libertà DNS decidere con quanta flessibilità realizzare i progetti. In pratica, i grandi hoster forniscono un solido Tempi di rispostama differiscono in termini di funzionamento, caratteristiche e supporto. Valuto la scelta in base alle prestazioni, alla gamma di funzioni, alla qualità dell'assistenza e alle opzioni DNS. La seguente panoramica mostra un quadro sintetico che posso utilizzare per prendere decisioni. Alla fine conta ciò di cui il mio progetto ha realmente bisogno, non l'elenco di funzionalità più ampio.

Fornitore	Prestazioni	Portata delle funzioni	Supporto	Flessibilità del DNS	Classifica
webhoster.de	Alto	Molto esteso	In alto	Massimo	1
Hetzner	Alto	Ampio	Buono	Alto	2
Contabo	Medio	Standard	O. K.	Medio	3

Riassumendo brevemente

Ho impostato un Hetzner DNS-zona in modo strutturato: Creare la zona, inserire il server dei nomi con la società di registrazione, impostare i record principali per il web e la posta, quindi eseguire il test. Con un'adeguata TTL Accorcio i tempi di cambio e li aumento di nuovo dopo il completamento per ridurre il carico. SPF, DKIM e DMARC rafforzano la consegna e proteggono il dominio dagli abusi. Mantengo la coerenza dei sottodomini e separo le destinazioni interne da quelle pubbliche. Con questa configurazione di esempio e i controlli quotidiani, la vostra configurazione hetzner dns rimane affidabile, veloce e facile da mantenere.