Generatore online di record SPF

http://www.spfwizard.net/

Configurare DKIM (DomainKeys Identified Mail) con Postfix su Debian usando OpenDKIM (HOWTO)

Note preliminari:

Tutti comandi di questo HOWTO vengono eseguiti dall'utente root

esempio.com deve essere sostituito con il dominio su cui state configurando DKIM

Installazione software necessario:

apt-get install opendkim opendkim-tools

(la procedura di installazione crea in automatico l'utente e il gruppo opendkim)

Creazione directory e sistemazione permessi:

mkdir -p /etc/opendkim/keys

chown -R opendkim:opendkim /etc/opendkim

chmod -R go-wrx /etc/opendkim/keys

Generazione chiavi:

E' necessario generare una chiave pubblica e una privata per ogni dominio per il quale pensate di aggiungere la firma DKIM. La chiave privata e' conservata sul server, mentre la chiave pubblica deve essere pubblicata sul DNS del dominio in modo che i mail server di destinazione possano verificare la firma DKIM della nostra mail.

Bisogna decidere il nome del selettore. Un selettore e' una parola univoca che viene associata ad entrambe le chiavi, pubblica e privata, inclusa in tutte le firme e pubblicata nei record DNS. Per semplicita' useremo la parola default come selettore di default. Potete scegliere anche un'altra parola, ma se lo fate, state attenti a utilizzare sempre quella durante le varie fasi della configurazione.

Vi ricordo inoltre di sostituire il vostro dominio di posta a dominio.com nelle fasi seguenti della configurazione:

mkdir /etc/opendkim/keys/example.com

opendkim-genkey -D /etc/opendkim/keys/example.com/ -d example.com -s default

chown -R opendkim:opendkim /etc/opendkim/keys/example.com

mv /etc/opendkim/keys/example.com/default.private /etc/opendkim/keys/example.com/default

Nel comand opendkim-genkey vengono utilizzati i seguenti parametri:

-D indica la directory in cui verranno memorizzate le chiavi

-d indica il dominio di posta a cui fanno riferimento le chiavi generate

-s indica il selettore

Creazione e modifica dei file di configurazione:

I file di configurazione del sistema OpenDKIM sono i seguenti:

- 1 /etc/opendkim.conf  - e' il file di configurazione principale di OpenDKIM

- 2 /etc/opendkim/KeyTable - e' la lista delle chiavi disponibili

- 3 /etc/opendkim/SigningTable - e' la lista di domini e account specifici abilitati a firmare i propri messaggi

- 4 /etc/opendkim/TrustedHosts - e' la lista di server ritenuti affidabili al momento di inserire o verificare una firma DKIM

1) Creazione del file /etc/opendkim.conf (se esiste gia' salvatene il contenuto e sostituitelo con quanto segue)

Verificate che il contenuto del file sia il seguente:

##

## opendkim.conf -- configuration file for OpenDKIM filter

##

AutoRestart             Yes

AutoRestartRate         10/1h

Canonicalization        relaxed/simple

ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts

InternalHosts           refile:/etc/opendkim/TrustedHosts

KeyTable                refile:/etc/opendkim/KeyTable

LogWhy                  Yes

Mode                    sv

PidFile                 /var/run/opendkim/opendkim.pid

SignatureAlgorithm      rsa-sha256

SigningTable            refile:/etc/opendkim/SigningTable

Socket                  inet:8891@localhost

Syslog                  Yes

SyslogSuccess           Yes

TemporaryDirectory      /var/tmp

UMask                   022

UserID                  opendkim:opendkim

2) creazione del file /etc/opendkim/KeyTable:

default._domainkey.example.com example.com:default:/etc/opendkim/keys/example.com/default

Il file KeyTable dice a  OpenDKIM dove trovare le chiavi. Ogni elemento del file KeyTable e' una singola linea per ogni posizione di chiavi. Se avete intenzione di utilizzare chiavi multiple (ad esempio per firmare le mail dei domini virtuali con chiavi differenti).dovrete creare una linea separata per ogni dominio nel file KeyTable.

3) creazione del file /etc/opendkim/SigningTable:

*@example.com default._domainkey.example.com

Il file SigningTable dice a OpenDKIM come usare le vostre chiavi e queli selettori usare per i vari mittenti per le loro firme. Nell'esempio abbiamo detto al sistema che tutti (*) i mittenti del server "dominio.com" dovrebbero usare il selettore "default." 

