查看“DNS flag day 2020”的源代码


= Contents =

* What’s next?
* DNS Flag Day 2020
** Action: Authoritative DNS Operators
** Action: DNS Resolver Operators
** Action: DNS software vendors
** How to test?
* Who’s behind DNS Flag Day?
* Get in touch
* Supporters
* FAQ
* Previous DNS Flag Days


= What’s next? =
The next DNS Flag Day is scheduled for 2020-10-01. It focuses on the operational and security problems in DNS caused by Internet Protocol packet fragmentation.

On this page you can find comprehensive description of the problem, technical changes planned for 2020-10-01, and ways to test your systems before the set date.

You can also subscribe to the dns-announce mailing list or follow @dnsflagday on Twitter to receive a notification about significant changes.



= DNS Flag Day 2020 =
The DNS community has been discussing persistent interoperability and performance issues with the DNS system on industry mailing lists and at conferences such as DNS-OARC 30 panel discussion (video, slides).

The proposed plan for DNS Flag Day 2020 was announced in October 2019 at RIPE78 by Petr Špaček, CZ.NIC and Ondřej Surý, ISC (video, slides). This year, we are focusing on problems with IP fragmentation of DNS packets.

IP fragmentation is unreliable on the Internet today, and can cause transmission failures when large DNS messages are sent via UDP. Even when fragmentation does work, it may not be secure; it is theoretically possible to spoof ''parts'' of a fragmented DNS message, without easy detection at the receiving end.

* Bonica R. et al, “IP Fragmentation Considered Fragile”, Work in Progress, July 2018
* Huston G., “IPv6, Large UDP Packets and the DNS”, August 2017
* Fujiwara K., “Measures against cache poisoning attacks using IP fragmentation in DNS”, May 2019
* Fujiwara K. et al, “Avoid IP fragmentation in DNS”, September 2019

Recently, there was an paper and presentation Defragmenting DNS - Determining the optimal maximum UDP response size for DNS by Axel Koolhaas, and Tjeerd Slokker in collaboration with NLnet Labs that explored the real world data using the RIPE Atlas probes and the researchers suggested different values for IPv4 and IPv6 and in different scenarios. This is practical for the server operators that know their environment, and the defaults in the DNS software should reflect the minimum safe size which is '''1232'''.

These issues can be addressed by a) configuring servers to limit DNS messages sent over UDP to a size that will not trigger fragmentation on typical network links, and b) ensuring that DNS servers can switch from UDP to TCP when a DNS response is too big to fit in this limited buffer size.



== Message Size Considerations ==
The optimum DNS message size to avoid IP fragmentation while minimizaing the use of TCP will depend on the Maximum Transmission Unit (MTU) of the physical network links connecting two network endpoints. Unfortunately, there is not yet a standard mechanism for DNS server implementors to access this information. Until such a standard exists, we recommend that the EDNS buffer size should, by ''default'', be set to a value small enough to avoid fragmentation on the majority of network links in use today.

An EDNS buffer size of 1232 bytes will avoid fragmentation on nearly all current networks. This is based on an MTU of 1280, which is required by the IPv6 specification, minus 48 bytes for the IPv6 and UDP headers and the aforementioned research.

Note that this recomendation is for a ''default'' value, to be used when better information is not available. Operators may still configure larger values if their networks support larger data frames and they are certain there is no risk of IP fragmentation. DNS server vendors may use higher (or lower) packet sizes if better information about the MTU is available from the kernel.



== Action: Authoritative DNS Operators ==
If you are an authoritative DNS server operator, what you should do to help with these issues is ensure that your DNS servers can answer DNS queries over TCP (port 53). ''Check your firewall(s) as well,'' as some of them block TCP/53.

You should also configure your servers to negotiate an EDNS buffer size that will not cause fragmentation. The value recommended here is 1232 bytes.

''Authoritative DNS servers '''MUST NOT''' send answers larger than the requested EDNS buffer size!''

You can now check your servers by entering your domain name below and pressing “Test!”. This tester uses ISC’s EDNS Compliance Tester and will check that its <code>edns512tcp</code> test is successful, among other tests for general standards compliance.



== Action: DNS Resolver Operators ==
Requrirements on the resolver side are more or less the same as for authoritative: ensure that your servers can answer DNS queries over TCP (port 53), and configure an EDNS buffer size of 1232 bytes to avoid fragmentation. Remember to check your firewall(s) for problems with DNS over TCP!

Most importantly: ''Resolvers '''MUST''' resend queries over TCP if they receive a truncated UDP response (with TC=1 set)!''

'''NEW!''' This checker will test your browser, system and ISP’s resolver by loading an image on a specific URL that can only be looked up if there is support for TCP at the last resolver querying the authority. For more information, go to Check My DNS which this checker uses.



== Action: DNS Software Vendors ==
It is important for DNS software vendors to '''comply with DNS standards''', and to use a default EDNS buffer size (1232 bytes) that will not cause fragmentation on typical network links.

Relevant standards include <nowiki>RFC 7766</nowiki>, <nowiki>RFC 6891</nowiki> section 6.2.3. and <nowiki>RFC 6891</nowiki> section 6.2.4..

The motivation for this effort is described in IETF draft intarea-frag-fragile section 6.1 and IETF draft iab-protocol-maintenance.



== How to test? ==
If you’re the owner of a domain or the operator of an authoritative DNS server, you can use our web-based testing tool to check your domains; you can find it above under Action: Authoritative DNS Operators.

Our web-based testing tool for clients and DNS resolver operators can be found above under Action: DNS Resolver Operators.

You can also test by using the following CLI commands:
 <code>$ dig +tcp @auth_IP yourdomain.example.
 $ dig +tcp @resolver_IP yourdomain.example.
 $ dig @resolver_IP test.knot-resolver.cz. TXT</code>
All DNS queries must be successful, and commands should return the same results both with and without the <code>+tcp</code> option.

If you are a service provider, you can test your authoritative and recursive DNS services by configuring the default EDNS buffer size:

BIND

<code>
options {

  edns-udp-size 1232;

  max-udp-size 1232;

};
</code>

Knot DNS

<code>
server:

  max-udp-payload: 1232
</code>

Knot Resolver
<code>
net.bufsize(1232)
</code>

PowerDNS Authoritative

udp-truncation-threshold=1232

PowerDNS Recursor

edns-outgoing-bufsize=1232

udp-truncation-threshold=1232

Unbound

server:

  edns-buffer-size: 1232

NSD

server:

  ipv4-edns-size: 1232

  ipv6-edns-size: 1232

The configuration above will have no visible effect if everything works correctly. Some queries will fail to resolve if the TCP transport is not available.



= Who’s behind DNS Flag Day? =
The DNS Flag Day effort is community driven by DNS software and service providers, and supported by The DNS Operations, Analysis, and Research Center (DNS-OARC) which most in the community are members of.

If you have technical questions about DNS Flag Day, you can join the DNS-operations mailing list and ask them there.

= Get in touch =
For press & media inquiries please use media (at) dns-oarc.net and please put “DNS Flag Day” in the email subject line.

* Web: <nowiki>https://dnsflagday.net/</nowiki>
* Twitter: <nowiki>https://twitter.com/dnsflagday</nowiki>
* Announcements: <nowiki>https://lists.dns-oarc.net/mailman/listinfo/dns-announce</nowiki>
* Discussion: <nowiki>https://lists.dns-oarc.net/mailman/listinfo/dns-operations</nowiki>