DNS e Antispam
Il DNS è un elemento cruciale per il corretto funzionamento del mailserver e l’efficacia dei sistemi di sicurezza e filtraggio della posta indesiderata.
La corretta risoluzione DNS è chiaramente fondamentale per l’inoltro di posta elettronica a destinatari esterni, ma è coinvolta anche in un certo numero di operazioni importanti effettuate sulla posta in arrivo.
La risoluzione DNS del server IceWarp è affidata ai nameserver indicati nella configurazione (Sistema->Connessione->Generale) dove, durante l’installazione iniziale del software, vengono copiati quelli impostati al momento nella connessione di rete del sistema. Successivamente l’amministratore ha facoltà di modificarli, ma molto spesso non ne viene percepita l’esigenza e rimangono in uso quelli originali.
Generalmente si tratta di server DNS di proprietà, mantenuti e suggeriti dal fornitore di connettività o del servizio di hosting su cui è attestato il mailserver; altre volte, per ragioni economiche e di semplicità, vengono indicati server DNS accessibili pubblicamente, offerti gratuitamente da soggetti come Google (nameserver 8.8.8.8 / 8.8.4.4), Cloudflare (1.1.1.1 / 1.0.0.1), OpenDNS (208.67.222.222 / 208.67.220.220) e alcuni altri.
I problemi con questi server DNS pubblici sono sostanzialmente due, in un certo senso connessi tra loro:
- Sono generalmente indicati per uso non professionale, per le semplici operazioni di risoluzione DNS connesse alle normali attività dell’utente medio (navigazione web, utilizzo di applicazioni, ecc.) e spesso hanno finalità ben precise, come raccogliere informazioni sulle abitudini dell’utenza.
- Essendo molto noti, liberamente accessibili e gratuiti, sono utilizzati quotidianamente da un numero molto elevato di utenti e generano di conseguenza volumi di interrogazioni ricorsive non indifferenti, per soddisfare le richieste dell’utenza.
Quando i nameserver pubblici vengono utilizzati come resolver per il mailserver, le suddette problematiche non influenzano particolarmente le attività di inoltro della posta elettronica, in quanto le tipiche operazioni di risoluzione dei record MX oppure A vengono generalmente soddisfatte senza difficoltà.
La questione può essere invece molto diversa per le varie attività connesse alla posta in arrivo dall’esterno, sulla quale il mailserver effettua una serie di controlli e verifiche, che possono richiedere numerose operazioni di risoluzione DNS, tra cui:
- Risoluzione del record PTR per i controlli di sicurezza rDNS
- Verifica della cosiddetta “reputazione IP” del server remoto
- Verifica delle liste antispam DNSBL impostate a livello di servizio SMTP
- Verifica dei record TXT relativi alle tecniche SPF e DKIM da parte del sistema di filtraggio
- Verifica delle liste RBL, URIBL, SURBL e simili da parte del sistema Antispam
- Ulteriori test nell’ambito delle regole del sottosistema di filtraggio SpamAssassin
È quindi evidente che le operazioni di risoluzione DNS per la posta in arrivo sono molto più complesse e numerose rispetto a quelle necessarie per l’inoltro di posta all’esterno e risentono fortemente delle due problematiche menzionate in precedenza.
L’utilizzo dei nameserver pubblici noti si scontra infatti con importanti limitazioni, alcune delle quali attuate dai gestori stessi dei resolver, altre dai gestori di alcune delle liste di filtraggio antispam basate su DNS, appunto.
Il primo caso è conseguenza della destinazione d’uso a scopo non professionale dei nameserver in questione, per cui il gestore decide di inibire determinate tipologie o ambiti di interrogazione DNS, in quanto non necessari per l’utilizzo tipico dell’utenza media.
Per esempio alcuni nameserver non soddisfano volutamente le interrogazioni di alcune liste antispam note, in quanto sono attività a cui l’utenza non è generalmente interessata, quindi estranee alle finalità dei servizi DNS aperti.
In altri casi sono i gestori di liste e servizi antispam a limitare l’accesso ai propri servizi o il numero di interrogazioni che possono essere soddisfatte gratuitamente prima di essere sollecitati alla sottoscrizione di servizi a pagamento offerti, perché evidentemente si ricade in condizioni di utilizzo continuativo e probabilmente nell’ambito di attività professionali.
In entrambe le circostanze, gli effetti delle restrizioni vanno dalla mancata risposta del nameserver a risposte invariabilmente negative, che rendono inefficace la relativa funzionalità di sicurezza, fino ad arrivare a situazioni estreme e più problematiche, nelle quali il gestore del servizio antispam restituisce artificiosamente false risposte positive a tutte le interrogazioni, con lo scopo di dissuadere dall’utilizzo del servizio gratuito, causando chiaramente importanti problemi al mailserver che le sta effettuando.
Tra l’altro, le restrizioni possono essere permanenti oppure attivarsi improvvisamente nel corso della giornata, magari al raggiungimento di determinate soglie di utilizzo, causando ancora più problemi ai servizi di posta elettronica e conseguenti disagi per l’utenza.
Per tutti i motivi esposti sopra, pertanto, diventa fondamentale conoscere le interrogazioni DNS che il software ha necessità di effettuare per le varie funzionalità di filtraggio e sicurezza, e saper valutare se i nameserver impostati come resolver sono in grado di soddisfarle permanentemente e in modo efficiente, senza scontrarsi con le restrizioni e limitazioni sopra accennate.
Liste antispam basate su DNS – Interrogazioni di verifica del funzionamento
La maggior parte delle liste antispam basate su DNS prevedono una interrogazione di test, che consente di stabilire se il nameserver in uso è in grado di utilizzare il servizio o ricade nelle suddette problematiche ed è quindi inadatto all’impiego. L’interrogazione di test convenzionale è nella forma:
2.0.0.127.<lista>
Anche se nella maggior parte dei casi le interrogazioni di test sono in grado di restituire un record di tipo “A”, è preferibile effettuarle richiedendo un record di tipo “TXT”, nel qual caso la risposta sarà verbale e conterrà indicazioni più facilmente intellegibili sull’esito del test, anziché dover interpretare una risposta numerica.
La risposta contiene di solito l’indicazione della lista con cui c’è stato riscontro oppure una indicazione esplicita dell’esito del test, positivo o negativo.
La mancata risposta del nameserver o una risposta di record inesistente indicano ugualmente l’esito negativo della verifica. Alcune liste, soprattutto quelle combinate, possono restituire risposte multiple, per meglio specificarne il significato e l’ambito.
Per esempio, nel caso della nota lista DNSBL zen.spamhaus.org, il test effettuato tramite un nameserver correttamente funzionante e adatto allo scopo si svolge come segue:
Richiesta: 2.0.0.127.zen.spamhaus.org
Tipo di record: TXT
Risposte:
“Listed by PBL, see https://check.spamhaus.org/query/ip/127.0.0.2″
“Listed by XBL, see https://check.spamhaus.org/query/ip/127.0.0.2″
“Listed by SBL, see https://check.spamhaus.org/sbl/query/SBL2″
Ripetendo invece il test con un nameserver inadatto, per esempio 1.1.1.1 di Cloudflare:
Richiesta: 2.0.0.127.zen.spamhaus.org
Tipo di record: TXT
Risposta: “Error:open resolver; https://check.spamhaus.org/returnc/pub/172.70.172.6/”
Il nameserver pubblico di Cloudflare, come diversi altri della stessa tipologia, è infatti inibito dalle interrogazioni di molte delle più note liste basate su DNS.
Liste di altra tipologia (URIBL, SURBL, ecc.) possono essere verificate in maniera del tutto analoga. Per esempio:
Richiesta: 2.0.0.127.multi.uribl.com
Tipo di record: TXT
Risposta: “permanent testpoint“
In questo caso il test della lista URIBL multi.uribl.com ha restituito semplicemente esito positivo.
Ripetendo invece il test utilizzando un nameserver non adatto:
Richiesta: 2.0.0.127.multi.uribl.com
Tipo di record: TXT
Risposta: “127.0.0.1 -> Query Refused. See http://uribl.com/refused.shtml for more information [Your DNS IP: aaa.bbb.ccc.ddd]”
Implementazione di un server DNS resolver ricorsivo
Come già accennato, l’impiego dei nameserver pubblici messi a disposizione gratuitamente da soggetti come Google, Cloudflare, OpenDNS, eccetera, è in generale deprecato.
Tuttavia, anche server DNS privati e non accessibili pubblicamente, come quelli messi a disposizione dal proprio fornitore di connettività o dei servizi di hosting, potrebbero risultare inadeguati o non affidabili, sia per politiche d’utilizzo dei gestori, sia perché condivisi da più utilizzatori, con il rischio di imbattersi in limitazioni sul numero di interrogazioni DNS in un determinato periodo o sulla loro frequenza.
Un altro aspetto, spesso trascurato, ma determinante per il buon funzionamento del mailserver è costituito dalla reattività del servizio DNS.
Tempi di risposta non particolarmente brevi possono influenzare negativamente le prestazioni dei servizi di posta e aumentare il carico e il consumo di risorse. La maggior parte delle operazioni di risoluzione DNS viene infatti svolta nel corso delle sessioni SMTP entranti, la cui durata è quindi condizionata anche dalla tempestività delle risposte.
Nei casi più problematici, ritardi eccessivi delle risposte possono falsare l’esito di alcuni controlli di sicurezza. A seconda delle circostanze, un timeout di risoluzione DNS può infatti portare a un “falso negativo” e in qualsiasi caso prolungare inutilmente la durata delle operazioni e della sessione SMTP.
I server DNS pubblici risentono molto spesso di problemi di questo tipo, principalmente a causa del carico elevato a cui sono soggetti.
La soluzione migliore consiste perciò nel dotarsi di nameserver propri, a uso esclusivo dei propri servizi.
Se non è già disponibile nella propria infrastruttura, è possibile installare un server DNS locale a bordo della stessa macchina che ospita il mailserver, configurato come resolver ricorsivo.
È invece da evitare una configurazione con nameserver di inoltro (forwarders), perché si ricadrebbe molto probabilmente nelle problematiche fin qui descritte.
Si può eventualmente sfruttare il servizio resolver di sistema (Servizio DNS di Windows, systemd-resolved su Linux, …) ma per ottenere migliori prestazioni, affidabilità e flessibilità di configurazione, è consigliabile installare un server DNS più evoluto, come ISC BIND 9, opportunamente configurato come resolver ricorsivo e caching nameserver.
Limitazioni d’uso delle liste basate su DNS
In generale, l’impiego di nameserver di proprietà risolve efficacemente e in modo permanente le problematiche di risoluzione DNS connesse al mailserver.
Restano eventualmente da affrontare quelle legate alle politiche di utilizzo dei servizi a interrogazione DNS, come le più volte menzionate liste DNSBL, URIBL, SURBL, ecc.
Quelle più note e diffuse consentono di solito un utilizzo gratuito dei loro servizi in ambito non commerciale, da parte di organizzazioni medio-piccole e quindi per volumi di interrogazioni ragionevolmente contenuti.
Per esempio Spamhaus quantifica indicativamente in 100.000 interrogazioni al giorno i volumi massimi di un uso onesto e non a scopo commerciale delle proprie block list DNSBL.
Oltre quella soglia, si configura un’attività di sfruttamento commerciale, quindi l’organizzazione chiede la sottoscrizione di un servizio a pagamento.
Altri soggetti prevedono limiti notevolmente più bassi, oltre i quali viene chiesto all’utilizzatore almeno di formalizzare un’iscrizione per poter continuare a usufruire gratuitamente dei servizi, ancora una volta salvo il caso di un utilizzo commerciale.
È questo il caso delle liste gestite da Validity (ex Return Path, SenderScore), impiegate nell’ambito dell’elaborazione del componente di filtraggio SpamAssassin. L’azienda consente di effettuare 10.000 interrogazioni DNS delle loro liste nell’arco di 30 giorni. Superata quella soglia, l’utilizzatore è invitato a creare un account e a registrare i propri nameserver per continuare a utilizzare gratuitamente i servizi:
https://my.validity.com/zone/sign-up
Se non viene intrapresa questa azione, Validity attua il blocco dell’indirizzo del server DNS e gli impedisce l’utilizzo delle liste, riducendo di conseguenza l’efficacia del processo di filtraggio.
Nell’esito della scansione riportato nel log del modulo Antispam ed eventualmente negli header diagnostici del messaggio, la situazione in cui l’utilizzo di una determinata lista basata su DNS è inibito, è indicata con il suffisso _BLOCKED apposto al corrispondente test di SpamAssassin. Per esempio:
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED
RCVD_IN_VALIDITY_SAFE_BLOCKED
RCVD_IN_VALIDITY_RPBL_BLOCKED
Più in generale, la dicitura BLOCKED nelle regole di SpamAssassin costituisce un avviso all’amministratore di sistema di un problema di risoluzione DNS, quasi sempre per le motivazioni fin qui trattate (impiego di nameserver non idonei o superamento dei limiti di utilizzo consentito):
RCVD_IN_ZEN_BLOCKED_OPENDNS
URIBL_ZEN_BLOCKED_OPENDNS
URIBL_DBL_BLOCKED_OPENDNS
SURBL_BLOCKED
URIBL_BLOCKED
RCVD_IN_DNSWL_BLOCKED
DKIMWL_BLOCKED
Poiché hanno soltanto scopo informativo, a queste pseudo-regole è associato un punteggio nullo e ininfluente ai fini della classificazione spam, ma ovviamente l’impossibilità di effettuare i corrispondenti controlli può ridurre sensibilmente l’efficacia del filtraggio di SpamAssassin, in particolare con alcune tipologie di spam, che molto spesso soltanto i controlli tipo URIBL o SURBL sono in grado di rilevare.
È quindi opportuno rimediare quanto prima alle problematiche di risoluzione DNS per garantire la massima efficienza dei sistemi di sicurezza e prevenzione del server IceWarp.
Riferimenti utili
http://wiki.apache.org/spamassassin/DnsBlocklists\#dnsbl-block
https://knowledge.validity.com/s/articles/Accessing-Validity-reputation-data-through-DNS