E' importante notare che il simbolo * funzionera' solo se nel file di configurazione opendkim.conf l'opzione SigningTable utilizza il prefisso "refile:" prima del filename.

4) creazione del file /etc/opendkim/TrustedHosts:

127.0.0.1

hostname1.example1.com

example1.com

hostname1.example2.com

example2.com

Il file TrustedHosts dice a OpenDKIM chi puo' usare le chiavi per firmare i messaggi.

Essendo referenziato dalla direttiva ExternalIgnoreList nel file di configurazione, OpenDKIM ignorera' questa lista di host quando verifica le mail in ingresso.

Essendo referenziato dalla direttiva InternalHosts nel file di configurazione, OpenDKIM firmera' le mail in uscita da questi host.

IMPORTANTE: assicuratevi che l'IP address per localhost (127.0.0.1) sia inserito nel file TrustedHosts file, altrimenti OpenDKIM non firmera' le email spedite dal server.

Se aveye piu' server sulla stessa rete che utilizzano il vostro server come relay host, dovete inserire gli indirizzi IP di questi server nel file TrustedHosts se volete firmare anche le loro email. 

Inserite un elemento per ogni linea.

Un elemento puo' essere un hostname, un nome di dominio  (per esempio "dominio.com"), un indirizzo IP, an indirizzo IPv6 o un indirizzo CIDR (per esempio 192.168.1.0/24).

Configurazione di opendkim su postfix:

Inserire le righe seguenti nel file /etc/postfix/main.cf

smtpd_milters           = inet:127.0.0.1:8891

non_smtpd_milters       = $smtpd_milters

milter_default_action   = accept

milter_protocol = 2

Restart dei servizi coinvoilti:

/etc/init.d/onendkim restart
/etc/init.d/postfix restart

Verificare su /var/log/mail.log che entrambi i servizi siano ripartiti e che non ci siano altri errori.

Aggiungere i record DNS:

Ora che il vostro server sta firmando le mail in uscita e verificando le mail in entrata, avete bisogno di inserire alcune informazioni nei record DNS per dire agli altri mail server come sono configurate le vostre chiavi e per fornire loro la chiave pubblica in modo che possano verificare che la tua mail e' firmata correttamente.

cat /etc/opendkim/keys/example.com/default.txt

L'output di questo comando dovrebbe essere simile a quanto segue:

default._domainkey IN TXT "v=DKIM1; g=*; k=rsa; p=7k45u5i2T1AlEBeurUbdKh7Nypq4lLMXC2FHhezK33BuYR+3L7jxVj7FATylhwIDAQABMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHY7Zl+n3SUldTYRUEU1BErHkKN0Ya52gazp1R7FA7vN5RddPxW/sO9JVRLiWg6iAE4hxBp42YKfxOwEnxPADbBuiELKZ2ddxo2aDFAb9U/lp4" ; ----- DKIM default for example.com

Ora create un record DNS per il vostro dominio e copiate l'intero contenuto del file /etc/opendkim/keys/example.com/default.txt in fondo al file della zona del vostro dominio, Il nome TXT sara' default._domainkey e il valore TXT sara' tutto quello compreso tra apici (a partire da v=)

Potete ignorare il punto e virgola e il commento finale.

Seguite attentamente le istruzioni del vostro provider DNS per aggiungere un record TXT al vostro dominio

Ora sarebbe il momento giusto per verificare di avere anche un record SPF valido nel vostro DNS. Aver configurato a dovere sia DKIM che SPF aumentera' sensibilmente le vostre probabilita' di consegna della vostra posta in uscita.

DNS: error (FORMERR) resolving '$SOMETHING': xx.xx.xx.xx#53

Nel log /var/log/daemon.log apparivano diverse segnalazioni simili a questa:

Jul 31 09:01:27 server named[29883]: error (FORMERR) resolving '$SOMETHING': xx.xx.xx.xx#53

Qualche DNS risponde in maniera errata ad una interrogazione.

Il log puo' essere ignorato ed eventualmente disabilitato inserendo quanto segue nel file named.conf.local:

logging {         category lame-servers { null; };     }; 

DNS: generazione chiave rndc per aggiornamenti dinamici

Lanciare il comando:

rndc-confgen -a -c /etc/bind/rndc.key

se il comando precedente si dovesse bloccare (normalmente termina quasi istantaneamente) lanciate il comando seguente:

rndc-confgen -r /dev/urandom -a  -c /etc/bind/rndc.key

