{"id":52324,"date":"2019-11-06T00:00:00","date_gmt":"2019-11-05T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns"},"modified":"2021-01-02T13:04:14","modified_gmt":"2021-01-02T11:04:14","slug":"hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns","title":{"rendered":"Basta utilizzare un TTL ridicolmente basso per il DNS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Una bassa latenza DNS \u00e8 un fattore chiave per un rapido funzionamento su Internet. Per minimizzarla, \u00e8 importante selezionare attentamente i server DNS e <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DNSCrypt\/dnscrypt-resolvers\/blob\/master\/v2\/relays.md\">rilievi anonimi<\/a><\/noindex>. Ma prima di tutto \u00e8 necessario liberarsi delle richieste inutili.<\/p>\n<p>Per questo motivo, il DNS \u00e8 stato originariamente creato come protocollo altamente cacheabile. Gli amministratori delle zone impongono un tempo di vita (TTL) per singoli record e i resolver utilizzano queste informazioni quando memorizzano i record in memoria, per evitare traffico non necessario.<\/p>\n<p>La memorizzazione nella cache \u00e8 efficace? Un paio di anni fa, una mia piccola indagine ha mostrato che non \u00e8 perfetta. Diamo un'occhiata alla situazione attuale.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nPer raccogliere informazioni, ho patchato <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/jedisct1\/encrypted-dns-server\">Encrypted DNS Server<\/a><\/noindex> per mantenere il valore TTL per la risposta. Viene definito come il TTL minimo dei suoi record, per ogni richiesta in entrata. Questo fornisce una buona panoramica della distribuzione del TTL nel traffico reale, e tiene conto anche della popolarit\u00e0 di singole richieste. La versione patchata del server ha funzionato per alcune ore.<\/p>\n<p>Il set di dati risultante \u00e8 composto da 1&nbsp;583&nbsp;579 record (name, qtype, TTL, timestamp). Ecco la distribuzione generale del TTL (l'asse X rappresenta il TTL in secondi):<\/p>\n<p><img decoding=\"async\" alt=\"Basta utilizzare un TTL ridicolmente basso per il DNS\" src=\"\/wp-content\/uploads\/2019\/11\/ce19a1ceb07e1fd2f3b2284f86271eac.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>A parte un lieve picco a 86&nbsp;400 (principalmente per i record SOA), \u00e8 abbastanza evidente che i TTL si trovano in un intervallo basso. Esaminiamo da vicino:<\/p>\n<p><img decoding=\"async\" alt=\"Basta utilizzare un TTL ridicolmente basso per il DNS\" src=\"\/wp-content\/uploads\/2019\/11\/abbe48952b616e1c5bdb18c2dc103dc7.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Bene, i TTL superiori a 1 ora sono statisticamente insignificanti. Concentrati quindi sull'intervallo 0\u20133600:<\/p>\n<p><img decoding=\"async\" alt=\"Basta utilizzare un TTL ridicolmente basso per il DNS\" src=\"\/wp-content\/uploads\/2019\/11\/f8a88267e1868a55d9234f66ad8c5dee.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>La maggior parte dei TTL \u00e8 compresa tra 0 e 15 minuti:<\/p>\n<p><img decoding=\"async\" alt=\"Basta utilizzare un TTL ridicolmente basso per il DNS\" src=\"\/wp-content\/uploads\/2019\/11\/aab650c806097513a5924e5262211ea5.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>La stragrande maggioranza \u00e8 compresa tra 0 e 5 minuti:<\/p>\n<p><img decoding=\"async\" alt=\"Basta utilizzare un TTL ridicolmente basso per il DNS\" src=\"\/wp-content\/uploads\/2019\/11\/736af4b33b745fb0d5070200fa511426.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Non \u00e8 affatto bene.<\/p>\n<p>La distribuzione cumulativa rende il problema ancora pi\u00f9 evidente:<\/p>\n<p><img decoding=\"async\" alt=\"Basta utilizzare un TTL ridicolmente basso per il DNS\" src=\"\/wp-content\/uploads\/2019\/11\/a3a4f03188dd6dbbf4558076b827f6a5.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>In met\u00e0 delle risposte DNS, il TTL \u00e8 di 1 minuto o meno, mentre per tre quarti&nbsp;\u2014 5 minuti o meno.<\/p>\n<p>Ma aspetta, in realt\u00e0 tutto \u00e8 ancora peggiore. Infatti, questi sono TTL dai server autorevoli. Tuttavia, i resolver client (come router, cache locali) ottengono il TTL dai resolver superiori, che diminuisce ogni secondo.<\/p>\n<p>Pertanto, il client pu\u00f2 sostanzialmente utilizzare ogni record, in media, per met\u00e0 del TTL originale, dopodich\u00e9 invier\u00e0 una nuova richiesta.<\/p>\n<p>Forse questi TTL molto bassi riguardano solo richieste insolite, e non siti web o API popolari? Diamo un'occhiata:<\/p>\n<p><img decoding=\"async\" alt=\"Basta utilizzare un TTL ridicolmente basso per il DNS\" src=\"\/wp-content\/uploads\/2019\/11\/2680f9669a90f449a593edcc84ca0dc8.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>L'asse X&nbsp;\u00e8 il TTL, l'asse Y&nbsp;\u00e8 la popolarit\u00e0 delle richieste.<\/p>\n<p>Sfortunatamente, le richieste pi\u00f9 popolari sono anche quelle peggio salvate in cache.<\/p>\n<p>Avviciniamoci:<\/p>\n<p><img decoding=\"async\" alt=\"Basta utilizzare un TTL ridicolmente basso per il DNS\" src=\"\/wp-content\/uploads\/2019\/11\/c670382b195169779743f43fd7b15827.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Verdetto: \u00e8 davvero tutto male. Era gi\u00e0 brutto, e adesso \u00e8 anche peggio. La memorizzazione nella cache DNS \u00e8 diventata praticamente inutile. Poich\u00e9 sempre meno persone utilizzano il risolutore DNS del proprio provider (per motivi validi), l'aumento della latenza diventa pi\u00f9 evidente.<\/p>\n<p>La memorizzazione nella cache DNS \u00e8 utile solo per contenuti che nessuno visita.<\/p>\n<p>Si prega di notare che il software pu\u00f2 <noindex><a rel=\"nofollow\" href=\"https:\/\/00f.net\/2011\/11\/17\/how-long-does-a-dns-ttl-last\/\">interpretare<\/a><\/noindex> TTL bassi in modo diverso.<\/p>\n<h1>Perch\u00e9 \u00e8 cos\u00ec?<\/h1>\n<p>Perch\u00e9 per le voci DNS viene impostato un TTL cos\u00ec basso?<\/p>\n<ul>\n<li>I bilanciatori di carico obsoleti hanno mantenuto le impostazioni predefinite.<\/li>\n<li>Ci sono miti che dicono che il bilanciamento del carico DNS dipenda dal TTL (non \u00e8 cos\u00ec \u2014 sin dai tempi di Netscape Navigator, i client scelgono un indirizzo IP casuale da un insieme RR e provano in modo trasparente un altro se non riescono a connettersi)<\/li>\n<li>Gli amministratori desiderano applicare le modifiche immediatamente, poich\u00e9 \u00e8 pi\u00f9 semplice pianificare.<\/li>\n<li>L'amministratore del server DNS o del bilanciatore di carico considera come compito principale quello di implementare efficacemente la configurazione richiesta dagli utenti, e non quello di accelerare le prestazioni dei siti e dei servizi.<\/li>\n<li>Bassi TTL offrono tranquillit\u00e0.<\/li>\n<li>Le persone impostano inizialmente bassi TTL per i test e poi dimenticano di modificarli.<\/li>\n<\/ul>\n<p>Non ho incluso nella lista la 'gestione dei guasti', poich\u00e9 \u00e8 sempre meno rilevante. Se \u00e8 necessario reindirizzare gli utenti a un'altra rete solo per visualizzare una pagina di errore, quando tutto il resto \u00e8 completamente rotto, probabilmente \u00e8 accettabile una latenza superiore a 1 minuto.<\/p>\n<p>Inoltre, un TTL di un minuto significa che se i server DNS autorevoli sono bloccati per pi\u00f9 di un minuto, nessuno sar\u00e0 in grado di accedere ai servizi dipendenti. E la ridondanza non aiuter\u00e0 se la causa \u00e8 un errore di configurazione o un hack. D'altra parte, con TTL ragionevoli, molti client continueranno a utilizzare la configurazione precedente e non noteranno nulla.<\/p>\n<p>Gran parte della responsabilit\u00e0 dei bassi TTL ricade sui servizi CDN e sui bilanciatori di carico, specialmente quando combinano CNAME con bassi TTL e registrazioni con altrettanto bassi TTL (ma indipendenti):<\/p>\n<pre>$ drill raw.githubusercontent.com\nraw.githubusercontent.com.\t9\tIN\tCNAME\tgithub.map.fastly.net.\ngithub.map.fastly.net.\t20\tIN\tA\t151.101.128.133\ngithub.map.fastly.net.\t20\tIN\tA\t151.101.192.133\ngithub.map.fastly.net.\t20\tIN\tA\t151.101.0.133\ngithub.map.fastly.net.\t20\tIN\tA\t151.101.64.133<\/pre>\n<p>Ogni volta che scade un CNAME o una qualsiasi delle registrazioni A, \u00e8 necessario inviare una nuova richiesta. Entrambi hanno un TTL di 30 secondi, ma non coincidono. Il TTL medio effettivo sar\u00e0 di 15 secondi.<\/p>\n<p>Ma aspetta! La situazione \u00e8 ancora peggiore. Alcuni resolver si comportano molto male in una situazione del genere con due TTL bassi collegati:<\/p>\n<pre>$ drill raw.githubusercontent.com @4.2.2.2\nraw.githubusercontent.com.\t1\tIN\tCNAME\tgithub.map.fastly.net.\ngithub.map.fastly.net.\t1\tIN\tA\t151.101.16.133<\/pre>\n<p>Il resolver Level3 probabilmente funziona su BIND. Se continui a inviare questa richiesta, verr\u00e0 sempre restituito un TTL pari a 1. In sostanza, <code>raw.githubusercontent.com<\/code> non viene mai memorizzato nella cache.<\/p>\n<p>Ecco un altro esempio di questa situazione con un dominio molto popolare:<\/p>\n<pre>$ drill detectportal.firefox.com @1.1.1.1\ndetectportal.firefox.com.\t25\tIN\tCNAME\tdetectportal.prod.mozaws.net.\ndetectportal.prod.mozaws.net.\t26\tIN\tCNAME\tdetectportal.firefox.com-v2.edgesuite.net.\ndetectportal.firefox.com-v2.edgesuite.net.\t10668\tIN\tCNAME\ta1089.dscd.akamai.net.\na1089.dscd.akamai.net.\t10\tIN\tA\t104.123.50.106\na1089.dscd.akamai.net.\t10\tIN\tA\t104.123.50.88<\/pre>\n<p>Almeno tre registrazioni CNAME. Ahia. Una ha un TTL decente, ma \u00e8 completamente inutile. Negli altri CNAME il TTL iniziale \u00e8 di 60 secondi, ma per i domini <code>akamai.net<\/code> il TTL massimo \u00e8 di 20 secondi e nessuno di essi \u00e8 sincronizzato.<\/p>\n<p>E per quanto riguarda i domini che interpellano continuamente i dispositivi Apple?<\/p>\n<pre>$ drill 1-courier.push.apple.com @4.2.2.2\n1-courier.push.apple.com.\t1253\tIN\tCNAME\t1.courier-push-apple.com.akadns.net.\n1.courier-push-apple.com.akadns.net.\t1\tIN\tCNAME\tgb-courier-4.push-apple.com.akadns.net.\ngb-courier-4.push-apple.com.akadns.net.\t1\tIN\tA\t17.57.146.84\ngb-courier-4.push-apple.com.akadns.net.\t1\tIN\tA\t17.57.146.85<\/pre>\n<p>Lo stesso problema di Firefox, e il TTL si blocca per la maggior parte del tempo a 1 secondo utilizzando il resolver Level3.<\/p>\n<p>Dropbox?<\/p>\n<pre>$ drill client.dropbox.com @8.8.8.8\nclient.dropbox.com.\t7\tIN\tCNAME\tclient.dropbox-dns.com.\nclient.dropbox-dns.com.\t59\tIN\tA\t162.125.67.3\n\n$ drill client.dropbox.com @4.2.2.2\nclient.dropbox.com.\t1\tIN\tCNAME\tclient.dropbox-dns.com.\nclient.dropbox-dns.com.\t1\tIN\tA\t162.125.64.3<\/pre>\n<p>La registrazione <code>safebrowsing.googleapis.com<\/code> ha un valore TTL di 60 secondi, proprio come i domini di Facebook. E, di nuovo, dal punto di vista del cliente, questi valori si riducono della met\u00e0.<\/p>\n<h1>E se impostassimo un TTL minimo?<\/h1>\n<p>Utilizzando il nome, il tipo di richiesta, il TTL e il timestamp salvato inizialmente, ho scritto uno script per simulare 1,5 milioni di richieste che passano attraverso un resolver in caching, per valutare il volume di richieste inutili inviate a causa di una registrazione cache scaduta.<\/p>\n<p>Il 47,4% delle richieste \u00e8 stato effettuato dopo la scadenza di una registrazione esistente. Questo \u00e8 incredibilmente elevato.<\/p>\n<p>Quale sar\u00e0 l'impatto sul caching se impostiamo un TTL minimo?<\/p>\n<p><img decoding=\"async\" alt=\"Basta utilizzare un TTL ridicolmente basso per il DNS\" src=\"\/wp-content\/uploads\/2019\/11\/3abd417d312450519b45f66865b23763.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>L'asse X rappresenta i valori minimi di TTL. Le registrazioni con TTL iniziali superiori a questo valore non sono interessate.<\/p>\n<p>L'asse Y rappresenta la percentuale di richieste da parte di un cliente che ha gi\u00e0 una registrazione memorizzata nella cache, ma il cui termine \u00e8 scaduto e sta effettuando una nuova richiesta.<\/p>\n<p>La percentuale di richieste 'superflue' diminuisce dal 47% al 36% impostando semplicemente un TTL minimo di 5 minuti. Impostando un TTL minimo di 15 minuti, il numero di tali richieste scende al 29%. Un TTL minimo di 1 ora riduce ulteriormente il numero al 17%. Una differenza significativa!<\/p>\n<p>Che ne dici di non cambiare nulla sul lato server, ma invece di impostare TTL minimi nelle cache DNS dei clienti (router, resolver locali)?<\/p>\n<p><img decoding=\"async\" alt=\"Basta utilizzare un TTL ridicolmente basso per il DNS\" src=\"\/wp-content\/uploads\/2019\/11\/107a2bd53797d421d65ac7260bf78dfe.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Il numero di richieste necessarie diminuisce dal 47% al 34% impostando un TTL minimo di 5 minuti, al 25% con un minimo di 15 minuti e al 13% con un minimo di 1 ora. Forse il valore ottimale \u00e8 40 minuti.<\/p>\n<p>L'impatto di questa minima modifica \u00e8 enorme.<\/p>\n<h1>Quali sono le conseguenze?<\/h1>\n<p>Certo, il servizio pu\u00f2 essere trasferito a un nuovo fornitore di cloud, nuovo server, nuova rete, richiedendo ai clienti di utilizzare le ultime registrazioni DNS. E un TTL sufficientemente basso aiuta a rendere questa transizione fluida e senza intoppi. Ma con il passaggio a una nuova infrastruttura, nessuno si aspetta che i clienti passino a nuove registrazioni DNS in 1 minuto, 5 minuti o 15 minuti. Impostare un termine di vita minimo di 40 minuti invece di 5 minuti non impedir\u00e0 agli utenti di accedere al servizio.<\/p>\n<p>Tuttavia, questo consentir\u00e0 di ridurre notevolmente la latenza e migliorare la privacy e l'affidabilit\u00e0, evitando richieste non necessarie.<\/p>\n<p>Certo, le RFC dicono che bisogna rispettare rigorosamente il TTL. Ma la realt\u00e0 \u00e8 che il sistema DNS \u00e8 diventato troppo inefficiente.<\/p>\n<p>Se lavori con server DNS autoritativi, ti preghiamo di controllare i tuoi TTL. Hai davvero bisogno di valori cos\u00ec ridicolmente bassi?<\/p>\n<p>Certo, ci sono buone ragioni per impostare TTL bassi per le registrazioni DNS. Ma non per il 75% del traffico DNS che non cambia praticamente mai.<\/p>\n<p>E se per qualche motivo hai davvero bisogno di utilizzare TTL bassi per DNS, assicurati anche che la memorizzazione nella cache non sia abilitata sul tuo sito. Per le stesse ragioni.<\/p>\n<p>Se hai un cache DNS locale in esecuzione, come <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dnscrypt\/dnscrypt-proxy\">dnscrypt-proxy<\/a><\/noindex>, che consente di impostare TTL minimi, utilizza questa funzione. Va bene. Non succeder\u00e0 nulla di brutto. Imposta un TTL minimo compreso tra 40 minuti (2400 secondi) e 1 ora. \u00c8 un intervallo piuttosto ragionevole.<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/474450\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041d\u0438\u0437\u043a\u0430\u044f \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0430 DNS \u2014 \u043a\u043b\u044e\u0447\u0435\u0432\u043e\u0439 \u0444\u0430\u043a\u0442\u043e\u0440 \u0434\u043b\u044f \u0431\u044b\u0441\u0442\u0440\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442\u0435. \u0427\u0442\u043e\u0431\u044b \u0435\u0451 \u043c\u0438\u043d\u0438\u043c\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u0442\u044c, \u0432\u0430\u0436\u043d\u043e \u0442\u0449\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u043f\u043e\u0434\u043e\u0431\u0440\u0430\u0442\u044c DNS-\u0441\u0435\u0440\u0432\u0435\u0440\u044b \u0438 \u0430\u043d\u043e\u043d\u0438\u043c\u043d\u044b\u0435 \u0440\u0438\u043b\u0435\u0438. \u041d\u043e \u043f\u0435\u0440\u0432\u044b\u043c \u0434\u0435\u043b\u043e\u043c \u0441\u043b\u0435\u0434\u0443\u0435\u0442 \u0438\u0437\u0431\u0430\u0432\u0438\u0442\u044c\u0441\u044f \u043e\u0442 \u0431\u0435\u0441\u043f\u043e\u043b\u0435\u0437\u043d\u044b\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432. \u0418\u043c\u0435\u043d\u043d\u043e \u043f\u043e\u044d\u0442\u043e\u043c\u0443 DNS \u0438\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u043b\u0441\u044f \u043a\u0430\u043a \u0441\u0438\u043b\u044c\u043d\u043e \u043a\u044d\u0448\u0438\u0440\u0443\u0435\u043c\u044b\u0439 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b. \u0410\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u044b \u0437\u043e\u043d \u0443\u0441\u0442\u0430\u043d\u0430\u0432\u043b\u0438\u0432\u0430\u044e\u0442 \u0432\u0440\u0435\u043c\u044f \u0436\u0438\u0437\u043d\u0438 (TTL) \u0434\u043b\u044f \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0445 \u0437\u0430\u043f\u0438\u0441\u0435\u0439, \u0430 \u0440\u0435\u0437\u043e\u043b\u0432\u0435\u0440\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442 \u044d\u0442\u0443 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044e \u043f\u0440\u0438 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0438 \u0437\u0430\u043f\u0438\u0441\u0435\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52324","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041d\u0438\u0437\u043a\u0430\u044f \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0430 DNS \u2014 \u043a\u043b\u044e\u0447\u0435\u0432\u043e\u0439 \u0444\u0430\u043a\u0442\u043e\u0440 \u0434\u043b\u044f \u0431\u044b\u0441\u0442\u0440\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0425\u0432\u0430\u0442\u0438\u0442 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u0441\u043c\u0435\u0445\u043e\u0442\u0432\u043e\u0440\u043d\u043e \u043c\u0430\u043b\u044b\u0439 TTL \u0434\u043b\u044f DNS | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041d\u0438\u0437\u043a\u0430\u044f \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0430 DNS \u2014 \u043a\u043b\u044e\u0447\u0435\u0432\u043e\u0439 \u0444\u0430\u043a\u0442\u043e\u0440 \u0434\u043b\u044f \u0431\u044b\u0441\u0442\u0440\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-05T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2021-01-02T11:04:14+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Smetti di usare un TTL ridicolmente basso per il DNS | ProHoster","description":"Una bassa latenza DNS \u00e8 un fattore chiave per un funzionamento rapido su Internet.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0425\u0432\u0430\u0442\u0438\u0442 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u0441\u043c\u0435\u0445\u043e\u0442\u0432\u043e\u0440\u043d\u043e \u043c\u0430\u043b\u044b\u0439 TTL \u0434\u043b\u044f DNS | ProHoster","og:description":"\u041d\u0438\u0437\u043a\u0430\u044f \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0430 DNS \u2014 \u043a\u043b\u044e\u0447\u0435\u0432\u043e\u0439 \u0444\u0430\u043a\u0442\u043e\u0440 \u0434\u043b\u044f \u0431\u044b\u0441\u0442\u0440\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442\u0435.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-05T21:00:00+00:00","article:modified_time":"2021-01-02T11:04:14+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52324","title":null,"description":"","keywords":"","keyphrases":null,"primary_term":null,"canonical_url":"","og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 03:14:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:45:29","updated":"2026-01-24 03:14:21","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/52324","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=52324"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/52324\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=52324"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=52324"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=52324"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}