{"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\/pl\/blog\/administrirovanie\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns","title":{"rendered":"Przesta\u0144 u\u017cywa\u0107 \u015bmiesznie kr\u00f3tkiego TTL dla DNS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Niskie op\u00f3\u017anienie DNS to kluczowy czynnik dla szybkiej pracy w internecie. Aby je zminimalizowa\u0107, wa\u017cne jest staranne dobranie serwer\u00f3w DNS oraz <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DNSCrypt\/dnscrypt-resolvers\/blob\/master\/v2\/relays.md\">anonimowe ryle<\/a><\/noindex>. Jednak najpierw nale\u017cy pozby\u0107 si\u0119 zb\u0119dnych zapyta\u0144.<\/p>\n<p>W\u0142a\u015bnie dlatego DNS zosta\u0142 pierwotnie stworzony jako mocno buforowany protok\u00f3\u0142. Administratorzy stref ustalaj\u0105 czas \u017cycia (TTL) dla poszczeg\u00f3lnych rekord\u00f3w, a resolverzy wykorzystuj\u0105 te informacje podczas przechowywania rekord\u00f3w w pami\u0119ci, aby unikn\u0105\u0107 zb\u0119dnego ruchu.<\/p>\n<p>Czy buforowanie jest skuteczne? Kilka lat temu moje ma\u0142e badanie pokaza\u0142o, \u017ce nie jest idealne. Przyjrzyjmy si\u0119 aktualnej sytuacji.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nAby zebra\u0107 informacje, za\u0142ata\u0142em <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/jedisct1\/encrypted-dns-server\">Encrypted DNS Server<\/a><\/noindex> w celu zachowania warto\u015bci TTL dla odpowiedzi. Okre\u015bla si\u0119 j\u0105 jako minimalne TTL jego rekord\u00f3w dla ka\u017cdego nadchodz\u0105cego zapytania. Daje to dobry przegl\u0105d rozk\u0142adu TTL rzeczywistego ruchu, a tak\u017ce uwzgl\u0119dnia popularno\u015b\u0107 poszczeg\u00f3lnych zapyta\u0144. Za\u0142atana wersja serwera dzia\u0142a\u0142a przez kilka godzin.<\/p>\n<p>Zestaw wynikowy sk\u0142ada si\u0119 z 1&nbsp;583&nbsp;579 rekord\u00f3w (name, qtype, TTL, timestamp). Oto og\u00f3lny rozk\u0142ad TTL (osi\u0105 X jest TTL w sekundach):<\/p>\n<p><img decoding=\"async\" alt=\"Przesta\u0144 u\u017cywa\u0107 \u015bmiesznie kr\u00f3tkiego TTL dla DNS\" src=\"\/wp-content\/uploads\/2019\/11\/ce19a1ceb07e1fd2f3b2284f86271eac.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Pomijaj\u0105c niewielki wzrost przy 86&nbsp;400 (g\u0142\u00f3wnie dla rekord\u00f3w SOA), do\u015b\u0107 wyra\u017anie wida\u0107, \u017ce TTL znajduj\u0105 si\u0119 w niskim zakresie. Przyjrzyjmy si\u0119 bli\u017cej:<\/p>\n<p><img decoding=\"async\" alt=\"Przesta\u0144 u\u017cywa\u0107 \u015bmiesznie kr\u00f3tkiego TTL dla DNS\" src=\"\/wp-content\/uploads\/2019\/11\/abbe48952b616e1c5bdb18c2dc103dc7.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Dobrze, TTL powy\u017cej 1 godziny nie jest statystycznie istotne. Skupmy si\u0119 wi\u0119c na zakresie 0-3600:<\/p>\n<p><img decoding=\"async\" alt=\"Przesta\u0144 u\u017cywa\u0107 \u015bmiesznie kr\u00f3tkiego TTL dla DNS\" src=\"\/wp-content\/uploads\/2019\/11\/f8a88267e1868a55d9234f66ad8c5dee.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Wi\u0119kszo\u015b\u0107 TTL od 0 do 15 minut:<\/p>\n<p><img decoding=\"async\" alt=\"Przesta\u0144 u\u017cywa\u0107 \u015bmiesznie kr\u00f3tkiego TTL dla DNS\" src=\"\/wp-content\/uploads\/2019\/11\/aab650c806097513a5924e5262211ea5.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Zdecydowana wi\u0119kszo\u015b\u0107 od 0 do 5 minut:<\/p>\n<p><img decoding=\"async\" alt=\"Przesta\u0144 u\u017cywa\u0107 \u015bmiesznie kr\u00f3tkiego TTL dla DNS\" src=\"\/wp-content\/uploads\/2019\/11\/736af4b33b745fb0d5070200fa511426.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>To nie jest zbyt dobrze.<\/p>\n<p>Kumulacyjny rozk\u0142ad jeszcze bardziej uwidacznia problem:<\/p>\n<p><img decoding=\"async\" alt=\"Przesta\u0144 u\u017cywa\u0107 \u015bmiesznie kr\u00f3tkiego TTL dla DNS\" src=\"\/wp-content\/uploads\/2019\/11\/a3a4f03188dd6dbbf4558076b827f6a5.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>W po\u0142owie odpowiedzi DNS TTL wynosi 1 minut\u0119 lub mniej, a u trzech czwartych&nbsp;\u2014 5 minut lub mniej.<\/p>\n<p>Ale poczekaj, w rzeczywisto\u015bci jest jeszcze gorzej. To TTL od serwer\u00f3w autorytatywnych. Jednak resolverzy klienccy (np. routery, lokalne bufory) otrzymuj\u0105 TTL od wy\u017cszych resolver\u00f3w, co zmniejsza si\u0119 co sekund\u0119.<\/p>\n<p>W ten spos\u00f3b klient w rzeczywisto\u015bci mo\u017ce korzysta\u0107 z ka\u017cdego rekordu \u015brednio przez po\u0142ow\u0119 oryginalnego TTL, po czym sk\u0142ada nowe zapytanie.<\/p>\n<p>Mo\u017ce te bardzo niskie TTL dotycz\u0105 tylko nietypowych zapyta\u0144, a nie popularnych stron internetowych i API? Przyjrzyjmy si\u0119:<\/p>\n<p><img decoding=\"async\" alt=\"Przesta\u0144 u\u017cywa\u0107 \u015bmiesznie kr\u00f3tkiego TTL dla DNS\" src=\"\/wp-content\/uploads\/2019\/11\/2680f9669a90f449a593edcc84ca0dc8.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>O\u015b X&nbsp;\u2014 to TTL, o\u015b Y&nbsp;\u2014 popularno\u015b\u0107 zapyta\u0144.<\/p>\n<p>Niestety, najpopularniejsze zapytania s\u0105 r\u00f3wnie\u017c najgorzej buforowane.<\/p>\n<p>Przybli\u017cmy:<\/p>\n<p><img decoding=\"async\" alt=\"Przesta\u0144 u\u017cywa\u0107 \u015bmiesznie kr\u00f3tkiego TTL dla DNS\" src=\"\/wp-content\/uploads\/2019\/11\/c670382b195169779743f43fd7b15827.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Werdykt: rzeczywi\u015bcie jest \u017ale. Ju\u017c wcze\u015bniej by\u0142o \u017ale, a teraz jest jeszcze gorzej. Kaflowanie DNS sta\u0142o si\u0119 praktycznie bezu\u017cyteczne. Poniewa\u017c coraz mniej os\u00f3b korzysta z resolvera DNS swojego dostawcy (z uzasadnionych powod\u00f3w), op\u00f3\u017anienia sta\u0142y si\u0119 bardziej zauwa\u017calne.<\/p>\n<p>Kaflowanie DNS sta\u0142o si\u0119 przydatne tylko dla tre\u015bci, do kt\u00f3rych nikt nie zagl\u0105da.<\/p>\n<p>Zauwa\u017c r\u00f3wnie\u017c, \u017ce oprogramowanie mo\u017ce <noindex><a rel=\"nofollow\" href=\"https:\/\/00f.net\/2011\/11\/17\/how-long-does-a-dns-ttl-last\/\">interpretowa\u0107 w r\u00f3\u017cny spos\u00f3b<\/a><\/noindex> niski TTL.<\/p>\n<h1>Dlaczego tak?<\/h1>\n<p>Dlaczego dla rekord\u00f3w DNS ustalany jest tak ma\u0142y TTL?<\/p>\n<ul>\n<li>Przestarza\u0142e load balancery pozosta\u0142y z ustawieniami domy\u015blnymi.<\/li>\n<li>Kr\u0105\u017c\u0105 mity, \u017ce r\u00f3wnowa\u017cenie obci\u0105\u017cenia w DNS zale\u017cy od TTL (to nieprawda&nbsp;\u2014 od czas\u00f3w Netscape Navigator klienci wybieraj\u0105 losowy adres IP z zestawu RR i transparentnie pr\u00f3buj\u0105 inny, je\u015bli nie mog\u0105 si\u0119 po\u0142\u0105czy\u0107)<\/li>\n<li>Administratorzy chc\u0105 stosowa\u0107 zmiany natychmiastowo, poniewa\u017c tak \u0142atwiej jest planowa\u0107.<\/li>\n<li>Administrator serwera DNS lub load balancera widzi swoj\u0105 rol\u0119 w skutecznym wdra\u017caniu konfiguracji, kt\u00f3rej \u017c\u0105daj\u0105 u\u017cytkownicy, a nie w przyspieszaniu dzia\u0142ania stron i us\u0142ug.<\/li>\n<li>Niskie TTL daj\u0105 spok\u00f3j ducha.<\/li>\n<li>Ludzie pocz\u0105tkowo ustalaj\u0105 niskie TTL w celu testowania i zapominaj\u0105 je p\u00f3\u017aniej zmieni\u0107.<\/li>\n<\/ul>\n<p>Nie w\u0142\u0105czy\u0142em w list\u0119 \u00abodporno\u015bci na awarie\u00bb, poniewa\u017c staje si\u0119 to coraz mniej aktualne. Je\u015bli trzeba przekierowa\u0107 u\u017cytkownik\u00f3w do innej sieci tylko w celu wy\u015bwietlenia strony z b\u0142\u0119dem, gdy wszystko inne zawiod\u0142o, to op\u00f3\u017anienie wi\u0119ksze ni\u017c 1 minuta jest zapewne dopuszczalne.<\/p>\n<p>Ponadto, minutowy TTL oznacza, \u017ce je\u015bli autorytatywne serwery DNS b\u0119d\u0105 zablokowane przez wi\u0119cej ni\u017c 1 minut\u0119, nikt inny nie b\u0119dzie m\u00f3g\u0142 uzyska\u0107 dost\u0119pu do zale\u017cnych us\u0142ug. I redundancja nie pomo\u017ce, je\u015bli przyczyn\u0105 jest b\u0142\u0105d konfiguracji lub w\u0142amanie. Z drugiej strony, przy rozs\u0105dnych TTL wielu klient\u00f3w b\u0119dzie kontynuowa\u0107 korzystanie z poprzedniej konfiguracji i nigdy niczego nie zauwa\u017c\u0105.<\/p>\n<p>W niskich TTL w du\u017cej mierze s\u0105 winne us\u0142ugi CDN i load balancery, szczeg\u00f3lnie gdy \u0142\u0105cz\u0105 CNAME z ma\u0142ymi TTL i rekordy z r\u00f3wnie ma\u0142ymi (ale niezale\u017cnymi) TTL:<\/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>Za ka\u017cdym razem, gdy wygasa CNAME lub jeden z rekord\u00f3w A, trzeba wys\u0142a\u0107 nowe zapytanie. Oba maj\u0105 30-sekundowy TTL, ale nie s\u0105 zgodne. Rzeczywisty \u015bredni TTL b\u0119dzie wynosi\u0142 15 sekund.<\/p>\n<p>Ale chwileczk\u0119! Jest jeszcze gorzej. Niekt\u00f3re resolver'y zachowuj\u0105 si\u0119 bardzo \u017ale w takiej sytuacji z dwoma po\u0142\u0105czonymi niskimi TTL:<\/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>Resolver Level3 prawdopodobnie dzia\u0142a na BIND. Je\u015bli b\u0119dziesz nadal wysy\u0142a\u0107 to zapytanie, zawsze zostanie zwr\u00f3cony TTL r\u00f3wny 1. W zasadzie, <code>raw.githubusercontent.com<\/code> nigdy nie jest buforowany.<\/p>\n<p>Oto kolejny przyk\u0142ad takiej sytuacji z bardzo popularn\u0105 domen\u0105:<\/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>Nie mniej ni\u017c trzy rekordy CNAME. Ojej. Jeden ma przyzwoity TTL, ale to zupe\u0142nie bezu\u017cyteczne. W pozosta\u0142ych CNAME pierwotny TTL wynosi 60 sekund, ale dla domen <code>akamai.net<\/code> maksymalny TTL wynosi 20 sekund, a \u017caden z nich nie jest zsynchronizowany.<\/p>\n<p>A co z domenami, kt\u00f3re ci\u0105gle sprawdzaj\u0105 urz\u0105dzenia 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>Ten sam problem, co w Firefoksie, a TTL przez wi\u0119kszo\u015b\u0107 czasu utknie na 1 sekundzie przy u\u017cyciu resolver'a 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>W rekordzie <code>safebrowsing.googleapis.com<\/code> warto\u015b\u0107 TTL wynosi 60 sekund, jak w przypadku domen Facebooka. I znowu, z perspektywy klienta, te warto\u015bci s\u0105 zmniejszane o po\u0142ow\u0119.<\/p>\n<h1>A co z ustawieniem minimalnego TTL?<\/h1>\n<p>U\u017cywaj\u0105c nazwy, rodzaju zapytania, TTL oraz pocz\u0105tkowo zapisanej znacznika czasowej, napisa\u0142em skrypt do symulacji 1,5 miliona zapyta\u0144 przechodz\u0105cych przez buforuj\u0105cy resolver, aby oceni\u0107 ilo\u015b\u0107 niepotrzebnych zapyta\u0144 wysy\u0142anych z powodu przestarza\u0142ej lokalizacji bufora.<\/p>\n<p>47,4% zapyta\u0144 zosta\u0142o dokonanych po wyga\u015bni\u0119ciu istniej\u0105cego rekordu. To nieuzasadnione wysokie.<\/p>\n<p>Jakie b\u0119d\u0105 konsekwencje dla buforowania, je\u015bli ustalony zostanie minimalny TTL?<\/p>\n<p><img decoding=\"async\" alt=\"Przesta\u0144 u\u017cywa\u0107 \u015bmiesznie kr\u00f3tkiego TTL dla DNS\" src=\"\/wp-content\/uploads\/2019\/11\/3abd417d312450519b45f66865b23763.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>O\u015b X to minimalne warto\u015bci TTL. Rekordy z pocz\u0105tkowym TTL wy\u017cszym ni\u017c ta warto\u015b\u0107 nie s\u0105 dotkni\u0119te.<\/p>\n<p>O\u015b Y to procent zapyta\u0144 od klienta, kt\u00f3ry ma ju\u017c zbuforowany rekord, ale jego okres wa\u017cno\u015bci wygas\u0142 i wysy\u0142a nowe zapytanie.<\/p>\n<p>Procent 'zb\u0119dnych' zapyta\u0144 spada z 47% do 36% przy prostej instalacji minimalnego TTL wynosz\u0105cego 5 minut. Ustalaj\u0105c minimalny TTL na 15 minut, liczba tych zapyta\u0144 spada do 29%. Minimalny TTL wynosz\u0105cy 1 godzin\u0119 zmniejsza je do 17%. Znacz\u0105ca r\u00f3\u017cnica!<\/p>\n<p>Co powiesz na to, aby nie zmienia\u0107 nic na serwerze, a zamiast tego ustawi\u0107 minimalne TTL w klienckich pami\u0119ciach DNS (routery, lokalne resolverzy)?<\/p>\n<p><img decoding=\"async\" alt=\"Przesta\u0144 u\u017cywa\u0107 \u015bmiesznie kr\u00f3tkiego TTL dla DNS\" src=\"\/wp-content\/uploads\/2019\/11\/107a2bd53797d421d65ac7260bf78dfe.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Liczba wymaganych zapyta\u0144 zmniejsza si\u0119 z 47% do 34% przy minimalnym TTL wynosz\u0105cym 5 minut, do 25% przy minimum 15 minut i do 13% przy minimum 1 godziny. Mo\u017cliwe, \u017ce optymalna warto\u015b\u0107 to 40 minut.<\/p>\n<p>Wp\u0142yw tej minimalnej zmiany jest ogromny.<\/p>\n<h1>Jakie s\u0105 konsekwencje?<\/h1>\n<p>Oczywi\u015bcie, mo\u017cna przenie\u015b\u0107 us\u0142ug\u0119 do nowego dostawcy chmurowego, na nowy serwer, now\u0105 sie\u0107, wymuszaj\u0105c na klientach u\u017cycie najnowszych rekord\u00f3w DNS. A wystarczaj\u0105co niski TTL pomaga przeprowadzi\u0107 t\u0119 zmian\u0119 p\u0142ynnie i niewidocznie. Ale przechodz\u0105c na now\u0105 infrastruktur\u0119, nikt nie oczekuje, \u017ce klienci przejd\u0105 na nowe rekordy DNS w ci\u0105gu 1, 5 lub 15 minut. Ustawienie minimalnego czasu \u017cycia na 40 minut zamiast 5 minut nie przeszkodzi u\u017cytkownikom w dost\u0119pie do us\u0142ugi.<\/p>\n<p>Jednak pozwoli to znacznie skr\u00f3ci\u0107 op\u00f3\u017anienia i zwi\u0119kszy\u0107 prywatno\u015b\u0107 oraz niezawodno\u015b\u0107, unikaj\u0105c zb\u0119dnych zapyta\u0144.<\/p>\n<p>Oczywi\u015bcie, RFC m\u00f3wi, \u017ce nale\u017cy \u015bci\u015ble przestrzega\u0107 TTL. Ale rzeczywisto\u015b\u0107 jest taka, \u017ce system DNS sta\u0142 si\u0119 zbyt nieefektywny.<\/p>\n<p>Je\u015bli pracujesz z autorytatywnymi serwerami DNS, sprawd\u017a swoje TTL. Czy naprawd\u0119 potrzebujesz takich absurdalnie niskich warto\u015bci?<\/p>\n<p>Oczywi\u015bcie, istniej\u0105 wa\u017cne powody ustalania ma\u0142ych TTL dla rekord\u00f3w DNS. Ale nie dla 75% ruchu DNS, kt\u00f3ry praktycznie si\u0119 nie zmienia.<\/p>\n<p>I je\u015bli z jakiego\u015b powodu naprawd\u0119 musisz stosowa\u0107 niskie TTL dla DNS, upewnij si\u0119, \u017ce na twojej stronie nie w\u0142\u0105czono buforowania. Z tych samych powod\u00f3w.<\/p>\n<p>Je\u015bli masz dzia\u0142aj\u0105c\u0105 lokaln\u0105 pami\u0119\u0107 podr\u0119czn\u0105 DNS, tak\u0105 jak <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dnscrypt\/dnscrypt-proxy\">dnscrypt-proxy<\/a><\/noindex>, kt\u00f3ry pozwala ustawi\u0107 minimalne TTL, korzystaj z tej funkcji. To w porz\u0105dku. Nic z\u0142ego si\u0119 nie wydarzy. Ustaw minimalne TTL na oko\u0142o 40 minut (2400 sekund) do 1 godziny. Ca\u0142kiem rozs\u0105dny zakres.<\/p>\n<p>\u0179r\u00f3d\u0142o: <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\/pl\/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=\"pl_PL\" \/>\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\/pl\/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\udd47Przesta\u0144 u\u017cywa\u0107 absurdalnie ma\u0142ego TTL dla DNS | ProHoster","description":"Niska latencja DNS to kluczowy czynnik dla szybkiej pracy w internecie.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/52324","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=52324"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/52324\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=52324"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=52324"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=52324"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}