In quali circostanze (se presenti) un record MX dovrebbe puntare a localhost?

Sto pensando che non c'è assolutamente alcuna ragione o giustificazione per questo, ma prima di aprire la bocca e ottenere un po 'di amministrazione in kimchi profondo, ho pensato che avrei dovuto chiedere.

C'è qualche circostanza in cui un record MX dovrebbe puntare a un indirizzo di loopback? Per me, questo dice che qualsiasi server di posta che tenta di inviare a questo dominio invierà invece a se stesso e fallirà, ma non sono un guru della posta, quindi forse mi manca qualcosa.

Mi sono imbattuto nel seguito durante la risoluzione dei problemi di perché-non-stiamo-ottenendo-mail ?? problema per un cliente, e ho problemi a avvolgerci la testa. Forse sto pensando troppo alle cose.

Risposta breve: non dovrebbe.

Risposta lunga: se il dominio in questione (DIQ) non deve ricevere e-mail, l'inserimento di un indirizzo di loopback per il record MX fa sì che il server di invio tenti di connettersi a se stesso. Ciò consente di risparmiare il DIQ di pochi byte misurati e di ripulire eventualmente i registri del firewall (se qualcuno sta persino guardando) quando altri server di posta tentano di connettersi. Tuttavia, a mio avviso, il risparmio di larghezza di banda non è sufficiente per giustificare la violazione di RFC 3330.

Sicuramente un NO, non con un IP 127.0.0.0. L'intero intervallo 127.0.0.0 su IPv4 funziona come indirizzi di loopback, quindi quando qualsiasi macchina si connette a IP in quell'intervallo proverà a connettersi a se stessa.

L'indirizzo IP del tuo record MX dovrebbe essere accessibile dal mondo esterno e ciò che quel risultato sta dicendo a qualsiasi server che sta eseguendo una query MX, di provare a connettersi a se stesso.

Se il mio server cercasse di inviarti e-mail, cercherebbe il record MX e quindi connetterebbe il proprio indirizzo IP, invierebbe l'e-mail e fallirebbe.

Le RFC pertinenti affermano:

• Il record di risorse MX DEVE puntare a un nome di dominio completo (non un indirizzo IP) di un server su Internet pubblico che accetta la posta per il dominio. Si noti che questo server non deve necessariamente trovarsi nello stesso dominio del record MX. RFC 1035 sezione 3.3.9

• Gli indirizzi nell'intervallo 127.0.0.0/8 NON DEVONO mai apparire su Internet pubblico. RFC 5735 sezione 3

Si noti che alcuni server di posta rifiuteranno la posta elettronica da mittenti non conformi alle RFC pertinenti .

Quando un host deve essere in grado di inviare posta a se stesso attraverso domini ospitati diversi ma non accetta la posta esterna, "MX 0 localhost". è accettabile. Per indicare che un host non ha alcun server di posta, usa "MX 0".

"MX 0". è dettagliato in RFC7505 .

Bene, ho una situazione in cui l'impostazione di un dominio su localhost sembra essere necessaria.

Nel marzo 2012 ho registrato un dominio carino che sono stato sorpreso di trovare disponibile. Mia figlia voleva creare un sito di collaborazione artistica. Ho impostato MX su uno dei miei altri server SMTP. Questo ha funzionato bene, ma poi ho iniziato a ricevere molti messaggi di posta "utente sconosciuto" su xxx@cute-domain.com (non il vero nome di dominio). Quindi ho usato MailScanner per bloccare tutti i messaggi in arrivo verso quel dominio tranne un indirizzo legittimo. Sembra che il dominio fosse un servizio di posta elettronica gratuito a partire dal 2001 ma apparentemente si era oscurato e aveva rinunciato al suo simpatico nome di dominio.

Questo ha funzionato bene fino a un paio di giorni fa (20/11/12) quando il server smtp ha iniziato a rifiutare i messaggi in arrivo a causa di connessioni aperte eccessive. Questi erano processi smtp in attesa di risposte "ricevuta a", credo. Ho guardato il traffico e sono stato bombardato da migliaia di messaggi in arrivo per xxx@cute-domain.com da altrettanti relè smtp in tutto il mondo. (17.000 messaggi in un periodo di 24 ore)

Quindi ho cambiato l'MX per puntare a un altro server che non esegue smtp con la porta 25 bloccata. Abbastanza sicuro, hanno iniziato a comparire migliaia di sessioni abbandonate. Dato che questo comportamento sembra una sorta di torrent di spam, forse proveniente da una botnet, ho pensato che sarebbe stato necessario impostare MX per localhost.

Lo lascerò così per un po '. Non abbiamo bisogno di e-mail per il cute.domain.com, quindi nulla è perso tranne i cicli per la botnet.

Perché non usare un target MX che non risolve nulla? Per esempio:

example.com. IN MX 10 qualcosa. Invalido.

Gli spammer vedranno l'errore di risoluzione e non si preoccuperanno del prossimo record MX, pensando che il bersaglio sia configurato male. I server reali proveranno il record successivo. Ciò non disturberà la porta TCP chiusa di nessuno 25, ovvero nessun traffico smtp, solo DNS.