Sono consapevole che non dovresti indirizzare direttamente un record MX a un indirizzo IP, ma dovresti invece puntarlo a un A
record che, a sua volta, punta all'indirizzo IP del tuo server di posta.
Ma, in linea di principio, perché è necessario?
Sono consapevole che non dovresti indirizzare direttamente un record MX a un indirizzo IP, ma dovresti invece puntarlo a un A
record che, a sua volta, punta all'indirizzo IP del tuo server di posta.
Ma, in linea di principio, perché è necessario?
Risposte:
L'idea alla base del record MX è quella di specificare un host o host che possono accettare la posta per un dominio. Come specificato in RFC 1035 , il record MX contiene un nome di dominio. Deve quindi puntare a un host che può essere risolto da solo nel DNS. Non è stato possibile utilizzare un indirizzo IP poiché sarebbe interpretato come un nome di dominio non qualificato, che non può essere risolto.
Le ragioni di ciò negli anni '80, quando le specifiche sono state scritte originariamente, sono quasi le stesse delle ragioni che lo hanno oggi: un host può essere collegato a più reti e utilizzare più protocolli.
Negli anni '80, non era raro avere gateway di posta che si collegavano sia alla (relativamente nuova) Internet che utilizzava TCP / IP sia ad altre reti legacy, che spesso utilizzavano altri protocolli. Specificare MX in questo modo consentiva record DNS che potessero identificare come raggiungere un tale host su una rete diversa da Internet, come Chaosnet . In pratica, tuttavia, ciò non è quasi mai accaduto; praticamente tutti hanno riprogettato le proprie reti per diventare invece parte di Internet.
Oggi, la situazione è che un host può essere raggiunto da più protocolli (IPv4 e IPv6) e da più indirizzi IP in ciascun protocollo. Un singolo record MX non può elencare più di un indirizzo, quindi l'unica opzione è quella di puntare a un host, dove è possibile cercare tutti gli indirizzi di quell'host. (Come ottimizzazione delle prestazioni, il server DNS invierà insieme i record di indirizzo per l'host nella sezione aggiuntiva di risposta se dispone di record autorevoli per loro, salvando un round trip.)
C'è anche la situazione che si verifica quando i tuoi scambiatori di posta sono forniti da terze parti (ad esempio Google Apps o Office 365). Puntare i record MX sui loro nomi host, ma può accadere che il fornitore di servizi debba modificare gli indirizzi IP dei server di posta. Poiché hai indicato un host, il fornitore di servizi può farlo in modo trasparente e non è necessario apportare modifiche ai tuoi record.
DNS come protocollo ha alcuni tipi diversi di valori, questi non sono intercambiabili.
È importante notare che il DNS è un protocollo binario con mappature rigorose tra il tipo di record e il tipo di dati in possesso di tale record.
Ad esempio:
un A
record contiene un indirizzo IPv4 (4 byte di dati, lunghezza fissa).
Un AAAA
record contiene un indirizzo IPv6 (16 byte di dati, lunghezza fissa).
Un MX
record, d'altra parte, contiene un nome (una sequenza di etichette sul formato <int number of bytes> <label> <int number of bytes> <label> <int 0>
, lunghezza variabile).
Non è possibile che un MX
record abbia un indirizzo IP come dati.
NXDOMAIN
).
MX
record che esistono realmente nel mondo possono o dovrebbero essere usati.
Lo proverò a indovinare. Certo, sono a casa con l'influenza, quindi forse sono nervoso.
RFC 974 afferma:
Il primo passo per il mailer su LOCAL è di inviare una query per MX RR per REMOTE. Si raccomanda vivamente di fare questo passo ogni volta che un mailer tenta di inviare il messaggio. La speranza è che le modifiche al database di dominio vengano rapidamente utilizzate dai mailer, e quindi gli amministratori di dominio saranno in grado di reindirizzare i messaggi in transito per host difettosi semplicemente modificando i loro database di dominio.
Richiedendo un nome anziché IP, incoraggia con forza questa pratica. I nomi possono rimanere gli stessi e, in caso di bilanciamento del carico o DR, non dovrai preoccuparti di modificare il record MX stesso e di attendere la propagazione del DNS.
Alcuni server di posta elettronica (come exim) in particolare non consentono l'invio a record MX che puntano a un indirizzo IP puro, quindi è necessario utilizzare un nome di dominio completo per essere invece conforme. Questo perché la maggior parte dei server prevede che il record MX contenga un nome host, non un IP (ecco a cosa servono i record A).
Modifica: per elaborare, in DNS ogni record ha requisiti rigorosi per il tipo di dati che ogni record può contenere. Nel caso dei record MX, è solo un nome host .
MX
record non può avere un indirizzo IP come valore.
IN RFC 1025 I record MX indicano solo un RR (record di risorse) di un record A o CNAME.
Quindi il server di posta che invia la posta richiede il RR di un record MX, il record mx elenca i record A dei server, il server di posta effettua una ricerca in avanti per ottenere un record A e quindi inoltra la posta via smtp all'host del servizio elencato come un server di posta "disposto" a ricevere posta per quel dominio.
Molte delle regole in vigore relative alla posta si sono evolute al fine di mantenere la fiducia tra i domini secondo cui i messaggi inviati avanti e indietro sono effettivamente validi. Tutto ciò per ridurre in definitiva lo SPAM.
Tutti questi componenti essenziali per una fondazione su cui costruire un server di posta hanno almeno un piccolo componente fondato nella creazione di comunicazioni affidabili e nella riduzione di comunicazioni non attendibili.
Lo scopo dei MX
record è che un'applicazione (trasferimento di posta) può conoscere l'host da utilizzare. A livello di applicazione, i nomi host sono la cosa giusta da usare (non gli indirizzi IP).
Inoltre, l'aggiunta del concetto di record di tipo variante al DNS introduce una leva di complicazioni e quindi un punto di ingresso per problemi, disfunzioni nell'implementazione, problemi di sicurezza. Ad esempio, 1.2.3.4.example.com.
è un nome host valido (sì, lo è, anche alla luce di RFC1034, 3.5). Specificare questo host come MX
in un file di configurazione di bind per esempio.com potrebbe apparire
. MX 10 1.2.3.4
e presumibilmente è esattamente lo stesso di un record MX con un IP. E anche per trasferire l'informazione in un datagramma DNS richiede alcuni eccentrici componenti aggiuntivi; il modo più semplice sarebbe quello di introdurre un nuovo tipo di record di risorse, MXA
diciamo, per chiarire le ambiguità. Ma ancora una volta, perché introdurre l'onere di un nuovo tipo di record quando
. MXA 10 5.6.7.8
potrebbe sempre essere sostituito con
. MX 10 dummy
dummy A 5.6.7.8
(e sarebbe supportato anche da client DNS che non sono a conoscenza dei MXA
record)?