Wow, That's a lot of packets
Wow, That's a lot of packets
复制标题
DOI：
--
复制
发表时间：
2003
期刊：
影响因子：
--
通讯作者：
D. Wessels;Marina Fomenkov
中科院分区：
文献类型：
--
作者：
D. Wessels;Marina Fomenkov
运营根DNS服务器的组织报告每天的查询负载超过1亿次。考虑到DNS的设计目标，以及我们对当今互联网的了解，这个数字比我们预期的要高出两个数量级。在一个根服务器操作员的帮助下，我们对到达13个根服务器之一的查询进行了24小时跟踪。在本文中，我们分析这些数据，并使用一个简单的模型的DNS分类到九个类别之一的每个查询。我们发现，到目前为止，大多数查询是重复的，只有一小部分是合法的。我们还描述了一些“根服务器滥用者”，即客户端向根服务器发送特别大量的查询。我们认为，大部分的根服务器滥用的发生，因为查询代理从来没有收到答复，由于包过滤器，或路由问题。关键字-DNS根服务器I.背景技术背景：DNS 101域名系统（DNS）是现代互联网的基本组成部分[1]，通过将主机名映射到IP地址，在人类用户和互联网路由基础设施之间提供关键链接。DNS利用划分为区域或域的分层名称空间。这种等级制度表现在普遍存在的“点”结构上。例如，com是example.com、microsoft.com、cnn.com和大约2000万个其他区域的父区域。每个区域都有一个或多个权威名称服务器。这些是专用服务器，其工作是回答对其区域内的名称的查询。例如，加州大学圣地亚哥分校有三个权威名称服务器。需要知道www.ucsd.edu的IP地址的应用程序可以向其中一个服务器发送DNS查询，然后返回The Measurement Factory，Inc.，博尔德，科罗拉多，电子邮件：wirt@measurement-factory.com。CAIDA，圣地亚哥超级计算机中心，加州大学，圣地亚哥。电子邮件：marina@caida. org。对这项工作的支持由WIDE和DARPA NMS N66001-01-1-8909提供。权威的回答。如果应用程序不知道向何处发送查询，它会询问父区域中的服务器。在上面的例子中，不知道任何关于ucsd.edu的信息，应用程序应该向edu区域的权威服务器发送一个查询。如果应用程序不知道edu区域，它会查询“根区域”。这个过程称为递归迭代。DNS根区域由分布在地球仪上的13个名称服务器（不要与13个通用顶级域服务器混淆）提供服务。13是当前DNS体系结构中可能的最大根服务器数量，因为这是512字节UDP应答数据包中可以容纳的最大数量。十台根服务器位于美国，两个在欧洲，一个在亚洲。1根区域和根名称服务器至关重要，因为它们是在DNS中定位任何内容的起点。没有它们，DNS以及我们使用的几乎所有应用程序（Web，ssh，email）都将无法使用。查询名称服务器的DNS客户端或解析器有两种类型：存根和递归。存根解析器，通常在用户应用程序中找到，如web浏览器，ssh客户端和邮件传输代理，相当原始，主要依赖于更智能的递归解析器，这些解析器可以理解名称服务器引用。递归解析器通常在专门的DNS应用程序中实现，例如伯克利互联网域名（BIND）[2]服务器和微软的DNS服务器。大多数组织都使用本地递归名称服务器。递归名称服务器缓存名称服务器响应，包括引用。缓存可以节省网络资源，因为中间服务器不需要为每个请求查询根名称服务器。例如，名称服务器了解到a.gtld-servers.net和其他网站是com区域的权威网站，并为此信息设置时间限制（TTL）。顶级域名的TTL通常为1-2天。从理论上讲，缓存递归名称服务器只需要查询根名称服务器以查找未知的顶级域或TTL过期。然而，许多研究表明，根名称服务器收到的查询比它们应该收到的要多得多。在本文中，我们彻底调查和根名称服务器流量的特点，事实上，许多根名称服务器实际上是多个主机背后的网络负载均衡器。其中一些甚至占据了几个物理位置，使用IPv4任播在单个IP地址下运行。
Organizations operating Root DNS servers report loads exceeding 100 million queries per day. Given the design goals of the DNS, and what we know about today’s Internet, this number is about two orders of magnitude more than we would expect. With the assistance of one root server operator, we took a 24-hour trace of queries arriving at one of the thirteen root servers. In this paper we analyze these data and use a simple model of the DNS to classify each query into one of nine categories. We find that, by far, most of the queries are repeats and that only a small percentage are legitimate. We also characterize a few of the “root server abusers,” that is, clients sending a particularly large number of queries to the root server. We believe that much of the root server abuse occurs because the querying agents never receive the replies, due either to packet filters, or to routing issues. Keywords—DNS root server I. BACKGROUND: DNS 101 The Domain Name System (DNS) is a fundamental component of the modern Internet [1], providing a critical link between human users and Internet routing infrastructure by mapping host names to IP addresses. The DNS utilizes a hierarchical name space divided into zones, or domains. This hierarchy is manifested in the widespread “dots” structure. For example, com is the parent zone for example.com, microsoft.com, cnn.com, and approximately 20 million other zones. Each zone has one or more authoritative name servers. These are dedicated servers, whose job is to answer queries for names within their zone(s). For example, UCSD has three authoritative name servers. An application that needs to know the IP address for www.ucsd.edu can send a DNS query to one of those servers, which then returns The Measurement Factory, Inc., Boulder, Colorado, E-mail: wessels@measurement-factory.com. CAIDA, San Diego Supercomputer Center, University of California, San Diego. E-mail: marina@caida.org. Support for this work is provided by WIDE and DARPA NMS N66001-01-1-8909. an authoritative answer. If the application does not know where to send a query it asks the servers in the parent zone. In the example above, not knowing anything about ucsd.edu, the application should send a query to the authoritative server for the edu zone. If the application does not know about the edu zone, it queries the “root zone.” This process is called recursive iteration. The DNS root zone is served by 13 name servers (not to be confused with the 13 generic top-level domain servers) distributed across the globe. Thirteen is the maximum number of root servers possible in the current DNS architecture because that is the most that can fit inside a 512byte UDP reply packet. Ten root servers are located in the U.S., two are in Europe, and one is in Asia.1 The root zone and the root name servers are vital because they are the starting points for locating anything in the DNS. Without them, the DNS and hence almost every application we use (the Web, ssh, email) would be rendered unusable. DNS clients, or resolvers, that query name servers, come in one of two flavors: stub and recursive. Stub resolvers, typically found in user applications, such as web browsers, ssh clients, and mail transfer agents, are rather primitive and mostly rely on smarter recursive resolvers that understand name server referrals. Recursive resolvers are usually implemented in specialized DNS applications such as the Berkeley Internet Domain Name (BIND) [2] server and Microsoft’s DNS server. Most organizations operate local recursive name servers. Recursive name servers cache name server responses, including referrals. Caching conserves network resources because intermediate servers do not need to query the root name servers for every request. For example, the name server learns that a.gtld-servers.net and others are authoritative for the com zone and sets the time-tolive (TTL) for this information. Typical TTLs for top level domains are on the order of 1–2 days. In theory, a caching recursive name server only needs to query the root name servers for an unknown top level domain or when a TTL expires. However, a number of studies have shown that the root name servers receive many more queries than they should. In this paper we thoroughly investigate and characterize root name server trafIn fact many of the root name servers are actually multiple hosts behind network load balancers. Some of them even occupy a few physical locations, employing IPv4 anycast to operate under a single IP address.