Old but Gold: Prospecting TCP to Engineer DNS Anycast (extended). Moura, G. C. M., Heidemann, J., Hardaker, W., Bulten, J., Ceron, J., & Hesselman, C. Technical Report ISI-TR-739b, USC/Information Sciences Institute, June, 2020. Released June 2020, updated April 2021
Old but Gold: Prospecting TCP to Engineer DNS Anycast (extended) [link]Paper  abstract   bibtex   
DNS latency is a concern for many service operators: CDNs exist to reduce service latency to end-users, but must rely on global DNS for reachability and load-balancing. We show that a recursive DNS resolver's preference for low latency shifts traffic at TLDs and the DNS root. DNS latency today is monitored with distributed infrastructure such as RIPE Atlas, or with active probing using Verfploeter. While Atlas coverage is wide, it is incomplete, and Verfploeter coverage in IPv6 is limited. In this paper we show that \emphpassive observation of TCP handshakes provides a mechanism to measure DNS latency. Passive RTT estimation from TCP is an old idea, but it has never been used to examine DNS before. We show that there is sufficient TCP DNS traffic today to provide greater coverage than existing approaches, and is the best method to observe latency of DNS using IPv6. We show that estimates of DNS latency from TCP is consistent with UDP latency. Our approach finds real problems: We define \emphDNS polarization, a new problem where a hypergiant sends global traffic to one anycast site rather than taking advantage of the global anycast deployment—we found Google traffic polarized and cut its latency from 100ms to 10ms, and for Microsoft, the latency cut due to traffic being depolarized was from 90ms to 20ms. Our approach is in operational use for a European country's top-level domain, and monitoring with our tool helped find and correct a routing detour sending European traffic to Australia.
@TechReport{Moura20a,
	author = 	"Giovane C. M. Moura and John Heidemann and
        		Wes Hardaker and Jeroen Bulten and Joao Ceron
                  and Christian Hesselman",
	title = 	"Old but Gold: Prospecting {TCP} to Engineer {DNS} Anycast (extended)",
	institution = 	"USC/Information Sciences Institute",
	year = 		2020,
	month = 	jun,
	sortdate = "2020-06-30",
	project = "ant, lacanic, paaddos, ddidd, diiner",
	jsubject = "network_security",
	number = 	"ISI-TR-739b",
	note = "Released June 2020, updated April 2021",
	jlocation = 	"johnh: pafile",
	keywords = 	"anycast, dns, tcp, latency, root, .nl-tld",
	url =		"https://ant.isi.edu/%7ejohnh/PAPERS/Moura20a.html",
	pdfurl =	"https://ant.isi.edu/%7ejohnh/PAPERS/Moura20a.pdf",
	otherurl = "https://www.isi.edu/publications/trpublic/pdfs/isi-tr-739.pdf",
	dataurl =	"https://ant.isi.edu/datasets/dns/#Moura20a_data",
	myorganization =	"USC/Information Sciences Institute",
	copyrightholder = "authors",
	abstract = "
DNS latency is a concern for many service operators:  CDNs exist to
reduce service latency to end-users, but must rely on global DNS for
reachability and load-balancing.  We show that a recursive DNS
resolver's preference for low latency shifts traffic at TLDs and the
DNS root.  DNS latency today is monitored with distributed
infrastructure such as RIPE Atlas, or with active probing using
Verfploeter.  While Atlas coverage is wide, it is incomplete, and
Verfploeter coverage in IPv6 is limited.  In this paper we show that
\emph{passive observation of TCP handshakes provides a mechanism to
measure DNS latency}.  Passive RTT estimation from TCP is an old idea,
but it has never been used to examine DNS before.  We show that there
is sufficient TCP DNS traffic today to provide greater coverage than
existing approaches, and is the best method to observe latency of DNS
using IPv6.  We show that estimates of DNS latency from TCP is
consistent with UDP latency.  Our approach finds real problems:  We
define \emph{DNS polarization}, a new problem where a hypergiant sends
global traffic to one anycast site rather than taking advantage of the
global anycast deployment---we found Google traffic polarized and cut
its latency from 100ms to 10ms, and for Microsoft, the latency cut due
to traffic being depolarized was from 90ms to 20ms.  Our approach is
in operational use for a European country's top-level domain, and
monitoring with our tool helped find and correct a routing detour
sending European traffic to Australia.
",
}

Downloads: 0