=Paper=
{{Paper
|id=Vol-2178/SSN2018_paper_5
|storemode=property
|title=Proposal for an Intelligent Distribution Model of DNS Queries According to Time Zones
|pdfUrl=https://ceur-ws.org/Vol-2178/SSN2018_paper_5.pdf
|volume=Vol-2178
|authors=Jeisson Sánchez,Sandra Céspedes
|dblpUrl=https://dblp.org/rec/conf/ssn/SanchezC18
}}
==Proposal for an Intelligent Distribution Model of DNS Queries According to Time Zones==
https://ceur-ws.org/Vol-2178/SSN2018_paper_5.pdf
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.