Usare un Content Delivery Network (CDN): come e perché

Nota Bene: Questo articolo non è più aggiornato da almeno 6 mesi perciò verifica le informazioni contenute che potrebbero essere obsolete.

Oggi analizziamo i motivi per cui è opportuno configurare e attivare una CDN per distribuire meglio i contenuti presenti sul nostro sito web.

Un Content Delivery Network può fornire una marcia in più ad un sito internet, grazie ad un sistema di caching reverse proxy, ottimizzandone così la velocità, l’esperienza utente e conseguentemente la SEO on-site grazie ad una migliore indicizzazione dei contenuti presenti sul dominio da parte dei motori di ricerca.

Naturalmente i visitatori non si renderanno conto del fatto che viene servita loro una copia del sito e non il contenuto originale.

Sommario

Scopriamo come e perchè configurare una #CDN con Cloudflare su un nostro sito webCONDIVIDI IL TWEET

Cos’è un Content Delivery Network

Una CDN è un  sistema di server, collegati fra loro tramite internet, che dialogano e collaborano in maniera tale da realizzare un sistema distribuito per la fornitura di contenuti all’utenza.

Quando un utente richiede un contenuto, dietro ad una CDN, il sistema instraderà la richiesta verso il nodo più vicino in modo da risparmiare tempo nel trasferimento dei dati.

In particolare una CDN è utile quando i nostri contenuti devono essere distribuiti in tutto il mondo o quando il server sui cui è ospitato il nostro sito è distante dal target del sito stesso.

Un ulteriore servizio che può fornire una CDN è quello di mitigare attacchi DDos, che vengono distribuiti sull’intera rete non sovraccaricando il server che ospita il nostro sito fino a farlo collassare e di mantenere online il nostro sito, fornendo una copia cache, quando il server su cui è ospitato collassa o viene spento per manutenzione o problemi tecnici.

Cloudflare

Una delle più famose CDN è Cloudflare, una impresa statunitense creata nel 2009 che, oltre a fornire un servizio di Content Delivery Network offre diversi servizi accessori.

In questi ultimi mesi Cloudflare ha sviluppato un nuovo datacenter a Milano, in Italia, fornendo così un nodo veloce e vicino a tutta l’utenza della penisola.

Cloudflare offre in maniera gratuita il servizio basico, che andremo ad analizzare in questo articolo, ma con una spesa di 20 €/mese potremo attivare un servizio di ottimizzazione dedicato per i dispositivi mobile, in modo da incrementare la velocità di caricamento delle pagine di un sito web quando richieste da smartphone o tablet.

Perché configurare una CDN

Come abbiamo visto è utile configurare una CDN per:

  • distribuire meglio i nostri contenuti nel mondo;
  • migliorare la sicurezza del nostro sito grazie al firewall integrato, se compreso nella CDN (Cloudflare offre questo servizio);
  • proteggere il nostro sito da attacchi DDos;
  • migliorare globalmente la SEO del nostro sito, grazie al incremento delle perfomance delle nostre pagine;

Classica comunicazione tra client e sito

comunicazione sito client

Comunicazione tra client e sito dietro a CDN

comunicazione sito cdn client

Come configurare una CDN su Cloudflare

Vediamo insieme come configurare una CDN mediante Cloudflare e il suo servizio gratuito.

Creazione Account

Come prima cosa è necessario creare un account su Cloudflare, che ci permetterà di gestire uno o più siti.

Visitiamo quindi la pagina di registrazione che richiede nome utente e password per l’account. A seguito di questa azione riceveremo una mail con un codice per attivare l’account.

Aggiunta di un sito

Dopo aver fatto accesso al servizio di CDN mediante il nostro nuovo e fiammante account aggiungiamo un sito al pannello. Se necessario è possibile aggiungere più di un sito, separando i domini dalla virgola.

aggiungi sito

Il dominio che vogliamo aggiungere va inserito nella forma pura, ossia nomedominio.tld. Nel caso di www.posizionamento-seo.com inserirò quindi posizionamento-seo.com.

Premiamo quindi sul bottone Begin Scan e aspettiamo che il servizio faccia la scansione del nostro dominio.

scansione sito

Una volta che il servizio ha completato la scansione del nostro dominio premiamo sul bottone Continue Setup.

aggiungi sito cdn

Nella pagina che comparirà dobbiamo poi selezionare per quali servizi attivare la nostra CDN.

Per aiutarci Cloudflare ci mostra i servizi che ha rilevato sul nostro server, a seguito di scansione automatica, per cui offre dei consigli di attivazione o meno della Content Delivery Network.

selezione DNS record

Di nostro possiamo modificare questa preselezione automatica premendo sull’icona della nuvoletta con la freccia. Come è facilmente comprensibile nuvola grigia e freccia che la oltrepassa vuol dire servizio NON filtrato dalla CDN, mentre il contrario (CDN attiva) è contrassegnato dall’icona della nuova arancione con freccia passante.

