| dnsop | D. MA |
| Internet-Draft | ZDNS |
| Intended status: Standards Track | L. Song |
| Expires: February 29, 2016 | Beijing Internet Institute |
| August 28, 2015 |
UDP payload size for DNS messages
draft-madi-dnsop-udp4dns-00
The classic 512-bytes UDP payload for transporting DNS messages is an embedded dependence on IPv4. As the Internet infrastructure is evolving to IPv6, the very constraint stemming from IPv4 can be removed by the virtue of that IPv6 mandates a MTU of 1280 bytes. This document specifies a new minimum size of UDP packet to carry DNS message, making DNS implementations going forward more adaptive to both applications based on the Internet and infrastructures supporting the Internet.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 29, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Over the years, the size of DNS response message has increased beyond the IPv4 MTU, in part because DNSSEC aware DNS servers will automatically attempt to return KEY resources as additional information, along with those resource records actually requested [RFC2535]. IPv6 records also increase the size of the response, along with NAPTR and other record types. Other new functions added to DNS may also bring in more data in DNS responses in the days to come.
The classic 512-bytes UDP payload for transporting DNS messages is an embedded dependence on IPv4. As the Internet infrastructure is evolving to IPv6 [ipv6-info], the very constraint stemming from IPv4 can be removed by the virtue of that IPv6 mandates a MTU of 1280 bytes. A larger minimum size of DNS PDU would be more adaptive to variable infrastructure evolution and reflects the evolving nature of IP transmission.
This document specifies a new minimum size of UDP packet to carry DNS message, making DNS implementations going forward more adaptive to both applications based on the Internet and infrastructures supporting the Internet.
This section explicitly specifies the new minimum size of UDP packet for DNS messages, updating the 512-UDP limitation.
1232 bytes is the minimum size of UDP payload for DNS messages, according to the IPv6 MTU specifications. That is, in addition to 40- bytes IPv6 header and 8-bytes UDP header, the minimum transportation capacity that an IPv6 packet offers to application layer is 1232 bytes.
Based on this enhancement, DNS message exchanges will enjoy a larger capacity of protocol data unit, decreasing the number of IP packets, which account for some of the increase in the level of the traffic processed by intermediate devices along the path of DNS query/response exchanges. DNS software and intermediate devices must support 1232 bytes as the minimum size of UDP payload for DNS messages.
This section presents considerations on some compatibility issues due to the new minimum size of UDP payload for DNS messages. Yet solutions to these issues are out of scope of this document.
IPv4 will coexist with IPv6 for a long time. This proposal MUST work well with IPv4 infrastructure, relating to packet process by intermediate devices and MTU along the path in question. As expected, nonconformant networks will see 1232-bytes as anomaly.
Some observations, described in the appendix, indicate that 1232- bytes will be a safe minimum size of UDP payload for DNS messages in IPv4 environments.
An embedded dependence on IPv4 MTU, the classic 512-bytes UDP payload for transporting DNS messages is bound with some DNS implementations. Obsoleting the classic 512-bytes UDP payload would therefore introduce some incompatibility. Priming exchange, among others, may see some problems. Priming exchange is now done with the assumption that all DNS response should fit into the classic 512-bytes UDP payload. Given a root server is of dual-stack, receiving priming queries based on 1232-bytes UDP payload, a classic DNS implementation MAY see this kind of packet as anomaly to ignore or it needs to know how to truncate the message to get DNS query or it needs to negotiate with recursive servers to reinitiate the very process somehow.
TBD
| [ipv6-info] | ARIN, "ipv6 info center", 2015. |
| [RFC2535] | Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999. |
This section is to describe a set of tests to ascertain the limitation for a DNS message along its path as with current networking environments.
To carry out the very tests for DNS message MTU, a client and a server are implemented with Python and Erlang. The client is programmed to send both non-semantically UDP packets and DNS packets with no EDNS0 indicator respectively, by comparison. The UDP payload of all the sent packets is designed to be more 512 bytes and sent with increasingly larger size with variable bytes, 32 or 16 for instance, as a step. While the functionality of the very server is listen on 53 ports and 5333 port (other than traditional DNS port) and bounce the received packets to the client. The corresponding client is therefore able to know whether its sent packets could travel through networks to the server.
Two servers are deployed in Beijing, one's upstream ISP is China Science & Technology network and the other's is China Unicom. In order to gain diversity, clients are deployed at ZDNS in Beijing, TWNIC in Taipei, local ISP in Chengdu, China Mobile in Beijing, TCI in Moscow and JPRS in Tokyo. The tests were carried out in alignment with the combination of servers and clients.
As with the current networking conditions, a DNS message can safely pass the overwhelming majority of the intermediate devices along its path, as long as it is with no bigger than 1472 bytes size.
As with observed, generally, firewalls block DNS messages that will lead to IP fragmentation.
Yoshiro YONEYA, JPRS
Nai-Wen HSU, TWNIC
Dmitry KOVALENKO, TCINET