Risoluzione dei comuni errori di misconfigurazione DNS

DNS (sistema dei nomi di dominio) potrebbe non essere conosciuto dalla maggior parte delle persone che usano Internet, ma è la vera forza invisibile che guida Internet, senza la quale tutti vedrebbero numeri e IP. Il significato stesso dei nomi di dominio esiste oggi solo grazie al DNS.

Introduzione

Il modo più semplice per spiegare il DNS in una riga è mappare il nome di dominio all’indirizzo IP. Non sono sicuro di quanti sappiano che quando qualcuno digita un nome di dominio in IE/firefox, il browser inoltra la richiesta DNS chiedendo l’indirizzo IP al risolutore dell’ISP (fornitore di servizi Internet) e il risolutore contatta i server root e poi recupera sistematicamente l’indirizzo IP in pochi millisecondi.

Comprendere il DNS e il suo funzionamento è uno dei soggetti più difficili dell’ingegneria informatica eppure molti amministratori di rete esperti faticano su questo argomento quando si tratta di scrivere file di zona DNS.

Prima di procedere con questo articolo, i seguenti sono i punti più importanti che dovresti ricordare, altrimenti non capirai nulla.

Punti da ricordare

Un record A deve SEMPRE contenere l’indirizzo IP (mappa host a IP)

Ogni volta che specifichi un record A, deve contenere l’indirizzo IP sul lato destro. Il record A è così importante nel DNS, senza il quale il significato di mappare i nomi host a IP sarebbe assurdo. Quindi ricorda questo!

CNAME (Alias) deve contenere nomi host. Nessun IP qui
I record NS e MX devono contenere nomi host. Nessun IP consentito.
Usa il PUNTO alla fine, ogni volta che specifichi un nome di dominio nel file di zona DNS. Questo PUNTO è così importante e se lo dimentichi avrai incubi con la tua configurazione DNS.

Ad esempio

example.com. IN NS ns1.example.com.

Perché il PUNTO? semplicemente perché indica di iniziare la query dai server root (denotati dal punto)

I record MX (per i server di posta) devono contenere nomi host NON IP.

Termini comuni del DNS e i loro significati

(i) Record Glue

I record glue sono record A associati ai record NS per fornire informazioni di “bootstrap” ai nomi server dei record NS. (vedi RFC 1912 sezione 2.3)

domain.com. IN NS ns1.domain.com. domain.com. IN NS ns2.domain.com.

ns1 IN A 11.33.55.77 ns2 IN A 22.44.66.88

Nell’esempio sopra stiamo mappando ciascun record NS all’indirizzo IP (record A) legando così i nameserver all’IP (cioè incollandoli).

(ii) Delegazione di Nameserver LAME

Un nameserver che fornisce una risposta non autorevole è solitamente chiamato ‘LAME’. Ogni dominio deve avere almeno 2 nameserver e se chiedo a ciascuno di essi, e se hanno informazioni sulla zona del dominio, riceverò una risposta autorevole. Se no, è una ‘delegazione lame’. Riferirsi a RFC 1912 sezione 2.8.

Un esempio di delegazione lame è

domain.com IN NS ns1.domain.com domain.com IN NS ns2.example-server.net

ns1.domain.com è configurato per avere informazioni sulla zona del dominio, ma ns2.exserver.net non è stato configurato correttamente e non ha alcuna informazione sul dominio. Quindi ns1 risponderà in modo autorevole mentre ns2 non lo farà, il che sarà ‘lame’ finché non sarà configurato correttamente.

Per ottenere una comprensione più approfondita, utilizziamo lo strumento dig per example.com.

Prima troviamo i nameserver di example.com:

 dig example.com NS

;; SEZIONE RISPOSTA: example.com. 158240 IN NS a.iana-servers.net. example.com. 158240 IN NS b.iana-servers.net.

Poiché abbiamo ricevuto 2 nameserver, chiediamo a ciascuno di essi se forniscono una risposta autorevole. Se è autorevole, il flag ‘aa’ nell’intestazione sarà impostato nella risposta ricevuta (‘aa’ è risposta autorevole).

