View on GitHub

DNS flag day 2020

English (US) Le Français 日本語 Español 中文(中国)

Thank you!

The 2019 DNS Flag Day was a very successful event. The Internet community worked together and fixed problems which were causing delays and other problems for Internet users worldwide. We would like to thank all operators who cooperated and helped to make Internet a better place.

Summary of the past and future DNS Flag Days can be found e.g. in https://youtu.be/mH_elg9EUWw?t=649.

Contents

What’s next?

The next DNS Flag Day is being planned right now. It will focus on the operational and security problems in DNS caused by Internet Protocol packet fragmentation.

Please subscribe to the dns-announce mailing list or follow @dnsflagday on Twitter to receive a notification when more information becomes available.

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 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.

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.

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.

Note: Work in progress

This web site and some aspects of DNS Flag Day 2020 are works in progress.

Nevertheless, the technical requirements are already clear enough that operators and developers can start preparing by testing and fixing their systems.

If you have comments or suggestions, please join the discussion at the dns-operations mailing list.

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, though it is still up for discussion.

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 edns512tcp test is successful, among other tests for general standards compliance.

Test your domain


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.

Test your resolver


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 RFC 7766, RFC 6891 section 6.2.3. and RFC 6891 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:

$ dig +tcp @auth_IP yourdomain.example.
$ dig +tcp @resolver_IP yourdomain.example.
$ dig @resolver_IP test.knot-resolver.cz. TXT

All DNS queries must be successful, and commands should return the same results both with and without the +tcp option.

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

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.

Previous DNS Flag Days

Here is a list of the previous DNS Flag Days:

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.

Supporters

FAQ