Newsgroup: it.comp.os.linux.sys
Titolo: [SEMI-OT] Priorità MX e DNS Round Robin

Buongiorno,
 
mi è sorto un dubbio analizzando il campo MX di alcuni domini, riporto 
un estratto di esempio:
 
Prima interrogazione:
 
;; ANSWER SECTION:
dominio.tld.		5136	IN	MX	10 mail01.dominio.tld.
dominio.tld.		5136	IN	MX	11 mail02.dominio.tld.
dominio.tld.		5136	IN	MX	12 mail03.dominio.tld.
 
Seconda interrogazione:
 
;; ANSWER SECTION:
dominio.tld.		5136	IN	MX	12 mail03.dominio.tld.
dominio.tld.		5136	IN	MX	10 mail01.dominio.tld.
dominio.tld.		5136	IN	MX	11 mail02.dominio.tld.
 
e così via ...
 
Come si nota l'ordine di ritorno cicla tra i vari mail01, 02, ecc ... 
per effeto del DNS Round Robin, tuttavia le priorità sono fisse e 
distinte per i vari server (mail01 ha sempre la piorità più bassa).
 
In questo caso un mail server che deve consegnare a dominio.tld come si 
comporterà?
 
1 - onorerà sempre il server con priorità più bassa (mail01)
2 - onorerà il primo server ritornato
3 - andrà a caso, dipende dal tasso di umidità, altro ...
 
In rete trovo vari tutorial dove però (secondo me correttamente) le 
priorità sono impostate uguali se si vuole una distribuzione del 
carico.
 
Le priorità diverse invece sono usate come backup MX.
 
Qualcuno può illuminarmi? Grazie.
 
 

 1 - onorerà sempre il server con priorità più bassa (mail01)
 
In linea di massima sì.
Quindi, se vuoi bilanciamento, priorità uguali.

Nel suo scritto precedente, whiplash ha sostenuto :

Grazie per il contributo. Il discorso che mi preoccupa è "In linea di 
massima sì". Immagino non vi è certezza ed ogni implementazione di mail 
server agisce secondo suoi criteri.
 
Mi rendo conto che l'esempio da me riportato non deriva da una 
configurazione consona e coerente, ma tantè che ne sto trovando più di 
un caso in giro.
 
 

 comporterà?
 
La teoria vuole che si onori la RFC 5321 (in 
http://tools.ietf.org/html/
 
rfc5321):
  5.1. Locating the Target Host
 
In pratica, tranne talvolta QulMail, quelle regole sono rispettate.
 


Il problema non è l'MTA, di solito (leggasi: "salvo implementazioni SMTP
fantasiose".
 
La regola è che l'MTA deve inviare (o tentare) per primo all'MX con
priorità più bassa.
 
Se ve ne è più d'uno di pari priorità, piglia il primo che gli viene
passato.
 
E' poi compito del resolver (in teoria) fornire gli stessi record in
ordine diverso ad ogni query.
Il problema è che non tutti lo fanno; per dirne uno di ben noto e
"importante", google. Sicchè -ad esempio- tutti i mailserver che sono
stati impostati per usare google come resolver (pochi, auspicabilmente,
ma non ci credo nemmeno io) ti martelleranno su un unico record MX (e
qualora per quell'MX ci fossero più record A, tutti insieme allegramente
sullo stesso record A).
 
 
Sicchè, di fatto, il round-robin via DNS è una cosa tutt'altro che
precisa anche quando le cose van bene....
 

 precisa anche quando le cose van bene....
 
[CUT]
 
Grazie mille, non avevo considerato che anche l'implemntazione del 
resolver potesse incidere nel discorso. Avevo dato per scontato che in 
prsenza di RR i nomi "girassero", ma tu mi insgeni che non sempre è 
così.
 
 

 In pratica, tranne talvolta QulMail, quelle regole sono rispettate.
 
Ma qualcuno ancora lo usa? A proposito è possibile trovare delle 
stasitiche sulla distribuzione dei vari mail server (come netcraft per 
i vari web server, per intenderci)?
 
Chiosando si può affermare che l'implemntazione da me riportata non ha 
alcun senso, se l'intendo originale era quello di distribuire il 
traffico tra più mail server (a meno che non abbiano fatto scentemente 
ciò in presenza di connettività del tutto ballerine). Concordi?
 
 

 fatto scentemente ciò in presenza di connettività del tutto ballerine). Concordi?
 
Sì, se l'intento era quello.
In realtà, come ha fatto notare Skull, anche mettendoli tutti a pari priorità, con resolver stronzi ciò potrebbe non accadere.
 

 priorità, con resolver stronzi ciò potrebbe non accadere.
 
 
Si ma ...
 
Devi anche pensare che nessun gestore di email sano di mente userebbe 
google come resolver su un MTA.
 
La ragione è semplice: la maggior parte delle RBL non funzionano su google 
e nel 2012 senza RBL è difficile campare.
 
La vedo più come eccezione che come regola.

 La vedo più come eccezione che come regola.
 
Verissimo come linea generale, ma la quantità di implementazioni di
resolver che non ciclano è ampia. Tendenzialmente, comunque, le cose si
bilanciano comunque per mero effetto statistico...
 
Il senso che volevo sottintendere, tuttavia, è che il bilanciamento via
DNS non garantisce mai risultati 100% even. Tantopiù con un protocollo
come SMTP dove la stragrande maggioranza degli emettitori NON è un
mailserver e pertanto interpreta in maniera molto approssimativa le RFC.
 
Se le esigenze di bilanciamento possono convivere con ciò, il
bilanciamento via DNS può essere sufficiente.
Se i numeri si fanno grossi e l'esigenza del bilanciamento è quella di
non avere macchine ammazzate dai comportamenti anomali, l'uso di
bilanciatori diviene sostanzialmente necessaria.
 
(c'era un thread di diversi anni fa qui su icols, al riguardo, cmq...)
 

 La ragione è semplice: la maggior parte delle RBL non funzionano su google
 
Puoi spiegarmi perchè?
 
Grazie in anticipo
Rizio

 Puoi spiegarmi perchè?
 
Perchè la maggior parte delle DNSBL è erogata in modalità "Freemium",
ovvero free per l'uso personale/small-business/etc, ma richiede fee per
uso commerciale, soprattutto da grossi operatori.
 
Lo fanno applicando ACL ai DNS che eseguano un numero eccessivo di
query, sostanzialmente.
 
Se consentissero a chiunque di usare gratuitamente la loro
infrastruttura semplicemente usando open resolver (come google,
appunto), avrebbero già chiuso bottega da un pezzo...
 
Ergo, tipicamente le DNSBL hanno questi open resolver in ACL...
 
 
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
 

 Ergo, tipicamente le DNSBL hanno questi open resolver in ACL...
 
Grazie mille Skull, sei sempre illuminante.
 
Rizio

 Grazie mille Skull, sei sempre illuminante.
 
Come non quotare...
Ci sono almeno 4-5 persone qui dentro che hanno la palle quadrate :)