Abbassa il TTL, prima

Questo doveva essere, in principio, un commento su un altro blog. Ma l’antispam dei commenti mi ha impedito di commentare (anche se sono tuttora sicuro che 5+8=13). Avrei voluto mandare una email all’autore, ma nelle pagine “contattami/contact me” (il blog è multilingua) c’è scritto di usare un form che io non visualizzo. E allora rispondo da qui, che avere un blog permette anche questo.

In realtà, questa è solo una scusa. Di DNS ne volevo parlare da un po’, e già un’altra occasione, oggi ieri, mi aveva spinto a fare un post sull’argomento.

Più precisamente, volevo fare un post sull’importanza per chi lavora su Internet (il mio pensiero era rivolto in particolar modo ai SEO, ma in realtà vale per molte più categorie) di conoscere il funzionamento della rete in maniera più allargata rispetto alle specializzazioni che il lavoro ci chiede. Fondamentalmente, ritengo che sia molto utile conoscere il meglio possibile i maggiori protocolli usati su Internet. A tutti i livelli del TCP/IP. ARP, ping, DNS, mail, http, https, etc: sono tutti importanti. Poi, e solo poi, potrete davvero dominare il lavoro che fate a livello di applicativi. Già che ci sono, metto pure il ricarico: usate un sistema operativo che vi dia la possibilità di capire ed imparare.

Però sono stanco e pigro, e non farò qui ora un elenco di situazioni tipiche nelle quali conoscenze di questi protocolli agevolerebbero (eufemismo) di molto il lavoro. Anche perchè l’elenco sarebbe pressochè sterminato.

E allora torno alla scusa che mi ha fatto scrivere questo post. Il mio commento doveva essere a questo post.
Leggete il post (e se non ce l’avete già, mettete pure l’rss nel vostro feed aggregator, già che ci siete).
Questo che segue, invece, è il mio commento:

dipende tutto dal TTL del DNS. prima di una migrazione da un server ad un altro sarebbe buona norma (anche se non sempre è possibile, per diversi motivi) accorciare il TTL a 24 ore (o anche meno). se prima il TTL è di una settimana, ad esempio, va portato a 24 ore e poi si può procedere alla migrazione dall’ottavo giorno. in questo modo, tutti i server del mondo vedranno il nuovo record nel giro di 24 ore dal cambio. ovviamente, dopo si può rialzare il TTL.

Comments

  1. Il commento è arrivato ed è stato pubblicato

  2. ciao Sante,
    é arrivato il trackback di questo post, ma il commento no. ovviamente non so dirti dove possa stare il problema. magari sbagliando la somma la prima volta poi ci vuole del tempo? (di fatto, al primo “submit” non ho proprio inserito numeri perché neanche ho visto il campo dell’antispam, stando sotto al “submit”).
    boh, comunque ti rispondo di lá.

  3. devo avere problemi con la matematica: ma 7+2 non fa 9?

    Error: Please press the back button and fill the required field for spam protection.

    sono costretto a continuare qui…

    io ero un sistemista, e quindi alcune cose sull’argomento, volente o nolente, le so. ovviamente, non posso darti la risposta definitiva, non gestendo i dns server ritardatari.
    posso solo immaginare che in Australia i dns non avessero i record in cache non avendo ricevuto query nei giorni precedenti. di conseguenza, nel momento in cui la query é arrivata al server dns lá giú, non avendola in cache, il server ha interrogato il dns autoritario. e questo gli ha dato il record aggiornato. i server qui invece avevano il record in cache, il TTL non era ancora scaduto, e quindi non hanno girato la richiesta al server autoritario.

    questo é quello che succede di norma. e dubito sia successo qualcosa di diverso, francamente. al massimo potresti trovare giusto qualche server dns sparso per il mondo che viola le RFC. ma non sarebbe un problema di “Italia o Australia”, quanto piú di “idiozia o meno” 🙂

  4. Ciao Stefano, prendo in prestito il tuo blog, per commentare anche io sul blog di Sante (ho il tuo stesso problema aritmetico :P)

    ———————–

    ciao, anche io quando faccio gli aggiornamenti ho qualche volta dei ritardi, ma mai di questa portata. Sei sicuro che il dns secondario si sia regolarmente allineato? Altrimenti è probabile che qualche dns prenda a caso dall’altro server la zona vecchia.

    In ogni caso mi permetto di aggiungere che non sono i server del mondo a rilevare la modifica ai tuoi dns. Così come hai scritto potrebbe sembrare che la tua informazione dns venga propagata fisicamente di server in server.

    Ciao,
    Giuseppe

  5. rispondo anche io qui, dal momento che la conversazione si è spostata e per il fatto che Stefano e Giuseppe hanno fatto una descrizione più che giusta di come vanno le cose a livello dns.
    Il problema però è proprio questo: le RFC. Mi trovo spessissimo a combattere con queste cose e quindi vi posto un paio di parametri dei server dns di cui parla Sante.
    TTL = 7200 ed expire a 1209600. Le zone sono state fatte “scattare” (per chi non mastica di sistemistica e dovesse leggere, vuol dire cambiare il seriale della zona dns per ovviare a problemi di “incomprensione” tra di dns di navigazione).
    I dns sono ovviamente autoritativi per le zone delegate.
    Il problema rilevato è stato questo: dopo circa 8 ore anche in Italia si erano propagate correttamente quasi tutte le zone, ma domenica 21/01 sembra ci sia stato un backport delle zone nei dns di navigazione di alcune compagnie telefoniche, che spesso usano invece il TTL a 3 gg, l’expire a due settimane e che usano proxare le zone.
    Specifico: non è un’accusa, solo una constatazione. Ognuno è libero di configurare come vuole la “sua roba” su internet, però poi si deve essere liberi anche di prendersi “infamate” da chi subisce qualche disservizio 😉

  6. Raimondo grazie dell’approfondimento. Ho capito il punto.
    E se come dici c’é violazione delle RFC, voglio ardentemente infamare anche io, convinto come sono che la violazione volontaria delle RFC dovrebbe essere punita con pene corporali.

  7. non posso che concordare in pieno con te, Stefano, quando parli delle conoscenze…
    e questo, secondo me, non solo per il lavoro che si va a compiere (che sarà legato a solo determinati ambiti) ma anche per capire/apprezzare/criticare costruttivamente il lavoro di altre persone con cui ci si potrebbe trovare a lavorare…

Speak Your Mind

*