Quanto può essere fragile l’infrastruttura che regge metà del web? Se pensavate che il problema fossero solo i server che esplodono perché troppi bot la caricano di traffico, preparatevi a rimettervi l’anello al dito.

Recentemente è saltato fuori un segnale d’allarme che ha fatto sobbalzare i monitor di chiunque monitori le zone DNS: il TLD .de sembra essere andato offline, o perlomeno non raggiungibile, con un sospetto colpevole molto specifico: DNSSEC. Per chi non mastica protocolli di rete tutto il giorno, DNSSEC è quel sistema che serve a garantire che la risposta che ricevi dal DNS non sia stata manipolata da qualche tizio in mezzo al percorso. Suona bene, no? Sicuro, protetto, professionale.

Il problema è che quando configuri queste ‘catene di fiducia’ e qualcosa va storto — un record non aggiornato, una firma scaduta o una firma che non torna con la chiave pubblica — il sistema non si limita a dirti ‘ehi, c’è un errore’. No, il sistema decide che la zona è invalida e, di conseguenza, tutto ciò che sta sotto scompare nel nulla. Praticamente, nel tentativo di evitare un attacco man-in-the-middle, abbiamo creato un blackout totale per milioni di utenti. È il classico paradosso della sicurezza: abbiamo costruito un lucchetto così complicato che, se la chiave si incastra un millimetro, rimaniamo tutti fuori di casa.

Da smanettone, la cosa mi fa riflettere su quanto siamo diventati dipendenti da astrazioni che non controlliamo più. Noi che passiamo le notti a far girare script in Python o a ottimizzare il percorso di un utensile su una CNC, siamo abituati al concetto di ‘fail-safe’. Ma qui siamo nel campo del ‘fail-deadly’. Se sbagli un parametro in un file di configurazione di un router, magari perdi la connessione; se sbagli un passaggio nella catena DNSSEC del TLD, la Germania digitale smette di rispondere.

Per noi che amiamo il controllo totale, questo è un promemoria brutale. Non basta che il codice funzioni o che il modellatore 3D sia preciso; bisogna che l’intera infrastruttura sottostante sia resiliente. Questo episodio ci ricorda che la complessità è un debito tecnico che paghiamo con gli interessi sotto forma di instabilità. Spero che i responsabili di Verisign e dei registri tedeschi abbiano già fixato tutto, perché la prossima volta che il .de sparisce, non sarà solo un log su Hacker News a scosso, ma un caos di siti introvabili.

In breve: meno hype sulla ‘sicurezza infallibile’ e più attenzione alla gestione degli errori. Perché la sicurezza che rompe le scatole è solo un altro modo per fare un Denial of Service da soli.

Source: .de TLD offline due to DNSSEC?

E se vi dicessi che un semplice aggiornamento di ottimizzazione ha quasi mandato in tilt Internet? Non è un attacco hacker, non è un blackout, è solo un pollo che esce dall’uovo nel posto sbagliato.

Sì, avete capito bene. Parliamo di DNS, di record CNAME e A, e di come un cambio di ordine in una risposta DNS abbia creato problemi a chi non si aspettava che l’ordine contasse. Cloudflare ha scoperto che alcuni client DNS si aspettano i CNAME prima di tutto il resto, e quando l’ordine è cambiato… boom, problemi di risoluzione.

Ma partiamo dall’inizio. I record DNS sono un po’ come le pagine gialle del web: ti dicono dove trovare un dominio. L’A record è il classico “qui c’è l’IP”, mentre il CNAME è un alias, un “vai a vedere lì” che punta a un altro record. Niente di complicato, finché non inizi a mescolare l’ordine.

Il problema è che il protocollo DNS, vecchio di 40 anni, non specifica chiaramente l’ordine in cui i record devono apparire. È come se il manuale di istruzioni della LEGO dicesse “mettete insieme i pezzi, ma non vi diciamo in che ordine”. Funziona finché qualcuno non prova a fare il furbo e cambia le regole.

Per noi smanettoni, la lezione è semplice: quando si gioca con i DNS, non date nulla per scontato. Anche le cose più banali, come l’ordine dei record, possono diventare un problema. E se siete quelli che amano smanettare con i propri DNS locali, fate attenzione a come li configurate: potreste scoprire che il vostro setup perfettamente funzionante si rompe perché un client DNS si aspetta qualcosa di diverso.

E poi c’è la questione del vendor lock-in. Cloudflare è uno dei giganti del DNS, e quando loro cambiano qualcosa, il mondo intero trema. Sarebbe bello avere standard più chiari e meno dipendenza da chi ha il controllo del DNS globale. Ma finché non succederà, ci toccherà fare attenzione a ogni singolo aggiornamento.

In conclusione, il DNS è come un pollo che esce dall’uovo: sembra semplice finché non inizi a guardare i dettagli. E i dettagli, a volte, fanno la differenza tra un sistema che funziona e uno che va in tilt. Quindi, la prossima volta che configurate un record DNS, ricordate: l’ordine conta, anche se non dovrebbe.

Source: What came first: the CNAME or the A record?

Hai mai avuto un incubo in cui il tuo server preferito smette di rispondere perché il DNS ha deciso di fare i capricci? Beh, è successo davvero. E la colpa è di un pollo che esce dall’uovo nel modo sbagliato.