dig @b.iana-servers.net example.com NS
dig @a.iana-servers.net example.com NS

;; Ricevuta risposta:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60896
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; SEZIONE DOMANDA:
;example.com. IN NS

;; SEZIONE RISPOSTA:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.

Guarda nei flag.

flags: qr aa rd

Poiché ‘aa’ è impostato nella risposta, entrambi i nameserver di example.com forniscono una risposta autorevole. Se è una delegazione lame non otterrai la risposta autorevole.

ATTENZIONE:

Non dovresti usare CNAME (alias) insieme ai record NS e spesso confonde la maggior parte dei risolutori causando loop e spesso porta a ‘delegazione lame’.

domain.com IN NS ns1.domain.com. domain.com IN NS ns2.domain.com. domain.com In CNAME ns9.example-server.net

Quindi non usare mai CNAME insieme ai record NS.

(iii) Nameserver Stealth

I Nameserver Stealth (o nameserver nascosti) sono nameserver non corrispondenti/conflittuali che esistono a livello root contro i nameserver nel dominio.

Per illustrare questo, quando chiedo ai server genitori riguardo al tuo dominio per i record NS a livello root ottengo

ns0.domain.com ns2.domain.com ns3.domain.com

ma quando interrogo i nameserver del tuo dominio per i record NS non sono gli stessi e vengono come

ns0.domain.com ns2.domain.com ns.example-dns.net

Poiché ns.example-dns.net e ns3.domain.com sono nascosti, entrambi sono ‘nameserver stealth’. Anche se non c’è nulla di sbagliato in questo, è consigliabile non avere alcun nameserver stealth sia a livello root che nel tuo server DNS.

Puoi usare il comando dig per cercare i record NS a livello di server root.

 dig +trace @K.root-servers.net example.com NS

e per chiedere a uno dei nameserver del dominio.

 dig @ns0.domain.com example.com NS

Cerca eventuali discrepanze NS tra le due query. Se c’è un nameserver mancante a livello root, aggiungi il nameserver mancante al tuo registrar di dominio. Se il nameserver è mancante a livello di dominio, aggiungi il nameserver al file di zona del dominio e aggiorna tutti i tuoi nameserver secondari.

(iv) Server DNS aperto

Eseguire il server DNS ‘aperto’ è un grande rischio per la sicurezza poiché risponde a query ricorsive sia dall’interno che dall’esterno della tua rete. Significa che chiunque può interrogare il tuo server per l’indirizzo IP e il tuo server DNS risponderà loro.

Per illustrare questo, abbiamo due nameserver che eseguono bind per il dominio example.com.

ns1.example.com ns2.example.com

Chiediamo a ns1.example di risolvere il dominio esterno google.com e se otteniamo l’indirizzo IP (record A) nella sezione risposta, allora significa che è un ‘server DNS aperto’.

dig @ns1.example.com google.com
dig @ns2.example.com google.com

;; opzioni globali: printcmd
;; Ricevuta risposta:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12107
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; SEZIONE DOMANDA:
;google.com. IN A

;; Tempo di query: 32 msec

Poiché non c’è sezione RISPOSTA o indirizzo IP, entrambi i nameserver non costituiscono un server DNS aperto.

Se ti capita di eseguire bind8 o versioni successive, tutto ciò che devi fare è impostare ‘recursion no’ all’interno delle opzioni per disabilitare il server DNS che risponde a query ricorsive.

options {
….
recursion no;
}

(v) Trasferimenti di zona (richiesta AXFR)

I trasferimenti di zona vengono effettuati dai nameserver secondari per recuperare le informazioni più recenti e aggiornate sulla zona per il dominio dal nameserver master o primario. I trasferimenti di zona dovrebbero essere resi disponibili solo ai nameserver secondari e non al mondo aperto poiché rappresentano un grande rischio per la sicurezza e possono esporre gli interni della tua rete all’attaccante.

