University of Amsterdam System and Network Engineering Research Project 1 Making do with what we've got: Using PMTUD for a higher DNS responsiveness Authors: Supervisors: Hanieh Bagheri Willem Toorop [email protected] [email protected] Victor Boteanu Benno Overeinder [email protected] [email protected] February 28, 2013 Abstract The goal of this research project is to find out if ICMPv6 Packet Too Big (PTB) messages can be used to improve a name server's responsiveness. Path MTU Discovery (PMTUD) is a mechanism used to signal the sender that its packet does not fit in the MTU of a link along its path. The sender receives a PTB message, which contains the MTU of the next link. In IPv6, the ICMPv6 PTB also contains as much of the original packet that would fit on the next link. A DNS response includes the question that generated the response. However, DNS name servers are stateless and do not remember the queries that generated the response. Once a question has been answered, it is forgotten. A client would have to timeout and requery the server to get the answer. The aim of this research is to make use of the information in ICMPv6 PTB messages to give a sense of state to name servers, and resend the response to the client. This would improve the responsiveness of the name server, as it does not have to wait for the client to time out and resend the query. Three solutions of using PTBs are presented in this report, and we covered the effects they would have if implemented. Packet captures provided by SURFnet and SIDN are analyzed to provide statistical data from real name servers. A test implementation of one of the solutions is performed using the RIPE Atlas network, and observations are made on the results. The main conclusion of this paper is that PTB messages do contain enough information to be used by name servers to resend the response to the client. 1 Contents 1 Introduction 4 1.1 Research objective . 5 1.2 Research question . 5 1.3 Related work . 6 1.4 Outline . 6 2 Background concepts 7 2.1 Fragmentation: IPv4 vs IPv6 . 7 2.2 PMTUD . 8 2.3 ICMPv6 . 8 2.3.1 Packet Too Big . 8 2.3.2 Time Exceeded Message . 9 3 Real-world observations 11 3.1 SURFnet packet captures . 12 3.2 SIDN packet captures . 15 3.3 RIPE Atlas experiment . 16 4 Proposed solutions 19 4.1 Solution 1 - TC bit solution . 19 4.2 Solution 2 - Resubmit query . 19 4.3 Solution 3 - Resubmit query with EDNS0 . 19 4.4 Implications . 20 4.5 Implementation . 21 5 Test and results 22 6 Conclusion 23 7 Future work 23 A Abbreviations 24 2 List of Figures 1 Effect of response size on its status over UDP . 4 2 DNS response . 9 3 Packet Too Big message format . 9 4 Path MTU Discovery . 10 5 RIPE Atlas network of probes . 11 6 Probes used in experiment . 17 7 Atlas Probe PMTU . 17 8 Implementation of second solution . 22 List of Tables 1 SURFnet name servers IPv4/IPv6 ratio . 12 2 SURFnet response sizes . 13 3 SURFnet large response . 14 4 SURFnet fragmented responses . 14 5 SURFnet fragment payload length . 14 6 SURFnet ICMPv6 . 15 7 SIDN response sizes . 15 8 SIDN DNSSEC response sizes . 15 9 SIDN fragment payload length . 16 10 SIDN ICMPv6 messages . 16 3 1 Introduction he Domain Name System (DNS) is an essential component of the current Internet. It T is responsible for associating information, such as IP addresses, with domain names. DNS normally uses User Datagram Protocol (UDP) as the transport layer protocol. UDP is an "stateless" and "unreliable" protocol, in that it does not implement acknowledge- ments or retransmission. By using UDP, DNS is relatively fast, and if a client does not get a response in due time, it can query the server again, or try a different server. The classical DNS protocol limits the response size over UDP to 512 bytes. When a response does not fit in the available size, it will be truncated. In this case the TC flag in the response is set and the client should resend the query over TCP. Original DNS Does not have any security mechanism to prevent forging the source or the contents of the response. The Domain Name System Security Extensions (DNSSEC) is introduced to provide authenticity and origin integrity. DNSSEC causes the zone information to be cryptographically signed. Those cryptographic signatures are conveyed in the responses, resulting into larger responses. With the growing trend towards using DNSSEC (especially after the root zones being signed in 2010), we expect larger DNS responses to become more frequent. The Extension mechanisms for DNS (EDNS) introduced (among others) a mechanism for DNS clients and servers to agree on a larger response size over UDP. With EDNS, the name servers are allowed to exchange larger responses over UDP. The immediate effect of having large DNS messages over UDP is the possibility of frag- mentation. Every link in the Internet is capable of transmitting packets with a certain size, which is called Maximum Transmission Unit (MTU). Packets larger than this limit must be fragmented before being sent over that link. As shown in Figure 1, using UDP, when the response is smaller than the size defined in EDNS option, but it is not small enough to be sent as a single network packet, it has to be fragmented. Figure 1: Effect of response size on its status over UDP Although fragmentation addresses the issue with large DNS responses that are sent over UDP, the client-side firewalls might filter fragments [1]. In IPv6, routers are not allowed to fragment the packets. Fragmentation must be done by the end hosts. Those end hosts have to do Path MTU Discovery (PMTUD) to find out the smallest MTU in the path towards the destination. In the PMTUD process, the source sends a packet into the network. If the packet encounters a router with a smaller MTU, it is dropped and an ICMPv6 PTB is sent back to the source. There is a similar message in IPv4, called 4 "ICMP fragmentation needed". The main difference between the ICMPv6 PTB and its corresponding message in IP4 is that in the former, in addition to the passable MTU by the router, it contains the trimmed part of the original message. So looking at the PTB, one can see the part of the message that can traverse the path trough the router. 1.1 Research objective In this research, we are interested in leveraging the extra payload in ICMPv6 to increase responsiveness of name servers in the case of having large responses. The advantage of ICMPv6 PTB, which makes it helpful for our problem is that it contains the first part of the payload of the dropped message, which can fit into the minimum MTU supported by all IPv6 routers (1280 bytes). Having the returned ICMPv6 PTB, the server would be able to find out the original query, in addition to the appropriate MTU size. In this research, we will explore several approaches to utilize this information. 1.2 Research question This project is mainly aimed to answer the following question: Is it feasible to leverage the original packet payload in ICMPv6 to increase a name server responsiveness? The sub-questions that will be answered in this report will be: What strategies can be applied and what effects and risks would they have? How would this be best implemented? What is the impact of fragmentation and PMTUD on the performance/responsiveness of DNS servers? 5 1.3 Related work Previous research related to the topic of this project has been done by Maikel de Boer and Jeffrey Bosma, on the IPv6 Path MTU black holes, caused by ICMPv6 filters or fragment filters [1]. They made use of the RIPE Atlas network in order to find ICMPv6 filters or fragment filters, which cause IPv6 Path MTU black holes. Their research is relevant to our project, because it gives us information regarding IP fragment filtering, which is one of the issues that we have to take into consideration for this project. In a recent research by Gijs van den Broek et. al. [4], real-world resolvers are moni- tored to analyze their behavior, when dealing with fragmented DNS responses. In this work, two server-side solutions are offered and tested to prevent the responses from being fragmented. The idea in the first solution is to set the maximum response size to 1232 bytes. The second solution is more complicated. It needs to implement a module for dynamically adjusting the EDNS size option in queries related to the resolvers behind fragment-filtering firewalls. There is an Internet-draft written by Mark Andrews [5], mentioning that PMTUD does not work well with the stateless DNS, because there is no automatic mechanism for handling PTB messages in name servers. He recommends to enable IPV6 USE MIN MTU socket option in IPv6 to fragment packets at the minimum IPv6 MTU, instead of using PMTUD. In other words, the name servers are encouraged to fragment the responses at the smallest possible size, in order to avoid receiving PTB messages. 1.4 Outline The core concepts of fragmentation and PMTUD are presented in Section 2. Packet Too Bid and Fragment Reassembly Time Exceeded messages are discussed in Subsection 2.3 and we describe their importance to this research. In section 3, we describe the resources that were used. The packet captures from SURFnet and SIDN are treated in separate subsections, as well as the initial RIPE Atlas experiment.