Di suo Cloudflare non attiva il servizio sui protocolli imappopsmtp e webmail, tutti relativi alla gestione della posta elettronica.

In caso di configurazioni particolari e non rilevate automaticamente possiamo poi aggiungere dei record per poi selezionare se attivare o meno il servizio di CDN.

Una volta effettuata la nostra selezione premiamo sul bottone Continue, in fondo alla pagina.

selezione piano cdn

Selezioniamo poi il piano che vogliamo attivare, nel mio caso per questo tutorial ho scelto quello gratuito. Naturalmente in seguito potremo passare ai piani a pagamento, nel caso ci sia necessità di investire budget in maggiore velocità e performance per il nostro sito web. Premiamo nuovamente sul bottone Continue.

Cloudflare ci dirà quindi che è necessario modificare i DNS del nostro dominio affinché il servizio possa funzionare.

Modifica dei DNS

Siamo arrivati al passaggio più “complicato”: la modifica dei DNS del nostro sito. Questa operazione è necessaria in quanto permetterà all’utenza di transitare da una copia cache delle pagine del nostro sito, presente su un nodo di cloudflare, in fase di richiesta di un nostro contenuto.

La modifica dei DNS varia da host ad host e per effettuarla è necessario intervenire nel pannello con cui abbiamo configurato il nostro dominio per farlo puntare al nostro server. Non è quindi una modifica da effettuare sul sito.

Cloudflare ci viene in aiuto, infatti per gli host più utilizzati nel mondo fornisce un tutorial alla modifica dei DNS.

dns cloudflare

E’ questo il caso di gandi.net, il provider su cui ho configurato il dominio di posizionamento-seo.com, che utilizzerò come esempio in questo articolo. Per gli altri host dovrete fare riferimento al vostro provider o nel caso sia fornita alle linee guida presenti su Cloudflare.

Come cambiare i DNS su Gandi.net

Gandi.net, di cui ho parlato di sfuggita in alcuni miei precedenti articoli, offre un pannello semplificato per la gestione dei DNS e di cui Cloudflare presenta degli screenshot per spiegare nel dettaglio la procedura.

La ripropongo qui, riscritta da me in Italiano.

Dopo aver fatto accesso alla piattaforma di gestione del nostro host, con una utenza con diritti di modifica in relazione al dominio di cui vogliamo aggiornare i DNS apriamo la schermata relativa al dominio.

dns gandi

Sulla sinistra, nella zona dedicata ai Name servers premiamo su Modify servers.

gandi update dns

Si aprirà così una nuova pagina con i DNS che stiamo utilizzando in questo momento e che, se non abbiamo già modificato in passato, sono quelli standard di Gandi.

a.dns.gandi.net
b.dns.gandi.net
c.dns.gandi.net

Inseriamo quindi i DNS proposti da Cloudflare e premiamo su Submit per effettuare l’aggiornamento.

drew.nd.cloudflare.com
tia.nd.cloudflare.com

gandi update dns cloudflare
gandi dns change

Ritorneremo così nella schermata procedente, ma un box ci dirà che i DNS si stanno aggiornando. La procedura impiegherà qualche minuto, ma attenzione la propagazione effettiva dei DNS avverrà solamente dopo 24 ore, periodo durante il quale il sito potrebbe non venire visualizzato.  In realtà questoproblema non dovrebbe sussitere perché ci penserà Cloudflare a far visualizzare una copia del nostro sito mentre i DNS si propagano.

Torniamo quindi sul pannello di gestione del nostro sito su Cloudflare, dove vedremo che la CDN è in attesa di poter utilizzare i nuovi DNS e se vogliamo sfidare la sorte, possiamo provare a forzare un nuovo controllo sui DNS in uso premendo sul bottone Recheck Nameservers.

nuova analisi dns cdn
successo configurazione dns-cloudflare

Una volta che Cloudflare si aggancerà ai nuovi DNS del nostro dominio potremo incominciare a configurare il nostro account.

Configurazione dell’account di Cloudflare

In particolare se, come nel mio caso, il nostro dominio ha un certificato SSL proprietarioè necessario configurare bene la sezione relativa alla Criptazione. Per questo, nel pannello di Cloudflare, premiamo su Cripto. Per far si che i nostri certificati SSL non vengano filtrati dalla CDN, rendendo il nostro sito NON visualizzabile per colpa di un errore SSL sarà necessario selezionare nel box dedicato alla SSL come tipo di comunicazione di criptazione, nella select a discesa presente, l’impostazione Full (strict). Il resto lo lasciamo come di default, quindi:

  • HTTP Strict Transport Security (HSTS) non abilitata (il bottone Enable HSTS deve rimanere blu)
  • Authenticated Origin Pulls lo lasciamo su Off
  • in ultimo non è necessario creare dei certificati con Cloudflare
