There are multiple factors that a ect optimal response times for web browsing and one of them is the resolution of DNS requests. Currently, at the DNS level, the latency is increasing due to servers location, malicious tra c under-scaling, among others. In this work we propose a novel DNS tra c distribution according to daylight time in speci c zones. We demonstrate that DNS-related tra c congestion increases during the day light in each country. Based on these observations, we propose the tra c distribution depending on the time-zone di erence to balance the load at the DNS servers and to generate new routes toward the DNS servers with less work-load at these times. The distribution is based on the analysis of a real DNS tra c dataset during a one-day period and the responses of di erent queries in the main server located in Santiago de Chile.
Comercialmente desde el punto de vista de proveedores de servicio de Internet (ISP por sus siglas en ingles) el rendimiento de una red se traduce en millones de dolares, de manera positiva o negativa de acuerdo a los servicios recibidos por el usuario nal. La principal causa de resultados negativos es determinada por la latencia, que se ha incrementado aproximadamente 30ms en tiempos de respuesta desde el 2013 hasta el 2017, principalmente en servicios Web tanto en redes de Internet jo como movil [Incode17]. Por ejemplo, Amazon estima que los ingresos disminuyen en un 1% por cada 100 ms de latencia, mientras que para Google se estima un descenso del 0,74% en las busquedas web cuando la latencia aumenta alrededor de 400 ms [Karzand17] y el tra co disminuye en un 4% por cada 100 ms de latencia [Incode17]. Adicionalmente, el reporte en [Incode17] concreta que esas perdidas alcanzan hasta los 580 billones de dolares en perdidas por transacciones electronicas en redes de Internet jo para el an~o 2017, aproximadamente 70 billones mas que en 2016.
En consecuencia la prestacion y control de servicios de Internet orientados con alta disponibilidad, menor retraso en transmision, tasa de errores baja, tiempos de respuesta bajos, uso e ciente de ancho de banda, entre otros aspectos son temas de interes para la investigacion. Actualmente la mayor a de las investigaciones sobre la calidad de servicio (QoS por sus siglas en ingles) en Internet estan enfocadas al desarrollo de nuevos estandares, protocolos y metricas. A traves del tiempo se han desarrollado propuestas como la Arquitectura de Servicios Integrados de Internet (IISA por sus siglas en ingles), acuerdos de nivel de servicio (SLA pos sus siglas en ingles), gestion avanzada de tra co (ATM por sus siglas en ingles) y servicios diferenciados (Di Serv por sus siglas en ingles) para garantizar QoS en redes a gran escala. Sin embargo, muchos ISP pasan por alto la importancia de la latencia relacionada a tra co DNS, debido a que afecta directamente la percepcion QoS por parte de los usuarios nales [Akamai17]. En [Asap11] analizan la resolucion de solicitudes DNS y como se relaciona con los tiempos de respuesta optimos para la navegacion web.
Posteriormente, en [Bozkurt17] realizan una investigacion para identi car las causas de la in acion de la latencia en Internet (relacion entre el tiempo de recuperacion y lalatencia-c1), entre las que se destaca la resolucion DNS como factor de latencia en general. Sobre 1.9 millones de conexiones analizadas, la resolucion DNS es uno de los factores mas relevantes al igual que el factor de handshake-TLS, con una mediana de 6.3 1tiempo que tardar a la luz en viajar de ida y vuelta a lo largo de la ruta mas corta entre los mismos puntos nales y 10.2 veces respectivamente de 36.5 veces el tiempo in acion de latencia total. Investigaciones como estas revelan que el problema no esta situado en el ancho de banda del canal como muchos usuarios suponen.
En este trabajo se presenta el estudio de un conjunto de datos reales para analizar el tra co de resolucion y solicitudes DNS. Posteriormente se realizan mapas de calor de acuerdo a la ubicacion geogra ca de las solicitudes o respuestas DNS. Basados en los resultados de mapas de calor se propone una distribucion para apoyar el balance de carga en servidores DNS y generar nuevas metricas de rendimiento de red en funcion de la hora del d a y las solicitudes DNS. Esta propuesta permitir a generar una solucion a la congestion de solicitudes DNS en las zonas de mas alto tra co de datos Web de acuerdo al horario de dichas solicitudes DNS. En la RFC 7808 "Time Zone Data Distribution Service" [RFC 7808], se de ne el protocolo de servicio de distribucion de datos de zona horaria, consultas de zona horaria, localizacion de zona horaria y otros conceptos que son empleados en este trabajo.
Previos desarrollos de protocolos y algoritmos han generado soluciones genericas pero la evolucion de tecnolog as como la virtualizacion en la nube permitir an tener soluciones adaptativas y practicas como la que se propone en este trabajo. Para efectos de este trabajo se propone replicar servidores DNS de manera local en un nivel de dominio bajo, es decir replicacion de DNS cache y previas solicitudes durante un per odo establecido. Para ello es necesario geolocalizar direcciones IP con alta precision, lo cual ha sido propuesto en trabajos previos para deteccion anycast y trabajos relacionados [Cicalese15],[Cicalese16] y [Cicalese18]. 2
El conjunto de datos analizado corresponde a registros de un servidor DNS autoritativo ubicado en Santiago de Chile de un d a completo tomados entre los d as 2 a 3 del mes de octubre de 2017. Los protocolos contenidos en el conjunto de datos son TCP y DNS, en este trabajo se procesan solo DNS. Las solicitudes DNS corresponden en su mayor a a servicios Web con un 89% del total, el restante corresponde una gran parte a solicitudes Mail Exchange (MX por sus siglas en ingles). Durante el analisis de los registros se pudo observar que la cantidad de respuestas/solicitudes DNS en servidores alojados en diferentes pa ses aumentaba durante horas espec cas del d a. Esto pudo ser determinado mediante la visualizacion de diferentes mapas de calor de las respuestas DNS, como se observa en la gura 2. Pa ses como Brasil, Canada, Mexico, Argentina, entre otros, tienen solicitudes variables de acuerdo a la zona horaria en la que se encuentran. En Fig.2 (izquierda) se determina que pa ses como Argentina o Mexico no tienen solicitudes en un horario de 04:00 am segun Tiempo Universal Coordinado UTC/GMT-4 (UTC por sus siglas en ingles). Mientras que en la Fig.2 (central) se observa como aumenta la cantidad de solicitudes para Brasil, Canada e inclusive para los pa ses mencionados anteriormente en el horario de 02:00 pm UTC/GMT-4. Finalmente en la Fig.2 (derecha) se observan cambios en un horario de 06:30 pm UTC/GMT-4.
Figura 1. Mapas de calor en diferentes horarios de la cantidad de respuestas DNS en diferentes pa ses de America a un servidor ubicado en Santiago de Chile
De acuerdo a los mapas de calor generados se realiza un analisis de los pa ses con mas solicitudes DNS y que obtienen respuesta del servidor DNS en Santiago de Chile. Para geolocalizar los servidores se utilizaron los modulos mas conocidos como geoip de geolite2 contenidos en el desarrollo de la industria MaxMind [Maxmind]. Geolite2 es un grupo de bases de datos que relacionan direcciones IP con la ubicacion (ciudad o pa s) del servidor. Python se elige como lenguaje de programacion para implementar la geolocalizacion y la visualizacion por la cantidad de modulos de visualizacion de datos que son compatibles y por el desarrollo practico de algoritmos para realizar extraccion de caracter sticas de grandes cantidades de datos.
Adicional a la distribucion por zonas DNS mediante nubes anycast de los servidores instanciados geogra camente a nivel mundial, esta propuesta incorpora un balance de carga para generar un enrutamiento con diferentes saltos entre nodos intermedios o la distribucion de las solicitudes realizadas hacia o desde el servidor local en Santiago de Chile. Un ejemplo son las solicitudes provenientes desde Brasil en las que se puede generar una carga signi cativa en el servidor aparte de las solicitudes internas (Chile) y externas como EU o Canada. Por este motivo resulta util dirigir el tra co a servidores instanciados en una zona horaria con una carga menor de solicitudes en el mismo horario y que no afecte servicios donde se instancie la replica. Por ejemplo, para el rango de horas 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 alojado en Santiago de Chile proceso el 45.47%, es decir casi la mitad en un horario espec co. Mientras tanto, en el mismo horario el servidor DNS procesa el 13% de solicitudes del total en Estados Unidos que equivalen a alrededor de 200.000 mil solicitudes. Figura 2. Numero de respuestas DNS desde el servidor local en Santiago hacia solicitudes desde Brasil, Paraguay y Argentina durante un d a
Aunque actualmente existen servidores con grandes capacidades de procesamiento, d a a d a la implementacion de nuevas tecnolog as y aplicaciones basadas en servicios IP en su mayor a servicios Web hacen que se limiten los tiempos de respuesta DNS optimos. Por este motivo la propuesta de distribucion DNS basada en los tiempos de horario de mayor congestion segun el pa s de procedencia busca disminuir los RTT a solicitudes DNS. La distribucion horaria propuesta aborda dos estrategias: distribuir carga del servidor DNS localizado en Santiago de Chile en un porcentaje que se basa en reglas y umbrales establecidos por los administradores de red y la segunda es la replicacion de servicios por un tiempo determinado en otros servidores, lo cual genera un uso optimo de servicios por el tiempo de mayor cantidad de solicitudes DNS, lo cual ahorra costos de recursos economicos/computacionales en el uso de servidores virtuales e inclusive locales si es el caso. Para la ultima estrategia no solo se considera enviar las solicitudes hacia un servidor localizado en otro espacio geogra co, sino que se va a considerar que la carga de solicitudes DNS en ese horario no va a afectar el rendimiento de los servicios locales, debido a que no coincide el rango de horas con mas alto tra co DNS del pa s donde se replica el servidor. 3
Principalmente esta propuesta hace enfasis en una solucion generalizada a servidores DNS en otras ubicaciones geogra cas, lo expuesto en este trabajo es solo un ejemplo de como se comporta el tra co DNS para el caso de Santiago de Chile porque es de donde se adquirieron los datos de un servidor DNS real. Basados en el analisis previo se plantea desarrollar un algoritmo de distribucion de acuerdo a los tiempos durante el d a con mas tra co de solicitudes provenientes de diferentes pa ses. Para ello se plantea realizar un analisis estad stico de los datos seleccionados aleatoriamente. Un promedio de las horas con mas ujo de tra co 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, multiples trabajos [Castro09], [Narayan14] han planteado la emulacion o geo-replicacion de servidores con las que se obtienen mayor auto-escalabilidad y disponibilidad (incluso virtual). Adicionalmente se plantea hacer un diagnostico de las rutas de las solicitudes para determinar si la distribucion es mas optima en tiempos de respuesta de acuerdo a la distancia entre el servidor y el usuario/servidor que realiza la solicitud. Finalmente se realizara una comparacion con los tiempos de respuesta del servidor actual en Santiago de Chile.