{"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\/en\/blog\/administrirovanie\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns","title":{"rendered":"Stop using absurdly low TTL for DNS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Low DNS latency is a key factor for fast internet performance. To minimize it, it's important to carefully select DNS servers and <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DNSCrypt\/dnscrypt-resolvers\/blob\/master\/v2\/relays.md\">anonymous relays<\/a><\/noindex>. But first, it\u2019s crucial to eliminate unnecessary queries.<\/p>\n<p>That\u2019s why DNS was initially designed as a highly cacheable protocol. Zone administrators set a time-to-live (TTL) for individual records, and resolvers use this information to store records in memory to avoid unnecessary traffic.<\/p>\n<p>Is caching effective? A couple of years ago, my small research showed that it\u2019s not perfect. Let\u2019s take a look at the current situation.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nTo gather information, I patched <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/jedisct1\/encrypted-dns-server\">Encrypted DNS Server<\/a><\/noindex> to preserve the TTL value for the response. It is defined as the minimum TTL of its records for each incoming request. This provides a good overview of the distribution of real traffic TTL, while also considering the popularity of individual queries. The patched server ran for several hours.<\/p>\n<p>The resulting dataset consists of 1,583,579 records (name, qtype, TTL, timestamp). Here\u2019s the overall distribution of TTL (the X-axis represents TTL in seconds):<\/p>\n<p><img decoding=\"async\" alt=\"Stop using absurdly low TTL for DNS\" src=\"\/wp-content\/uploads\/2019\/11\/ce19a1ceb07e1fd2f3b2284f86271eac.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Aside from a slight bump at 86,400 (mainly for SOA records), it\u2019s quite clear that the TTLs are in a low range. Let\u2019s take a closer look:<\/p>\n<p><img decoding=\"async\" alt=\"Stop using absurdly low TTL for DNS\" src=\"\/wp-content\/uploads\/2019\/11\/abbe48952b616e1c5bdb18c2dc103dc7.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Well, TTLs over 1 hour are statistically insignificant. So, let\u2019s focus on the range of 0\u20133600:<\/p>\n<p><img decoding=\"async\" alt=\"Stop using absurdly low TTL for DNS\" src=\"\/wp-content\/uploads\/2019\/11\/f8a88267e1868a55d9234f66ad8c5dee.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Most TTLs are between 0 and 15 minutes:<\/p>\n<p><img decoding=\"async\" alt=\"Stop using absurdly low TTL for DNS\" src=\"\/wp-content\/uploads\/2019\/11\/aab650c806097513a5924e5262211ea5.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>The overwhelming majority are between 0 and 5 minutes:<\/p>\n<p><img decoding=\"async\" alt=\"Stop using absurdly low TTL for DNS\" src=\"\/wp-content\/uploads\/2019\/11\/736af4b33b745fb0d5070200fa511426.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>This is not very good.<\/p>\n<p>The cumulative distribution makes the problem even more evident:<\/p>\n<p><img decoding=\"async\" alt=\"Stop using absurdly low TTL for DNS\" src=\"\/wp-content\/uploads\/2019\/11\/a3a4f03188dd6dbbf4558076b827f6a5.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>In half of the DNS responses, the TTL is 1 minute or less, and for three-quarters, it\u2019s 5 minutes or less.<\/p>\n<p>But wait, it\u2019s actually worse. This is the TTL from authoritative servers. However, client resolvers (like routers, local caches) receive TTL from upstream resolvers, and it decreases every second.<\/p>\n<p>Thus, the client can effectively use each record, on average, for half of the original TTL, after which a new request will be sent.<\/p>\n<p>Maybe these very low TTLs only concern unusual queries, not popular websites and APIs? Let\u2019s see:<\/p>\n<p><img decoding=\"async\" alt=\"Stop using absurdly low TTL for DNS\" src=\"\/wp-content\/uploads\/2019\/11\/2680f9669a90f449a593edcc84ca0dc8.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>The X-axis represents TTL, and the Y-axis represents query popularity.<\/p>\n<p>Unfortunately, the most popular queries are also the worst cached.<\/p>\n<p>Let\u2019s zoom in:<\/p>\n<p><img decoding=\"async\" alt=\"Stop using absurdly low TTL for DNS\" src=\"\/wp-content\/uploads\/2019\/11\/c670382b195169779743f43fd7b15827.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Verdict: things are indeed bad. It was already bad before, and now it has become worse. DNS caching has become almost useless. As fewer people use their provider's DNS resolver (for good reasons), the increased latency becomes more noticeable.<\/p>\n<p>DNS caching has only become useful for content that no one visits.<\/p>\n<p>Also note that software can <noindex><a rel=\"nofollow\" href=\"https:\/\/00f.net\/2011\/11\/17\/how-long-does-a-dns-ttl-last\/\">interpret low TTLs<\/a><\/noindex> differently.<\/p>\n<h1>Why is that?<\/h1>\n<p>Why is such a low TTL set for DNS records?<\/p>\n<ul>\n<li>Outdated load balancers remain with default settings.<\/li>\n<li>There are myths that DNS load balancing depends on TTL (this is not true\u2014since the days of Netscape Navigator, clients have chosen a random IP address from the RR set and transparently tried another if they couldn\u2019t connect).<\/li>\n<li>Administrators want to apply changes immediately, as it's easier to plan.<\/li>\n<li>The DNS server or load balancer administrator sees their task as effectively deploying the configuration requested by users, not speeding up the operation of websites and services.<\/li>\n<li>Low TTLs provide peace of mind.<\/li>\n<li>People initially set low TTLs for testing and then forget to change them.<\/li>\n<\/ul>\n<p>I did not include 'failover' because it is becoming less relevant. If users need to be redirected to another network just to display an error page when everything else is broken, a delay of more than 1 minute may be acceptable.<\/p>\n<p>Additionally, a minute's TTL means that if authoritative DNS servers are blocked for more than a minute, no one else will be able to access dependent services. And redundancy won't help if the cause is a configuration error or a breach. On the other hand, with reasonable TTLs, many clients will continue to use the previous configuration and will never notice anything.<\/p>\n<p>Low TTLs are largely the fault of CDN services and load balancers, especially when they combine CNAMEs with small TTLs and records with equally low (but independent) TTLs:<\/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>Every time a CNAME or any A records expire, a new request must be sent. Both have a 30-second TTL, but they do not match. The actual average TTL will be 15 seconds.<\/p>\n<p>But wait! It gets worse. Some resolvers behave very poorly in this situation with two linked low TTLs:<\/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>Level3 resolver is probably running on BIND. If you continue to send this request, it will always return a TTL of 1. Essentially, <code>raw.githubusercontent.com<\/code> is never cached.<\/p>\n<p>Here\u2019s another example of such a situation with a very popular domain:<\/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>At least three CNAME records. Ouch. One has a decent TTL, but that\u2019s completely useless. In other CNAME records, the initial TTL is 60 seconds, but for the domains <code>akamai.net<\/code> the maximum TTL is 20 seconds, and none of them are in sync.<\/p>\n<p>What about domains that constantly poll Apple devices?<\/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>The same problem as with Firefox, and the TTL will be stuck at 1 second most of the time when using the Level3 resolver.<\/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>In the record <code>safebrowsing.googleapis.com<\/code> the TTL value is 60 seconds, just like the domains of Facebook. And again, from the client\u2019s perspective, these values are halved.<\/p>\n<h1>What about setting a minimum TTL?<\/h1>\n<p>Using the name, request type, TTL, and the originally stored timestamp, I wrote a script to simulate 1.5 million requests passing through a caching resolver to estimate the volume of unnecessary requests sent due to the expiration of a cache record.<\/p>\n<p>47.4% of the requests were made after the existing record expired. This is unacceptably high.<\/p>\n<p>What will be the impact on caching if a minimum TTL is set?<\/p>\n<p><img decoding=\"async\" alt=\"Stop using absurdly low TTL for DNS\" src=\"\/wp-content\/uploads\/2019\/11\/3abd417d312450519b45f66865b23763.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>The X-axis represents the minimum TTL values. Records with original TTLs above this value are unaffected.<\/p>\n<p>The Y-axis shows the percentage of requests from a client that already has a cached record, but its lifespan has expired, and they are making a new request.<\/p>\n<p>The share of 'unnecessary' requests decreases from 47% to 36% by simply setting a minimum TTL of 5 minutes. Setting a minimum TTL of 15 minutes reduces this number to 29%. A minimum TTL of 1 hour lowers it to 17%. A significant difference!<\/p>\n<p>How about changing nothing on the server side, but instead setting minimum TTLs in client DNS caches (routers, local resolvers)?<\/p>\n<p><img decoding=\"async\" alt=\"Stop using absurdly low TTL for DNS\" src=\"\/wp-content\/uploads\/2019\/11\/107a2bd53797d421d65ac7260bf78dfe.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>The number of required requests drops from 47% to 34% with a minimum TTL of 5 minutes, to 25% with a minimum of 15 minutes, and to 13% with a minimum of 1 hour. Perhaps the optimal value is 40 minutes.<\/p>\n<p>The impact of this minimal change is enormous.<\/p>\n<h1>What are the implications?<\/h1>\n<p>Of course, a service can be switched to a new cloud provider, a new server, or a new network, requiring clients to use the latest DNS records. And a sufficiently low TTL helps to make such a transition smooth and seamless. But with a switch to a new infrastructure, no one expects clients to update their DNS records within 1 minute, 5 minutes, or 15 minutes. Setting a minimum TTL of 40 minutes instead of 5 minutes does not hinder users from accessing the service.<\/p>\n<p>However, it will significantly reduce latency and enhance privacy and reliability by avoiding unnecessary requests.<\/p>\n<p>Of course, the RFCs state that TTL must be strictly adhered to. But the reality is that the DNS system has become too inefficient.<\/p>\n<p>If you are working with authoritative DNS servers, please check your TTLs. Do you really need such ridiculously low values?<\/p>\n<p>Sure, there are compelling reasons to set low TTLs for DNS records. But not for 75% of DNS traffic that hardly changes.<\/p>\n<p>And if for some reason you really need to use low TTLs for DNS, make sure that caching is not enabled on your site. For the same reasons.<\/p>\n<p>If you have a local DNS cache running, such as <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dnscrypt\/dnscrypt-proxy\">dnscrypt-proxy<\/a><\/noindex>, which allows setting a minimum TTL, use this feature. It\u2019s fine. Nothing bad will happen. Set the minimum TTL somewhere between 40 minutes (2400 seconds) and 1 hour. A perfectly reasonable range.<\/p>\n<p>Source: <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.2 - 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\/en\/blog\/administrirovanie\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\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\/en\/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\udd47Stop using an absurdly low TTL for DNS | ProHoster","description":"Low DNS latency is a key factor for fast internet performance.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","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\/en\/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\/en\/wp-json\/wp\/v2\/posts\/52324","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=52324"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/52324\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=52324"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=52324"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=52324"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}