draft-fujiwara-dnsop-avoid-fragmentation-02.txt   draft-fujiwara-dnsop-avoid-fragmentation-03.txt 
Network Working Group K. Fujiwara Network Working Group K. Fujiwara
Internet-Draft JPRS Internet-Draft JPRS
Intended status: Best Current Practice P. Vixie Intended status: Best Current Practice P. Vixie
Expires: October 9, 2020 Farsight Expires: October 15, 2020 Farsight
April 07, 2020 April 13, 2020
Fragmentation Avoidance in DNS Fragmentation Avoidance in DNS
draft-fujiwara-dnsop-avoid-fragmentation-02 draft-fujiwara-dnsop-avoid-fragmentation-03
Abstract Abstract
Path MTU discovery remains widely undeployed due to security issues, Path MTU discovery remains widely undeployed due to security issues,
and IP fragmentation has exposed weaknesses in application protocols. and IP fragmentation has exposed weaknesses in application protocols.
Currently, DNS is known to be the largest user of IP fragmentation. Currently, DNS is known to be the largest user of IP fragmentation.
It is possible to avoid IP fragmentation in DNS by limiting response It is possible to avoid IP fragmentation in DNS by limiting response
size where possible, and signaling the need to upgrade from UDP to size where possible, and signaling the need to upgrade from UDP to
TCP transport where necessary. This document proposes to avoid IP TCP transport where necessary. This document proposes to avoid IP
fragmentation in DNS. fragmentation in DNS.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 9, 2020. This Internet-Draft will expire on October 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Proposal to avoid IP fragmentation in DNS . . . . . . . . . . 3 3. Proposal to avoid IP fragmentation in DNS . . . . . . . . . . 3
4. Default maximum DNS/UDP payload size . . . . . . . . . . . . 5 4. Maximum DNS/UDP payload size . . . . . . . . . . . . . . . . 5
5. Incremental deployment . . . . . . . . . . . . . . . . . . . 5 5. Incremental deployment . . . . . . . . . . . . . . . . . . . 5
6. Request to zone operator and DNS server operator . . . . . . 5 6. Request to zone operator and DNS server operator . . . . . . 5
7. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 7. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Protocol compliance . . . . . . . . . . . . . . . . . . . 6 7.1. Protocol compliance . . . . . . . . . . . . . . . . . . . 6
7.2. DNS packet size . . . . . . . . . . . . . . . . . . . . . 6 7.2. DNS packet size . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. How to retrieve path MTU value to a destination . . 8 Appendix A. How to retrieve path MTU value to a destination . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
DNS has EDNS0 [RFC6891] mechanism. It enables that DNS server can DNS has EDNS0 [RFC6891] mechanism. It enables that DNS server can
send large size response using UDP. Now EDNS0 is widely deployed, send large size response using UDP. Now EDNS0 is widely deployed,
and DNS (over UDP) is said to be the biggest user of IP and DNS (over UDP) is said to be the biggest user of IP
fragmentation. fragmentation.
However, "Fragmentation Considered Poisonous" [Herzberg2013] proposed However, "Fragmentation Considered Poisonous" [Herzberg2013] proposed
skipping to change at page 5, line 5 skipping to change at page 5, line 5
o Fragmented DNS/UDP messages may be dropped without IP reassembly. o Fragmented DNS/UDP messages may be dropped without IP reassembly.
An ICMP error should be sent in this case, with rate limiting to An ICMP error should be sent in this case, with rate limiting to
prevent this logic from becoming a DDoS amplification vector. If prevent this logic from becoming a DDoS amplification vector. If
rate limiting is not possible, then no ICMP error should be sent. rate limiting is not possible, then no ICMP error should be sent.
(This is a countermeasure against DNS spoofing attacks using IP (This is a countermeasure against DNS spoofing attacks using IP
fragmentation.) fragmentation.)
The cause and effect of the TC bit is unchanged from EDNS0 [RFC6891]. The cause and effect of the TC bit is unchanged from EDNS0 [RFC6891].
4. Default maximum DNS/UDP payload size 4. Maximum DNS/UDP payload size
o Most of the Internet and especially the inner core has an MTU of
at least 1500 octets. An operator of a full resolver would be
well advised to measure their path MTU to several authority name
servers and to a random sample of their expected stub resolver
client networks, to find the upper boundary on IP/UDP packet size
in the average case. This limit should not be exceeded by most
answers received or transmitted by a full resolver, or else
fallback to TCP will occur too often. An operator of
authoritative servers would be also well advised to measure their
path MTU to several full-service resolvers. The Linux tool
"tracepath" can be used to measure the path MTU to well known
authority name servers such as [a-m].root-servers.net or [a-
m].gtld-servers.net. If the reported path MTU is for example no
smaller than 1460, then the maximum DNS/UDP payload would be 1432
for IP4 (which is 1460 - IP4 header(20) - UDP header(8)) and 1412
for IP6 (which is 1460 - IP6 header(40) - UDP header(8)). To
allow for possible IP options and faraway tunnel overhead, a
useful default for maximum DNS/UDP payload size would be 1400.
o [RFC4035] defines that "A security-aware name server MUST support o [RFC4035] defines that "A security-aware name server MUST support
the EDNS0 message size extension, MUST support a message size of the EDNS0 message size extension, MUST support a message size of
at least 1220 octets". Then, the smallest number of the maximum at least 1220 octets". Then, the smallest number of the maximum
DNS/UDP payload size is 1220. DNS/UDP payload size is 1220.
o DNS flag day 2020 proposed 1232 as an EDNS buffer size. o DNS flag day 2020 proposed 1232 as an EDNS buffer size.
[DNSFlagDay2020] [DNSFlagDay2020]
o However, in practice, the smallest MTU witnessed in the
operational DNS community is 1500 octets. The estimated size of a
DNS message's UDP headers, IP headers, IP options, and one or more
set of tunnel, IP-in-IP, VLAN, and virtual circuit headers, SHOULD
be 100 octets. Therefore, the maximum DNS/UDP payload size could
be estimated at 100 octets less than the local interface MTU,
which for ethernet would be 1500 - 100 = 1400.
5. Incremental deployment 5. Incremental deployment
The proposed method supports incremental deployment. The proposed method supports incremental deployment.
When a full-service resolver implements the proposed method, its stub When a full-service resolver implements the proposed method, its stub
resolvers (clients) and the authority server network will no longer resolvers (clients) and the authority server network will no longer
observe IP fragmentation or reassembly from that server, and will observe IP fragmentation or reassembly from that server, and will
fall back to TCP when necessary. fall back to TCP when necessary.
When an authoritative server implements the proposed method, its full When an authoritative server implements the proposed method, its full
skipping to change at page 6, line 26 skipping to change at page 6, line 36
Such noncompliant behaviour cannot become implementation or Such noncompliant behaviour cannot become implementation or
configuration constraints for the rest of the DNS. If failure is the configuration constraints for the rest of the DNS. If failure is the
result, then that failure must be localized to the noncompliant result, then that failure must be localized to the noncompliant
servers. servers.
7.2. DNS packet size 7.2. DNS packet size
Many stub resolvers do not set the DNSSEC OK bit. In this case, Many stub resolvers do not set the DNSSEC OK bit. In this case,
responses from full-service resolvers may be small. responses from full-service resolvers may be small.
With 'minimal response' configuration, DNS servers can be forced to With 'minimal-response' configuration, DNS servers can be forced to
emit small responses. emit small responses.
Server |DNSSEC| Answer | Response data |response Server |DNSSEC| Answer | Response data |response
type | OK | type | Answer/Authority/Additional|size type | OK | type | Answer/Authority/Add. | size
---------+------+----------+----------------------------+----- ---------+------+----------+-----------------------+-----
Resolver | No | Exist | RRSet// |minimal Resolver | No | Exist | RRSet// |RRSet
Resolver | No | Not exist| /SOA/ |minimal Resolver | No | Not exist| /SOA/ |SOA
Resolver | Yes | Exist | RRSet+RRSIG// |+RRSIG Resolver | Yes | Exist | RRSet+RRSIG// |RRSet+RRSIG
Resolver | Yes | Not exist| /SOA+NSEC/NSEC3+RRSIG/ |+RRSIG*3 Resolver | Yes | Not exist| /SOA+NSEC+RRSIG/ |SOA+NSEC*2+RRSIG*3
Auth. | No | Referral | /NS/glue |minimal Auth. | No | Referral | /NS/glue |NS+glue
Auth. | No | Exist | RRSet// |minimal Auth. | No | Exist | RRSet// |RRSet
Auth. | No | Not exist| /SOA/ |minimal Auth. | No | Not exist| /SOA/ |SOA
Auth. | Yes | Referral | /DS+RRSIG NS/glue |+DS+RRSIG Auth. | Yes | Referral | /DS+RRSIG+NS/glue |NS+glue+DS+RRSIG
Auth. | Yes | Exist | RRSet+RRSIG// |+RRSIG Auth. | Yes | Referral | /NSEC+RRSIG+NS/glue |NS+glue+NSEC+RRSIG
Auth. | Yes | Not exist| /SOA+NSEC/NSEC3+RRSIG/ |+RRSIG*3 Auth. | Yes | Exist | RRSet+RRSIG// |RRSet+RRSIG
Auth. | Yes | Not exist| /SOA+NSEC*2+RRSIG/ |SOA+NSEC*2+RRSIG*3
Non-existent answers with DNSSEC are largest. Non-existent answers with DNSSEC are largest.
Without 'minimal responses' configuration, DNS servers may add Without 'minimal responses' configuration, DNS servers may add
unnecessary NS RRset in authority section and nameservers' A/AAAA unnecessary NS RRset in authority section and nameservers' A/AAAA
RRSet in additional section. RRSet in additional section.
However, with 'minimal-responses' configuration, zone operators can However, with 'minimal-responses' configuration, zone operators can
control the authoritative server's response size (selection of DNSKEY control the authoritative server's response size (selection of DNSKEY
algorithm and size, and number of resource records). algorithm and size, and number of resource records).
 End of changes. 9 change blocks. 
30 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/