Per richiedere un trasferimento di zona per example.com, dobbiamo prima chiedere al nameserver master. Vedi l’esempio qui sotto con dig.

 dig @ns1.example.com example.com

Se vedi l’output con il file di zona completo, allora devi disabilitare il trasferimento di zona. Nella maggior parte dei casi vedrai connessione fallita o RIFIUTATA, il che significa che il trasferimento di zona non è consentito ed è una cosa buona.

Errori comuni del DNS nella scrittura del file di zona

1. Nessun CNAME che punta ai record NS

domain.com. IN NS ns1.domain.com. domain.com. IN NS ns2.domain.com. domain.com In CNAME ns9.example-server.net —–> SBAGLIATO

Posizionare CNAME insieme ai NS farà sì che tutti i nameserver falliscano e risulterà in una delegazione lame. Non farlo!

Riferirsi a RFC1912 2.4 e RFC2181 10.3.

2. Evitare di eseguire server DNS su IP nello stesso subnet (/24) o sullo stesso server.

Lo scopo principale del DNS è che i nameserver siano distribuiti su diverse posizioni geografiche in modo che se un DNS fallisce, l’altro funzionerebbe. Anche se è una pratica molto comune eseguire entrambi i nameserver sullo stesso server o subnet, non fornirebbe tolleranza ai guasti. Se il server fallisce, i tuoi nameserver falliranno e il tuo sito non si caricherà.

ns1 IN A 75.33.22.xx —–> stesso subnet /24 ns2 IN A 75.33.22.xx —–> stesso subnet /24

3. GLUE appropriato

Aggiungi sempre glue ai tuoi record NS agli indirizzi IP utilizzando il record A, altrimenti uno dei tuoi nameserver fallirà.

domain.com. IN NS ns1.domain.com. domain.com. IN NS ns2.domain.com.

ns1 IN A 1.2.3.4 —–> GLUE ns2 IN A 2.4.6.9 —–> GLUE

Riferirsi a RFC1912.

4. Nessun record MX duplicato

domain.com. IN MX mail.domain.com. domain.com. IN MX mail.domain.com —-> DUPLICATO

5. Consentire la porta 53 per connessioni UDP e TCP

Se utilizzi un firewall assicurati di non bloccare la porta 53 per le richieste DNS tcp e udp. Per impostazione predefinita, le ricerche DNS utilizzano il protocollo UDP mentre i trasferimenti di zona e le notifiche utilizzano il protocollo TCP della porta 53.

Porta 53 UDP = Richieste Dns Porta 53 TCP = Trasferimenti di zona

6. I CNAME non possono coesistere con gli host MX.

Non specificare CNAME o alias che puntano ai record MX.

domain.com. IN MX 10 mail.domain.com. mail IN CNAME domain.com. ———-> SBAGLIATO

Invece usa il record A per mappare direttamente all’indirizzo IP.

mail IN A 11.33.55.77 —> CORRETTO

Riferirsi a RFC1912.

7. I record MX non devono contenere indirizzi IP

domain.com. IN 10 MX mail.domain.com. —-> CORRETTO domain.com. IN 20 MX 11.22.33.44 —–> SBAGLIATO

Il modo corretto di farlo è incollare l’host mx al record A.

domain.com. IN MX 10 mail.domain.com. —–> CORRETTO mail IN A 11.33.55.77 ———-> CORRETTO

8. I record NS NON devono contenere indirizzi IP

Specifica sempre i nameserver per il tuo dominio con i record NS. Dovrebbe essere un nome e non un indirizzo IP.

domain.com. IN NS dns0.domain.com. —–> CORRETTO domain.com. IN NS 75.xx.xx.xx ———–> SBAGLIATO

DNS INVERSE PER LA CONSEGNA DELLA POSTA

Per una corretta consegna della posta, i seguenti metodi anti-spam sono molto importanti per assicurarsi che l’email venga consegnata nella casella di posta degli utenti. La maggior parte dei fornitori di servizi email pubblici come yahoo, hotmail e gmail utilizzano questi parametri per contrassegnare l’email come spam o meno.