ssl gandi cloudflare
CDN certificati attivi

Dopo che Cloudflare avrà analizzato i nostri certificati SSL nel pannello, nella sezione dedicata a SSL, comparirà una label verde con scritto ACTIVE CERTIFICATE e più in basso potremo vedere i certificati acquisiti.

SSL e Cloudflare

Anche nella versione gratuita Cloudflare permette di creare gratuitamente dei certificati SSL per il nostro dominio. Sappiate che è possibile utilizzare questa opzione per crittare la comunicazione con il nostro dominio e trasformare il nostro dominio in HTTPS, al fine di migliorare il ranking sul motore di ricerca Google.

In un prossimo articolo vedremo nel dettaglio la configurazione di Cloudflare per il piano free.

Analisi dei risultati

Analizziamo ora come è cambiata la perfomance di questo sito a seguito della configurazione di una CDN.

Analisi prima della configurazione della CDN

analisi velocita no cdn

Utilizzo per effettuare le analisi Web Page Test che oltre ad analizzare come vengono serviti i byte del mio sito nei differenti momenti mi segnala la presenza della CDN. Entrambi i test sono stati condotti facendo uscire la connessione da un server in Irlanda e simulando l’uso di browser Chrome dietro a connessione DSL.

Analisi dopo la configurazione della CDN

analisi velocita cdn

Come potete vedere nello screenshot qui sopra oltre al fatto che viene segnalata l’effettiva presenza della CDN a servire i miei contenuti sono notevolmente scesi, a livello di secondi:

  • il tempo di caricamento;
  • il tempo in cui viene servito il primo byte;
  • il tempo di caricamento del primo byte;
  • il tempo di carimento dell’intero documento;

Da notare che non viene più segnalata la presenza della compressione gzip delle immagini, pur se presente e configurata sul server.

What is a DMARC record and how do I create it on DNS server?

Command to verify the DNS record : dig _dmarc.saic.it any

Description

Email Security: What is DMARC record and how to create it on DNS server.

Prerequisites:

Before creating DMARC records it’s a good idea to test DKIM and SPF. Testing can be found here: https://dmarcguide.globalcyberalliance.org/#/

Resolution

Creating a DMARC record

Create the record
DMARC is designed to give receivers of email better judgment control  based on sending domain reputations.  It provides a platform where the sending side can publish policies to improve effectiveness against spam and phishing, in effect building domain reputations. This helps to provide guidelines on how to address messages that do not align according to those policies published by the sending domains.
  
DMARC was aimed at:
Reducing false negatives
Provide authentication reporting
Apply sender policies at the receiving end
Reduce phishing
Be scalable
  
In order to get started with DMARC, the sending domain needs to have an SPF and DKIM record published. Once the SPF and DKIM records are in place, you can configure DMARC by adding policies to your domain’s TXT records (the same way in which you published your SPF and DKIM records).  Your TXT record name should read something similar to “_dmarc.your_domain.com.”  Please replace the “your_domain.com” with your own domain.
 
As DMARC policies are published as TXT records, it defines what an email receiver should do with non-aligned mail it receives.

A DMARC record’s name when creating a TXT record is “_dmarc” which forms a TXT record such as _dmarc.mydomain.com or _dmarc.mydomain.net etc

An external guide/wizard on creating DMARC records: https://dmarcguide.globalcyberalliance.org/#/dmarc/

 Example:
“v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com”  
 
 In this scenario, the sender defines the policy as such that the receiver outright rejects all non-aligned messages and sends a report about the rejections to a specific email address. If the sender were to use the “quarantine” setting in the policy, it would look like:
 
“v=DMARC1;p=quarantine;pct=100;rua=mailto:postmaster@dmarcdomain.com” 

and would request the action to quarantine on the receiving end of the message. In the next example, if a message claims to be from your domain.com and fails DMARC, no action is taken. Instead, these messages will then show up in your daily aggregate report sent to
 
 “v=DMARC1; p=none; rua=mailto:postmaster@your_domain.com” 

Here is a sample where the message fails DMARC, then quarantines it 5% of the time.
 
 “v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@your_domain.com” 

In this sample, the policy is set to reject the message 100% of the time and send the daily report to the specified address of dmarc@your_domain.com.
 
“v=DMARC1; p=reject; rua=mailto:postmaster@your_domain.com, mailto:dmarc@your_domain.com”
  
 DMARC records follow the extensible “tag-value” syntax for DNS-based key records defined in DKIM. The following chart illustrates some of the available tags:
  
Common tags used in DMARC TXT records:
 

