Proposal for an Intelligent Distribution Model of DNS queries according to Time Zones Jeisson S. Sánchez M. Sandra Céspedes Umaña Jeisson@niclabs.cl scespedes@ing.uchile.cl se estima un descenso del 0,74% en las búsquedas web cuando la latencia aumenta alrededor de 400 ms Abstract [Karzand17] y el tráfico disminuye en un 4% por cada 100 ms de latencia [Incode17]. Adicionalmente, el re- There are multiple factors that affect optimal porte en [Incode17] concreta que esas pérdidas alcan- response times for web browsing and one of zan hasta los 580 billones de dólares en pérdidas por them is the resolution of DNS requests. Cur- transacciones electrónicas en redes de Internet fijo para rently, at the DNS level, the latency is increas- el año 2017, aproximadamente 70 billones más que en ing due to servers location, malicious traffic 2016. under-scaling, among others. In this work En consecuencia la prestación y control de servicios we propose a novel DNS traffic distribution de Internet orientados con alta disponibilidad, menor according to daylight time in specific zones. retraso en transmisión, tasa de errores baja, tiempos We demonstrate that DNS-related traffic con- de respuesta bajos, uso eficiente de ancho de banda, gestion increases during the day light in each entre otros aspectos son temas de interés para la in- country. Based on these observations, we pro- vestigación. Actualmente la mayorı́a de las investiga- pose the traffic distribution depending on the ciones sobre la calidad de servicio (QoS por sus siglas time-zone difference to balance the load at the en inglés) en Internet están enfocadas al desarrollo de DNS servers and to generate new routes to- nuevos estándares, protocolos y métricas. A través ward the DNS servers with less work-load at del tiempo se han desarrollado propuestas como la Ar- these times. The distribution is based on the quitectura de Servicios Integrados de Internet (IISA analysis of a real DNS traffic dataset during a por sus siglas en inglés), acuerdos de nivel de servi- one-day period and the responses of different cio (SLA pos sus siglas en inglés), gestión avanzada queries in the main server located in Santiago de tráfico (ATM por sus siglas en inglés) y servicios de Chile. diferenciados (DiffServ por sus siglas en inglés) para garantizar QoS en redes a gran escala. Sin embargo, 1 Introducción muchos ISP pasan por alto la importancia de la laten- Comercialmente desde el punto de vista de proveedores cia relacionada a tráfico DNS, debido a que afecta di- de servicio de Internet (ISP por sus siglas en inglés) rectamente la percepción QoS por parte de los usuarios el rendimiento de una red se traduce en millones de finales [Akamai17]. En [Asap11] analizan la resolución dólares, de manera positiva o negativa de acuerdo a de solicitudes DNS y cómo se relaciona con los tiempos los servicios recibidos por el usuario final. La princi- de respuesta óptimos para la navegación web. pal causa de resultados negativos es determinada por Posteriormente, en [Bozkurt17] realizan una inves- la latencia, que se ha incrementado aproximadamente tigación para identificar las causas de la inflación de 30ms en tiempos de respuesta desde el 2013 hasta el la latencia en Internet (relación entre el tiempo de re- 2017, principalmente en servicios Web tanto en redes cuperación y lalatencia-c 1 ), entre las que se destaca la de Internet fijo como móvil [Incode17]. Por ejemplo, resolución DNS como factor de latencia en general. So- Amazon estima que los ingresos disminuyen en un 1% bre 1.9 millones de conexiones analizadas, la resolución por cada 100 ms de latencia, mientras que para Google DNS es uno de los factores más relevantes al igual que el factor de handshake-TLS, con una mediana de 6.3 In: Proceedings of the IV School of Systems and Networks (SSN 2018), Valdivia, Chile, October 29-31, 2018. Published 1 tiempo que tardarı́a la luz en viajar de ida y vuelta a lo at http://ceur-ws.org largo de la ruta más corta entre los mismos puntos finales y 10.2 veces respectivamente de 36.5 veces el tiempo acuerdo a la zona horaria en la que se encuentran. inflación de latencia total. Investigaciones como estas En Fig.2 (izquierda) se determina que paı́ses como revelan que el problema no está situado en el ancho de Argentina o México no tienen solicitudes en un ho- banda del canal como muchos usuarios suponen. rario de 04:00 am según Tiempo Universal Coordinado En este trabajo se presenta el estudio de un con- UTC/GMT-4 (UTC por sus siglas en inglés). Mien- junto de datos reales para analizar el tráfico de res- tras que en la Fig.2 (central) se observa como aumenta olución y solicitudes DNS. Posteriormente se realizan la cantidad de solicitudes para Brasil, Canadá e inclu- mapas de calor de acuerdo a la ubicación geográfica de sive para los paı́ses mencionados anteriormente en el las solicitudes o respuestas DNS. Basados en los resul- horario de 02:00 pm UTC/GMT-4. Finalmente en la tados de mapas de calor se propone una distribución Fig.2 (derecha) se observan cambios en un horario de para apoyar el balance de carga en servidores DNS 06:30 pm UTC/GMT-4. y generar nuevas métricas de rendimiento de red en función de la hora del dı́a y las solicitudes DNS. Esta propuesta permitirı́a generar una solución a la con- gestión de solicitudes DNS en las zonas de más alto tráfico de datos Web de acuerdo al horario de dichas solicitudes DNS. En la RFC 7808 ”Time Zone Data Distribution Service” [RFC 7808], se define el proto- colo de servicio de distribución de datos de zona ho- raria, consultas de zona horaria, localización de zona horaria y otros conceptos que son empleados en este trabajo. Previos desarrollos de protocolos y algoritmos han generado soluciones genéricas pero la evolución de tec- nologı́as como la virtualización en la nube permitirı́an Figura 1. Mapas de calor en diferentes horarios de la can- tener soluciones adaptativas y prácticas como la que se tidad de respuestas DNS en diferentes paı́ses de América a propone en este trabajo. Para efectos de este trabajo un servidor ubicado en Santiago de Chile se propone replicar servidores DNS de manera local en un nivel de dominio bajo, es decir replicación de De acuerdo a los mapas de calor generados se real- DNS caché y previas solicitudes durante un perı́odo iza un análisis de los paı́ses con más solicitudes DNS establecido. Para ello es necesario geolocalizar direc- y que obtienen respuesta del servidor DNS en Santi- ciones IP con alta precisión, lo cual ha sido propuesto ago de Chile. Para geolocalizar los servidores se uti- en trabajos previos para detección anycast y trabajos lizaron los módulos más conocidos como geoip de ge- relacionados [Cicalese15],[Cicalese16] y [Cicalese18]. olite2 contenidos en el desarrollo de la industria Max- Mind [Maxmind]. Geolite2 es un grupo de bases de 2 Propuesta de Distribución In- datos que relacionan direcciones IP con la ubicación (ciudad o paı́s) del servidor. Python se elige como teligente de acuerdo a zona horaria lenguaje de programación para implementar la geolo- El conjunto de datos analizado corresponde a registros calización y la visualización por la cantidad de módulos de un servidor DNS autoritativo ubicado en Santiago de visualización de datos que son compatibles y por de Chile de un dı́a completo tomados entre los dı́as 2 el desarrollo práctico de algoritmos para realizar ex- a 3 del mes de octubre de 2017. Los protocolos con- tracción de caracterı́sticas de grandes cantidades de tenidos en el conjunto de datos son TCP y DNS, en datos. este trabajo se procesan solo DNS. Las solicitudes DNS Adicional a la distribución por zonas DNS me- corresponden en su mayorı́a a servicios Web con un diante nubes anycast de los servidores instanciados 89% del total, el restante corresponde una gran parte geográficamente a nivel mundial, esta propuesta in- a solicitudes Mail Exchange (MX por sus siglas en corpora un balance de carga para generar un en- inglés). Durante el análisis de los registros se pudo ob- rutamiento con diferentes saltos entre nodos interme- servar que la cantidad de respuestas/solicitudes DNS dios o la distribución de las solicitudes realizadas ha- en servidores alojados en diferentes paı́ses aumentaba cia o desde el servidor local en Santiago de Chile. Un durante horas especı́ficas del dı́a. Esto pudo ser de- ejemplo son las solicitudes provenientes desde Brasil terminado mediante la visualización de diferentes ma- en las que se puede generar una carga significativa en pas de calor de las respuestas DNS, como se observa el servidor aparte de las solicitudes internas (Chile) y en la figura 2. Paı́ses como Brasil, Canadá, México, externas como EU o Canadá. Por este motivo resulta Argentina, entre otros, tienen solicitudes variables de útil dirigir el tráfico a servidores instanciados en una zona horaria con una carga menor de solicitudes en el los servicios locales, debido a que no coincide el rango mismo horario y que no afecte servicios donde se in- de horas con más alto tráfico DNS del paı́s donde se stancie la replica. Por ejemplo, para el rango de horas replica el servidor. entre las 02:00 pm y 04:30 pm UTC/GMT-4, del total de solicitudes en ese dı́a desde Brasil el servidor DNS 3 Trabajos Futuros alojado en Santiago de Chile procesó el 45.47%, es de- Principalmente esta propuesta hace énfasis en una cir casi la mitad en un horario especı́fico. Mientras solución generalizada a servidores DNS en otras ubica- tanto, en el mismo horario el servidor DNS procesa ciones geográficas, lo expuesto en este trabajo es solo el 13% de solicitudes del total en Estados Unidos que un ejemplo de cómo se comporta el tráfico DNS para equivalen a alrededor de 200.000 mil solicitudes. el caso de Santiago de Chile porque es de donde se adquirieron los datos de un servidor DNS real. Basa- dos en el análisis previo se plantea desarrollar un al- goritmo de distribución de acuerdo a los tiempos du- rante el dı́a con más tráfico de solicitudes provenientes de diferentes paı́ses. Para ello se plantea realizar un análisis estadı́stico de los datos seleccionados aleatori- amente. Un promedio de las horas con más flujo de tráfico DNS permite establecer el rango de horas en el modelo propuesto. El balance de carga hacia un servidor real en otro paı́s permite disminuir tiempos de respuesta por parte de los servidores de respaldo y servidor local analizado en Chile. Por otro lado estas pruebas se piensan realizar en servidores de distintos paı́ses para coordinar los tiempos de funcionamiento del servidor de respaldo. Para replicar el servidor DNS, múltiples trabajos [Castro09], [Narayan14] han planteado la emulación o geo-replicación de servidores con las que se obtienen mayor auto-escalabilidad y Figura 2. Número de respuestas DNS desde el servidor disponibilidad (incluso virtual). Adicionalmente se local en Santiago hacia solicitudes desde Brasil, Paraguay plantea hacer un diagnóstico de las rutas de las solici- y Argentina durante un dı́a tudes para determinar si la distribución es más óptima en tiempos de respuesta de acuerdo a la distancia entre Aunque actualmente existen servidores con grandes el servidor y el usuario/servidor que realiza la solici- capacidades de procesamiento, dı́a a dı́a la im- tud. Finalmente se realizará una comparación con los plementación de nuevas tecnologı́as y aplicaciones tiempos de respuesta del servidor actual en Santiago basadas en servicios IP en su mayorı́a servicios Web de Chile. hacen que se limiten los tiempos de respuesta DNS óptimos. Por este motivo la propuesta de distribución References DNS basada en los tiempos de horario de mayor con- gestión según el paı́s de procedencia busca disminuir [Incode17] IncodeConsulting .The cost of network los RTT a solicitudes DNS. La distribución horaria latency www.incodeconsulting.com/wp- propuesta aborda dos estrategias: distribuir carga del content/uploads/2017/01/inCode-Cost-of- servidor DNS localizado en Santiago de Chile en un Latency-White-Paper-060114.pdf, Enero porcentaje que se basa en reglas y umbrales estable- 2017. cidos por los administradores de red y la segunda [Karzand17] M. Karzand, D. Leith, J. Cloud & M. es la replicación de servicios por un tiempo deter- Médard. Design of FEC for low delay in 5G. minado en otros servidores, lo cual genera un uso IEEE Journal on Selected Areas in Commu- óptimo de servicios por el tiempo de mayor cantidad nications (pp. 1783-1793), Vol. 35, Issue 8. de solicitudes DNS, lo cual ahorra costos de recursos August 2017. económicos/computacionales en el uso de servidores virtuales e inclusive locales si es el caso. Para la última [Asap11] W. Zhou, Q. Li, M. Caesar & P. God- estrategia no solo se considera enviar las solicitudes ha- frey ASAP: A low-latency transport layer. cia un servidor localizado en otro espacio geográfico, Proceedings of the Seventh COnference sino que se va a considerar que la carga de solicitudes on emerging Networking EXperiments and DNS en ese horario no va a afectar el rendimiento de Technologies, 2011. [Bozkurt17] I. N. Bozkurt, A. Aguirre, B. Chan- drasekaran, P. B. Godfrey, G. Laughlin, B. Maggs & A. Singla. Why is the Internet so slow?!. International Conference on Passive and Active Network Measurement, Springer (pp. 173-187). March 2017. [Castro09] Sebastian Enrique Castro Ávila. Una em- ulación para anycast Tesis para optar al grado de Magı́ster en Ciencias mención Com- putación, Agosto 2009. [RFC 7808] M. Douglass (Spherical Cow Group) & C. Daboo (Apple) ”Time Zone Data Distribu- tion Service”, RFC 7808, Marzo 2016. [Cicalese15] D.Cicalese, J. Auge, D. Joumblatt, D. Rossi, M. Olivier & T. Friedman. Lightweight Anycast Enumeration and Ge- olocation. IEEE Conference on Com- puter Communications Workshops (INFO- COM WKSHPS), 2015. [Cicalese18] D.Cicalese & D. Rossi, A longitudinal study of IP Anycast. ACM SIGCOMM Com- puter Communication Review, Enero 2018. [Cicalese16] D.Cicalese, J. Auge, D. Joumblatt, D. Rossi, M. Olivier & T. Friedman. Latency- Based Anycast Geolocation: Algorithms, Software, and Data Sets. IEEE Journal on Selected Areas in Communications, Volume: 34, Issue: 6, Junio 2016. [Akamai17] D. McDonald, Akamai Technologies Why you should care about DNS latency https://blogs.akamai.com/2017/06/why- you-should-care-about-dns-latency.html [Maxmind] Maxmind Paquete de desarrol- ladores GeoLite2, Geolite2 Redistribution https://www.maxmind.com/es/geolite2- developer-package [Narayan14] I. Narayanan, A. Kansal, A. Sivasubra- maniam, B. Urgaonkar, S. Govindan. To- wards a Leaner Geo-distributed Cloud In- frastructure In HotCloud Junio 2014.