Sì, avete capito bene. Un aggiornamento di Cloudflare a 1.1.1.1 ha causato una serie di problemi di risoluzione DNS perché ha cambiato l’ordine dei record nelle risposte. Il colpo di scena? Alcuni client DNS si aspettano che i CNAME vengano prima di tutto il resto, e quando l’ordine è cambiato… caos totale.

Per chi non vive nel mondo magico dei record DNS, facciamo un passo indietro. Un CNAME è come un alias: dice “questa cosa si chiama così, ma in realtà è quella là”. Un A record, invece, è come un indirizzo di casa: “questa cosa sta qui, a questo IP”. Il problema è che, per qualche motivo, alcuni software si sono abituati a vedere prima il CNAME e poi tutto il resto, e quando Cloudflare ha cambiato l’ordine per ottimizzare la memoria, hanno iniziato a fare i dispettosi.

E qui arriva la parte più divertente: il protocollo DNS ha 40 anni e nessuno si è mai preoccupato di definire un ordine “corretto” per i record. È come se avessimo scritto un manuale di istruzioni senza dire se il pollo viene prima dell’uovo o viceversa. Risultato? Ogni implementazione fa un po’ come gli pare.

Per noi smanettoni, questo significa due cose:

1. **Testate sempre i vostri DNS con diversi client**: se usate software custom o vecchi client, potrebbe essere il momento di fare qualche test. Mai dare per scontato che tutto funzioni come dovrebbe.

2. **Documentatevi sulle specifiche**: se state sviluppando qualcosa che interagisce con il DNS, leggete le RFC (sì, quelle noiosissime specifiche tecniche) e testate ogni scenario possibile. Perché sì, qualche sviluppatore da qualche parte ha deciso che l’ordine dei record fosse importante, e ora dobbiamo conviverci.

E poi, ammettiamolo: è sempre un po’ divertente quando i giganti del web si ritrovano a risolvere problemi che avrebbero potuto evitare con un po’ più di attenzione ai dettagli. Magari la prossima volta scriveranno meglio i manuali.

Ah, e se avete un server DNS che fa i capricci, controllate l’ordine dei record. Potrebbe essere la differenza tra un pollo che esce dall’uovo e un uovo che non si schiude mai.

Source: What came first: the CNAME or the A record?

Ecco una notizia che fa più rumore di un Arduino che va in corto circuito: Cloudflare si è appena beccata una multa da 14 milioni di euro in Italia. Il reato? Non aver bloccato automaticamente siti pirata sui suoi DNS pubblici.

Sì, avete capito bene. Il governo italiano ha deciso che un provider di infrastruttura internet dovrebbe anche fare da poliziotto, altrimenti sono cazzi amari.

Per chi non lo sapesse, Cloudflare offre un servizio DNS pubblico (1.1.1.1) che promette privacy e velocità. Ma secondo l’Italia, questo servizio dovrebbe anche filtrare contenuti illegali. E quando Cloudflare ha detto “No, grazie”, ecco la multa.

Da smanettone, la cosa mi fa venire in mente una domanda: ma siamo sicuri che sia il caso di trasformare ogni provider internet in un censore? E soprattutto, cosa significa per noi che ci piace smanettare con reti e server?

Prima di tutto, dobbiamo capire che questa multa non è un attacco a Cloudflare in sé, ma un tentativo di far rispettare leggi locali su contenuti illegali. Il problema è che, come spesso accade, la soluzione proposta è tecnologicamente discutibile.

Un provider DNS è come un centralino telefonico: ti connette alla rete, ma non è responsabile di cosa dici al telefono. Chiedere a un DNS di filtrare contenuti è come chiedere a un centralino di bloccare le chiamate sospette. Non è il suo lavoro, e alla fine rischi di creare un sistema fragile e centralizzato.

Per noi maker, la questione è ancora più spinosa. Se ogni provider deve filtrare contenuti, chi ci garantisce che non verranno bloccati anche progetti legittimi? E se domani qualche governo decidesse di bloccare siti di hacking etico o progetti open-source perché “troppo rischiosi”?

Inoltre, questa storia solleva un altro problema: la privacy. Se i DNS devono filtrare contenuti, qualcuno da qualche parte dovrà tenere traccia di cosa bloccano e perché. E noi sappiamo bene che dati di questo tipo sono un tesoro per chiunque voglia fare sorveglianza di massa.

Ma non tutto è negativo. Questa multa potrebbe spingere Cloudflare a innovare ancora di più. Magari vedremo nuovi servizi di DNS più privati e decentralizzati, o strumenti per noi maker per bypassare questi filtri in modo etico.

In ogni caso, la lezione da imparare è sempre la stessa: quando la tecnologia incontra la politica, le cose si complicano. E noi, come community di smanettoni, dobbiamo stare attenti a non perdere la nostra indipendenza.

Quindi, cosa possiamo fare? Per ora, teniamo d’occhio la situazione e continuiamo a sperimentare con soluzioni alternative. E se qualcuno vi dice che il DNS dovrebbe fare il censore, mandatelo a leggere un po’ di RFC sul funzionamento di internet.

Nel frattempo, continuate a smanettare, a costruire progetti fighi e, soprattutto, a non farvi bloccare da nessuno. Buon hacking a tutti!

Source: Cloudflare CEO on the Italy fines