TagName   RequiredPurposeSample
v             requiredProtocol Versionv=DMARC1
prequiredProtocol for Domainp=quarantine
pctoptional% of message subjected to filteringpct=20
ruaoptionalReporting UTIof aggregate reportrua=mailto:postmstr@domain.com
spoptionalPolicy for subdomains of the domainsp=r
aspfoptionalAlignment mode for spfaspf=r 
 


Only the v (version) and p (policy) tags are required. Three possible policy settings are available:

  • none – Take no action. Only log the affected messages in the daily report.
  • quarantine – Mark affected messages as spam.
  • reject – Cancel the message at the SMTP layer.  

 
Alignment mode refers to the analysis which sender records are compared to SPF and DKIM signatures. There are two possible values being presented, relaxed “r” or strict “s”. Relaxed allows for partial matches such as subdomains while strict requires an exact match.
Be sure to include an email address with the optional rua tag to have the daily reports sent to that address.
 
Example report
The daily reports are sent in XML format. They provide feedback informing you of the sending source IP addresses that have been sending out on your domain’s behalf.  This helps in determining which sources are valid or not. As a result, this assists in more effective deployment of your SPF and DKIM records.
Here is an example of a daily aggregate report. The judgement result is shown along with the source IP addresses and the action taken.
  
<record>
 <row>
 <source_ip>207.126.144.129</source_ip>
 <count>1</count>
 <policy_evaluated>
 <disposition>none</disposition>
 </policy_evaluated>
 </row>
 <identities>
 <header_from>stefanomail.com</header_from>
 </identities>
 <auth_results>
 <dkim>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 <human_result></human_result>
 </dkim>
 <spf>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 </spf>
 </auth_results>
 </record>
 <record>
 <row>
 <source_ip>207.126.144.131</source_ip>
 <count>1</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <reason>
 <type>forwarded</type>
 <comment></comment>
 </reason>
 </policy_evaluated>
 </row>
 <identities>
 <header_from>stefanomail.com</header_from>
 </identities>
 <auth_results>
 <dkim>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 <human_result></human_result>
 </dkim>
 <spf>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 </spf>
 </auth_results>
 </record> 
 
Here is an example of how to specify the optional size limit argument and set it to 10 MB.
“v=DMARC1; p=none; rua=mailto:postmaster@your_domain.com!10m”
  
Deploy slowly 
As the DMARC specification takes into consideration that scaling out the deployment may be challenging for some organizations to do at once, there are a number of built-in methods for “throttling” the DMARC processing so full deployment can be done in increments over time.

  • First thing to do is monitor your traffic and reports. Assess where your vulnerabilities are (where messages are being delivered without being digitally signed or are coming from invalid source IP addresses) and address them through SPF and DKIM records.
  • As you monitor your daily aggregate reports and get to a place where you are comfortable with the results, you can change the action on your policies to start to quarantine. You do this by changing your TXT record using DMARC to use the “quarantine” action. Continue to monitor your daily reports
  • Once you have been monitoring your traffic and daily reports for some time and feel comfortable with the sources seen sending traffic on behalf of your domain and they are all being digitally signed, you can move forward with the next step in changing the policy to use the “reject” tag to fully deploy DMARC in its entirety. Monitoring your reports and your spamfeed is an essential part of maintenance for DMARC accuracy.

Also worth noting, the optional pct tag can be used to sample your DMARC deployment in increments as well. Since 100% is the default, passing “pct=20” in your DMARC TXT record results in one-fifth of all messages affected by the policy actually receiving the disposition instead of all of them. This setting is especially useful once you elect to quarantine and reject mail. Start with a lower percent to begin with and increase it every few days.
So a conservative deployment cycle would resemble:

  1. Monitor all.
  2. Quarantine 1%.
  3. Quarantine 5%.
  4. Quarantine 10%.
  5. Quarantine 25%.
  6. Quarantine 50%.
  7. Quarantine all.
  8. Reject 1%.
  9. Reject 5%.
  10. Reject 10%.
  11. Reject 25%.
  12. Reject 50%.
  13. Reject all.

When you are ready to complete the DMARC deployment, remove the percentages from your policies so that the full action of “quarantine” and “reject” is now functioning at 100%. As always, monitor your daily reports.
Recap DMARC deployment.

  1. Deploy SPF and DKIM records for your domain.
  2. Confirm that all sending MTA’s on behalf of the specified domain are aligning the appropriate identifiers appropriately.
  3. Publish DMARC record using the “monitor” flag and specify rua value to receive daily aggregate reports.
  4. Assess vulnerabilities from the daily reports and adjust SPF and DKIM accordingly. Make changes to your mailstreams as needed.
  5. Change DMARC policy flags to “quarantine” and then eventually to “reject” as you see fit.

For further reference, you can go to:
http://dmarc.org/overview.html
http://dmarc.org/specification.html