(i) Configura l’IP inverso per il tuo server di posta con PTR nel DNS (richiede IP dedicato)
(ii) Configura il record SPF nel tuo DNS
(iii) Configura le chiavi di dominio

Ho visto in molte occasioni che se utilizzi un piano di hosting condiviso, la maggior parte delle email finisce nella cartella spam/bulk nella casella di posta degli utenti. Quindi usa un server dedicato.

Configura IP inversi per gli IP del server di posta

Per configurare l’IP inverso, prima dovrai inviare una richiesta al tuo fornitore di hosting (poiché possiedono l’indirizzo IP) e chiedere loro di configurare un IP inverso per il tuo server di posta. Una volta fatto ciò, devi inserire una riga utilizzando PTR nel tuo file di zona del dominio.

Per testare la ricerca dell’IP inverso:

 host

mostrerà l’output del dns inverso.

Configura il record SPF

Il record SPF è configurato utilizzando il record TXT nel tuo file di zona DNS. Ha un aspetto simile a quello mostrato di seguito. Visita http://openspf.org per ulteriori informazioni sulla configurazione e impostazione.

domain.com. IN TXT “v=spf1 a mx ip4:11.33.55.77 -all”

Per interrogare il record SPF utilizzando dig:

 dig domain.com TXT

Chiavi di dominio

Contiene fondamentalmente 2 record (con e senza selettore) posizionati sotto TXT utilizzando un trattino basso insieme alla chiave pubblica generata.

Il ‘sel’ è un selettore e può essere il nome del selettore.

Come configurare i nameserver DNS per il tuo dominio utilizzando BIND9

Basta andare alla tua console Linux e digitare i seguenti comandi.

yum install bind

Crea un nuovo file di zona per il tuo dominio e inserisci il file di zona di esempio (vedi sotto). Devi cambiare domain.com, serial e parametri email.

nano /var/named/domain.com.db

Apri /etc/named.conf e inserisci le seguenti righe:

zone “domain.com” {
type master;
file “/var/named/domain.com.com.db”;
};

Salva le modifiche al file e riavvia bind.

service named restart

File di zona DNS di esempio per BIND

Usa questo file per configurare i tuoi domini e nameserver in BIND9:

;=================================================================
;FILE DI ZONA DNS BIND ESEMPIO
;per QUALSIASI Dominio (Cambia semplicemente domain.com nel tuo sito)
;================================================================

; Prima di iniziare NON DIMENTICARE IL PUNTO E L’INCREMENTO DEL SERIAL

$TTL 14400
$ORIGIN domain.com.

; Record SOA
; Specifica il nameserver primario ns1.domain.com
; Il seriale dovrebbe aumentare ad ogni aggiornamento
@ 14400 IN SOA ns1.domain.com. webmaster.domain.com. (
2009092902 ; Serial in YYYYMMDDXX (XX è incremento)
10800; secondi di refresh
3600; riprova
604800; scadenza
38400; minimo
);
; Indirizzo IP del sito web specificato nel record A

IN A xx.xx.xx.xx

; Minimo 2 nomi di nameserver DNS

IN NS ns1.domain.com.
IN NS ns2.domain.com.

; Mappatura di tutti i Nameserver e i loro IP corrispondenti (GLUE)

ns1 IN A xx.xx.xx.xx
ns2 IN A xx.xx.xx.xx

; Specifica eventuali sottodomini e voce www qui utilizzando il record CNAME

www IN CNAME domain.com.
ftp IN CNAME domain.com.
server IN CNAME domain.com.
webmail IN CNAME domain.com.

; Configura il record MX (scambiatore di posta con priorità)
domain.com. IN MX 10 mail.domain.com.

; imposta il record A per la posta
mail IN A xx.xx.xx.xx;====================================

Informazioni sull’autore

Il signor Balakrishnan è un imprenditore di Internet e amministratore Linux con interessi nella programmazione PHP e nelle applicazioni Linux. Può essere contattato sul suo sito blog corpocrat.com o sulla sua pagina Twitter.