{"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\/es\/blog\/administrirovanie\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns","title":{"rendered":"Deja de usar un TTL rid\u00edculamente bajo para DNS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Una baja latencia de DNS es un factor clave para un buen rendimiento en internet. Para minimizarla, es importante elegir cuidadosamente los servidores DNS y <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DNSCrypt\/dnscrypt-resolvers\/blob\/master\/v2\/relays.md\">reenv\u00edos an\u00f3nimos<\/a><\/noindex>. Pero lo primero es deshacerse de las consultas innecesarias.<\/p>\n<p>Por eso, el DNS fue dise\u00f1ado originalmente como un protocolo altamente cacheable. Los administradores de zonas establecen el tiempo de vida (TTL) para cada registro, y los resolutores utilizan esta informaci\u00f3n al almacenar registros en memoria para evitar tr\u00e1fico innecesario.<\/p>\n<p>\u00bfEs eficaz el cach\u00e9? Hace un par de a\u00f1os, mi peque\u00f1a investigaci\u00f3n mostr\u00f3 que no era perfecto. Veamos la situaci\u00f3n actual.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nPara recopilar informaci\u00f3n, modifiqu\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/jedisct1\/encrypted-dns-server\">Encrypted DNS Server<\/a><\/noindex> para conservar el valor TTL de la respuesta. Se define como el m\u00ednimo TTL de sus registros, para cada consulta entrante. Esto proporciona una buena visi\u00f3n de la distribuci\u00f3n del TTL en el tr\u00e1fico real, y tambi\u00e9n considera la popularidad de las consultas individuales. La versi\u00f3n modificada del servidor funcion\u00f3 durante varias horas.<\/p>\n<p>El conjunto de datos resultante consta de 1&nbsp;583&nbsp;579 registros (name, qtype, TTL, timestamp). Aqu\u00ed est\u00e1 la distribuci\u00f3n general de TTL (el eje X representa TTL en segundos):<\/p>\n<p><img decoding=\"async\" alt=\"Deja de usar un TTL rid\u00edculamente bajo para DNS\" src=\"\/wp-content\/uploads\/2019\/11\/ce19a1ceb07e1fd2f3b2284f86271eac.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Aparte de un ligero bache en 86&nbsp;400 (principalmente, para registros SOA), es bastante evidente que los TTL est\u00e1n en un rango bajo. Veamos m\u00e1s de cerca:<\/p>\n<p><img decoding=\"async\" alt=\"Deja de usar un TTL rid\u00edculamente bajo para DNS\" src=\"\/wp-content\/uploads\/2019\/11\/abbe48952b616e1c5bdb18c2dc103dc7.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Bien, los TTL de m\u00e1s de 1 hora no son estad\u00edsticamente significativos. Entonces, centr\u00e9monos en el rango de 0-3600:<\/p>\n<p><img decoding=\"async\" alt=\"Deja de usar un TTL rid\u00edculamente bajo para DNS\" src=\"\/wp-content\/uploads\/2019\/11\/f8a88267e1868a55d9234f66ad8c5dee.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>La mayor\u00eda de los TTL est\u00e1n entre 0 y 15 minutos:<\/p>\n<p><img decoding=\"async\" alt=\"Deja de usar un TTL rid\u00edculamente bajo para DNS\" src=\"\/wp-content\/uploads\/2019\/11\/aab650c806097513a5924e5262211ea5.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>La abrumadora mayor\u00eda est\u00e1 entre 0 y 5 minutos:<\/p>\n<p><img decoding=\"async\" alt=\"Deja de usar un TTL rid\u00edculamente bajo para DNS\" src=\"\/wp-content\/uploads\/2019\/11\/736af4b33b745fb0d5070200fa511426.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Esto no es muy bueno.<\/p>\n<p>La distribuci\u00f3n acumulativa hace que el problema sea a\u00fan m\u00e1s evidente:<\/p>\n<p><img decoding=\"async\" alt=\"Deja de usar un TTL rid\u00edculamente bajo para DNS\" src=\"\/wp-content\/uploads\/2019\/11\/a3a4f03188dd6dbbf4558076b827f6a5.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>En la mitad de las respuestas DNS, el TTL es de 1 minuto o menos, y en tres cuartos de ellas, es de 5 minutos o menos.<\/p>\n<p>Pero espera, en realidad es a\u00fan peor. Este es el TTL de los servidores autoritativos. Sin embargo, los resolutores de clientes (como routers, cach\u00e9s locales) obtienen el TTL de los resolutores ascendentes, y este disminuye cada segundo.<\/p>\n<p>As\u00ed, el cliente puede usar en promedio cada registro durante la mitad del TTL original, despu\u00e9s de lo cual enviar\u00e1 una nueva consulta.<\/p>\n<p>\u00bfQuiz\u00e1s estos TTL tan bajos solo se refieren a consultas inusuales, y no a sitios web populares y API? Veamos:<\/p>\n<p><img decoding=\"async\" alt=\"Deja de usar un TTL rid\u00edculamente bajo para DNS\" src=\"\/wp-content\/uploads\/2019\/11\/2680f9669a90f449a593edcc84ca0dc8.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>El eje X&nbsp;representa el TTL, el eje Y&nbsp;representa la popularidad de las consultas.<\/p>\n<p>Desafortunadamente, las consultas m\u00e1s populares son tambi\u00e9n las que peor se cachean.<\/p>\n<p>Aproximemos:<\/p>\n<p><img decoding=\"async\" alt=\"Deja de usar un TTL rid\u00edculamente bajo para DNS\" src=\"\/wp-content\/uploads\/2019\/11\/c670382b195169779743f43fd7b15827.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Veredicto: todo est\u00e1 realmente mal. Ya hab\u00eda sido malo antes, y ahora es a\u00fan peor. La cach\u00e9 DNS se ha vuelto pr\u00e1cticamente in\u00fatil. A medida que cada vez menos personas utilizan el resolutor DNS de su proveedor (por razones v\u00e1lidas), el aumento de la latencia se vuelve m\u00e1s evidente.<\/p>\n<p>La cach\u00e9 DNS solo se ha vuelto \u00fatil para contenido que nadie visita.<\/p>\n<p>Tambi\u00e9n tenga en cuenta que el software puede <noindex><a rel=\"nofollow\" href=\"https:\/\/00f.net\/2011\/11\/17\/how-long-does-a-dns-ttl-last\/\">interpretar de diferentes<\/a><\/noindex> maneras los TTL bajos.<\/p>\n<h1>\u00bfPor qu\u00e9 es as\u00ed?<\/h1>\n<p>\u00bfPor qu\u00e9 se establece un TTL tan bajo para los registros DNS?<\/p>\n<ul>\n<li>Los equilibradores de carga obsoletos han permanecido con la configuraci\u00f3n por defecto.<\/li>\n<li>Existen mitos de que la distribuci\u00f3n de carga por DNS depende del TTL (no es as\u00ed&nbsp;\u2014 desde los tiempos de Netscape Navigator, los clientes eligen una direcci\u00f3n IP al azar de un conjunto de RR y transparentemente intentan otra si no pueden conectarse)<\/li>\n<li>Los administradores quieren aplicar los cambios de inmediato, por lo que es m\u00e1s f\u00e1cil planificar.<\/li>\n<li>El administrador del servidor DNS o del equilibrador de carga ve su tarea como desplegar efectivamente la configuraci\u00f3n que los usuarios solicitan, en lugar de acelerar los sitios y servicios.<\/li>\n<li>Los TTL bajos ofrecen tranquilidad.<\/li>\n<li>Las personas originalmente establecen TTL bajos para pruebas y luego se olvidan de cambiarlos.<\/li>\n<\/ul>\n<p>No inclu\u00ed en la lista la 'gesti\u00f3n de fallos', ya que esto es cada vez menos relevante. Si es necesario redirigir a los usuarios a otra red solo para mostrar una p\u00e1gina de error cuando absolutamente todo lo dem\u00e1s ha fallado, probablemente una latencia de m\u00e1s de 1 minuto sea aceptable.<\/p>\n<p>Adem\u00e1s, un TTL de un minuto significa que si los servidores DNS autoritativos est\u00e1n bloqueados por m\u00e1s de un minuto, nadie m\u00e1s podr\u00e1 acceder a los servicios dependientes. Y la redundancia no ayudar\u00e1 si la causa es un error de configuraci\u00f3n o un hackeo. Por otro lado, con TTL razonables muchos clientes continuar\u00e1n utilizando la configuraci\u00f3n anterior y nunca notar\u00e1n nada.<\/p>\n<p>Los TTL bajos son en gran medida culpa de los servicios CDN y los equilibradores de carga, especialmente cuando combinan CNAME con TTL bajos y registros con TTL igualmente bajos (pero independientes):<\/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>Cada vez que expira un CNAME o cualquiera de los registros A, se debe enviar una nueva consulta. Ambos tienen un TTL de 30 segundos, pero no coinciden. El TTL medio real ser\u00e1 de 15 segundos.<\/p>\n<p>\u00a1Pero espera! La situaci\u00f3n es a\u00fan peor. Algunos resolutores se comportan muy mal en esta situaci\u00f3n con dos TTL bajos relacionados:<\/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>El resolutor Level3 probablemente funciona con BIND. Si sigues enviando esta consulta, siempre regresar\u00e1 un TTL igual a 1. En esencia, <code>raw.githubusercontent.com<\/code> nunca se almacena en cach\u00e9.<\/p>\n<p>Aqu\u00ed hay otro ejemplo de una situaci\u00f3n as\u00ed con un dominio muy popular:<\/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>Al menos tres registros CNAME. Ay. Uno tiene un TTL decente, pero esto es completamente in\u00fatil. En otros CNAME, el TTL inicial es de 60 segundos, pero para los dominios <code>akamai.net<\/code> el TTL m\u00e1ximo es de 20 segundos, y ninguno est\u00e1 en fase.<\/p>\n<p>\u00bfQu\u00e9 pasa con los dominios que consultan continuamente a los dispositivos 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>El mismo problema que en Firefox, y el TTL se quedar\u00e1 en 1 segundo la mayor parte del tiempo al utilizar el resolutor Level3.<\/p>\n<p>\u00bfDropbox?<\/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>En el registro <code>safebrowsing.googleapis.com<\/code> el valor TTL es de 60 segundos, al igual que los dominios de Facebook. Y, nuevamente, desde el punto de vista del cliente, estos valores se reducen a la mitad.<\/p>\n<h1>\u00bfQu\u00e9 tal establecer un TTL m\u00ednimo?<\/h1>\n<p>Utilizando el nombre, tipo de consulta, TTL y la marca de tiempo inicialmente almacenada, escrib\u00ed un script para simular 1.5 millones de consultas pasando por un resolutor de cach\u00e9, para estimar la cantidad de consultas innecesarias enviadas debido a un registro de cach\u00e9 caducado.<\/p>\n<p>El 47.4% de las consultas se realizaron despu\u00e9s de la expiraci\u00f3n del registro existente. Esto es inusualmente alto.<\/p>\n<p>\u00bfCu\u00e1l ser\u00e1 el impacto en la cach\u00e9 si se establece un TTL m\u00ednimo?<\/p>\n<p><img decoding=\"async\" alt=\"Deja de usar un TTL rid\u00edculamente bajo para DNS\" src=\"\/wp-content\/uploads\/2019\/11\/3abd417d312450519b45f66865b23763.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>El eje X son los valores m\u00ednimos de TTL. Los registros con TTL originales por encima de este valor no se ven afectados.<\/p>\n<p>El eje Y es el porcentaje de solicitudes del cliente que ya tiene un registro en cach\u00e9, pero su tiempo de vida ha expirado y hace una nueva solicitud.<\/p>\n<p>La proporci\u00f3n de solicitudes \"excesivas\" disminuye del 47% al 36% al establecer un TTL m\u00ednimo de 5 minutos. Con un TTL m\u00ednimo de 15 minutos, esta cantidad se reduce al 29%. Un TTL m\u00ednimo de 1 hora la reduce al 17%. \u00a1Una diferencia significativa!<\/p>\n<p>\u00bfQu\u00e9 tal si no cambiamos nada en el servidor, y en su lugar, establecemos los TTL m\u00ednimos en las cach\u00e9s DNS de los clientes (enrutadores, resolutores locales)?<\/p>\n<p><img decoding=\"async\" alt=\"Deja de usar un TTL rid\u00edculamente bajo para DNS\" src=\"\/wp-content\/uploads\/2019\/11\/107a2bd53797d421d65ac7260bf78dfe.jpg\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>La cantidad de solicitudes necesarias disminuye del 47% al 34% al establecer un TTL m\u00ednimo de 5 minutos, al 25% con un m\u00ednimo de 15 minutos y al 13% con un m\u00ednimo de 1 hora. Posiblemente, el valor \u00f3ptimo sea de 40 minutos.<\/p>\n<p>El impacto de este peque\u00f1o cambio es enorme.<\/p>\n<h1>\u00bfCu\u00e1les son las consecuencias?<\/h1>\n<p>Por supuesto, se puede migrar el servicio a un nuevo proveedor de nube, nuevo servidor, nueva red, exigiendo a los clientes que utilicen los \u00faltimos registros DNS. Y un TTL suficientemente bajo ayuda a realizar esta transici\u00f3n de manera suave y discreta. Pero con la migraci\u00f3n a nueva infraestructura, nadie espera que los clientes cambien a los nuevos registros DNS en un minuto, cinco minutos o quince minutos. Establecer una vida m\u00ednima de 40 minutos en lugar de 5 no impedir\u00e1 que los usuarios accedan al servicio.<\/p>\n<p>Sin embargo, esto permitir\u00e1 reducir significativamente la latencia y mejorar la confidencialidad y confiabilidad, evitando solicitudes innecesarias.<\/p>\n<p>Por supuesto, los RFC indican que se debe cumplir estrictamente con el TTL. Pero la realidad es que el sistema DNS se ha vuelto demasiado ineficiente.<\/p>\n<p>Si trabaja con servidores DNS autoritativos, por favor, compruebe sus TTL. \u00bfRealmente necesita esos valores absurdamente bajos?<\/p>\n<p>Por supuesto, hay buenas razones para establecer TTL bajos para los registros DNS. Pero no para el 75% del tr\u00e1fico DNS que pr\u00e1cticamente no cambia.<\/p>\n<p>Y si por alguna raz\u00f3n realmente necesita utilizar TTL bajos para DNS, aseg\u00farese de que su sitio no tenga habilitada la cach\u00e9. Por las mismas razones.<\/p>\n<p>Si tiene un cach\u00e9 DNS local en funcionamiento, como <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dnscrypt\/dnscrypt-proxy\">dnscrypt-proxy<\/a><\/noindex>, que permite configurar un TTL m\u00ednimo, utiliza esta funci\u00f3n. Est\u00e1 bien. No pasar\u00e1 nada malo. Establece un TTL m\u00ednimo de entre 40 minutos (2400 segundos) y 1 hora. Un rango bastante razonable.<\/p>\n<p>Fuente: <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\/es\/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=\"es_ES\" \/>\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\/es\/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\udd47Deja de usar un TTL rid\u00edculamente bajo para DNS | ProHoster","description":"La baja latencia de DNS es un factor clave para un rendimiento r\u00e1pido en Internet.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/hvatit-ispolzovat-smehotvorno-malyj-ttl-dlya-dns","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/52324","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=52324"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/52324\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=52324"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=52324"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=52324"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}