Bind9 Error : named[....]: network unreachable resolving ...

named[8660]: network unreachable resolving 'zd.somedomain.org/AAAA/IN': 2001:500:f::1#53

Questo errore ripetuto nei log di sistema e' dovuto al fatto che per default, bind utilizza anche IPv6.

Per disabilitare questa caratteristica bisogna editare il file

/etc/default/bind9

e aggiungere

-4

alle opzioni, ottenendo:

OPTIONS="-4 -u named"

Completare la procedura facendo ripartire il servizio bind.

BIND+DHCP: gli aggiornamenti dinamici del DNS non funzionano

Se gli aggiornamenti dinamici del DNS non funzionano, controllate se nel file /var/log/daemon.log trovate qualcosa di simile a quanto segue:

Jun 27 22:27:26 milhouse named[3278]: /etc/bind/zones/db.simpson.jnl: open: permission denied
Jun 27 22:27:26 milhouse named[3278]: client 192.168.2.130#40535: updating zone 'corimtec.mylan/IN': error: journal open failed: unexpected error
Jun 27 22:27:26 milhouse dhcpd: Forward map from bart.simpson.local. to 192.168.2.162 FAILED: SERVFAIL

Per risolvere questo problema occorre verificare i permessi del file .jnl (nell'esempio /etc/bind/zones/db.simpson.jnl).

Nel nostro caso l'utente bind non aveva accesso in scrittura sul file .jnl

-rw-r--r-- 1 root bind 5951774 Jun 27 22:42 /etc/bind/zones/db.simpson.jnl

Basta assegnare l'apposito permesso con il comando

chmod 664 /etc/bind/zones/db.simpson.jnl

Ottenendo quindi:

-rw-rw-r-- 1 root bind 5951774 Jun 27 22:42 /etc/bind/zones/db.simpson.jnl

DNS: too many timeouts resolving '$OUTER_DOMAIN/A' (in '$URL'?): reducing the advertised EDNS UDP packet size to 512 octets

Se ricevete nei log tonnellate di messaggi simile al seguente:

Jun 13 12:10:31 $SERVER_NAME named[2604]: too many timeouts resolving '$OUTER_DOMAIN/A' (in '$URL'?): reducing the advertised EDNS UDP packet size to 512 octets

potete disabilitare il logging di EDNS inserendo nel vostro named.conf:

logging {

            category edns-disabled { null; };

        };

named[...]: network unreachable resolving

Se sul log vedete delle righe del genere (logwatch me le manda tutti i giorni all'alba):

named[9217]: network unreachable resolving 'www.google.com/A/IN': 2001:500:2f::f#53
named[9217]: network unreachable resolving 'www.google.com.localdomain.net/AAAA/IN': 001:dc3::35#53

il problema sta nel protocollo IPv6, se non lo usate potete modificare i parametri di lancio del vostro server DNS. Su debian la modifica va fatta nel file

/etc/default/bind9

sostituendo la riga:

OPTIONS="-u bind"

con la riga

OPTIONS="-4 -u bind"

Fate ripartire il vostro server DNS e i vostri log (ma soprattutto l'addetto al loro monitoraggio) ve ne saranno grati.

Pulire la cache del DNS

Voi sapete che l'IP address di un server e' x.x.x.x ma la vostra macchina sostiene che sia y.y.y.y?
Potete farla ragionare eseguendo un flush della cache del DNS:

Windows:

ipconfig /flushdns

Linux con bind:

rndc flush

Linux con ncsd:

/etc/init.d/nscd restart

e se non funzionasse

/etc/init.d/nscd reload

Linux con dnsmasq:

/etc/init.d/dnsmasq restart

Errore: Has an A record but no DHCID, not mine.

Lo scenario e' costituito da una subnet con DHCP che aggiorna dinamicamente il DNS ad ogni rinnovo di indirizzo IP.

Il meccanismo funzionava perfettamente per tutti gli host della subnet tranne uno: riceveva correttamente un indirizzo IP, pero' il DNS non veniva aggiornato. Il file /var/log/daemon.log conteneva questo errore:
Mar 16 20:29:05 server dhcpd: Forward map from hostname.domain.local. to 10.1.1.123 FAILED: Has an A record but no DHCID, not mine.
Ho trovato diverse soluzioni proposte, ma non la piu' ovvia (almeno in questo caso): esisteva infatti una definizione statica di hostname.domain.local nelle zone forward e reverse del DNS.

Soluzione:

SUL SERVER DNS

rndc freeze domain.local
rndc freeze 1.1.10.in-addr.arpa
vi /etc/bind/zones/db.domain.local (e rimuovere la linea contenente hostname.domain.local)
vi /etc/bind/zones/db.10.1.1 (e rimuovere la linea contenente hostname.domain.local)
rndc unfreeze domain.local
rndc unfreeze 1.1.10.in-addr.arpa

SUL CLIENT HOSTNAME.DOMAIN.LOCAL

dhclient
nslookup hostname.domain.local (se e' tutto ok, dovrebbe risultare l'indirizzo IP assegnato dal comando dhclient)

dns bind9: modifica zona con dynamic update

Se state aggiornando dinamicamente il vostro DNS tramite dynamic update (ad esempio, ogni volta che una macchina ottiene un indirizzo IP dal server DHCP della vostra rete), dovete fare attenzione nel caso vogliate modificare manualmente il file di definizione di una zona (ad esempio per inserire i riferimenti a un nuovo server).

I dynamic update infatti utilizzano un file .jnl (journal) in cui tengono traccia delle loro modifiche alla zona. Prima di modificare la zona manualmente dovete disabilitare il file di journal con il comando:

rndc freeze NOME_ZONA

Dopo aver completato le modifiche dovete riattivare il file di journal con il comando:

rndc unfreeze NOME_ZONA

Il punto finale nei nomi di dominio

Per la serie "i grandi dilemmi dell'umanita'" puo' capitare di dimenticare le situazioni in cui il nome di dominio (stiamo parlando di DNS) deve essere seguito da un punto (.).

Un piccolo promemoria:

• Usate il punto finale nei nomi di dominio nei file:
  

  hosts
  hosts.rev
  named.ca
  named.local

  
  In questi file un nome valido di dominio potrebbe essere:
  

  marketing.dominio.com.

• Non usate il punto finale nei nomi di dominio nei file
  

  named.boot
  resolv.conf

  
  In questi file il nome corretto sarebbe:
  

  marketing.dominio.com

  
  

bind9: dumping master file:...open: permission denied

Scenario:

1 server DNS primario e 1 server DNS secondario (entrambi basati su bind9)
Il master parte correttamente.
lo slave non parte e i log evidenziano un errore del genere:

Jan 31 17:42:41.799 dumping master file: /etc/named/tmp-XXXX2RSNyT: open: permission denied
Jan 31 17:42:41.799 transfer of 'mydomain.com/IN' from 192.168.3.1#53: failed while receiving responses: permission denied

Significa che lo slave ha iniziato il trasferimento delle zone dal master, pero' non riesce a scrivere i relativi file.

Soluzione:

Probabilmente avete configurato named.conf (o named.conf.local) tenendo le zone per cui il server e' slave nella stessa directory in cui tenete le zone statiche (127, ecc). Ebbene cio' e' male.
Meglio creare una directory apposita e darle i permessi giusti. Ad esempio:

mkdir /etc/bind/zones
chown bind.bind /etc/bind/zones

Ricordatevi di correggere il path dei file delle zone dinamiche per farli puntare alla nuova directory.
Rilanciate il servizio:

/etc/init.d/bind9 start

L'errore dovrebbe essere sparito.

Qualche DNS (non si sa mai)

OpenDns:

208.67.222.222
208.67.220.220

Tin.it:

62.211.69.150
212.48.4.15

Interbusiness:

151.99.125.3
151.99.125.2

Non voglio i tuoi DNS :-)

Vediamo di ottimizzare i DNS del nostro sistema.

Eseguite il comando:

sudo vi /etc/resolv.conf

Inserite le seguenti linee:

nameserver 208.67.222.222
nameserver 208.67.220.220

Opzionalmente potete inserire la linea seguente, mettendo al posto di x.x.x.x l'IP address del vostro router:

nameserver x.x.x.x

(208.67.222.222 e 208.67.220.220 sono i DNS di OpenDNS)

Per evitare che il file /etc/resolv.conf venga modificato in automatico dal DHCP o da qualche altro programma eseguire il comando:

sudo chattr +i /etc/resolv.conf

ATTENZIONE: per poter modificare in seguito /etc/resolv.conf dovete eseguire il comando:

sudo chattr -i /etc/resolv.conf

ATTENZIONE: il comando chattr +i è stato testato solo col filesystem EXT3.