View on GitHub

DNS flag day 2020

English (US) Le Français Nihongo 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


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 the DNS flag day 2020 was announced at RIPE78 by Petr Špaček, CZ.NIC and Ondřej Surý, ISC (video, slides). This time, we will focus on the problems with IP fragmentation of DNS packets.

IP fragmentation is a problem on the Internet today, especially when it comes to large DNS messages. And even if fragmentation works it might not be secure enough for DNS.

These issues can be fixed by honoring an EDNS buffer size that will not cause fragmentation and by allowing DNS to switch from UDP to TCP when larger buffer sizes are not enough.

Note: Work in progress

This web site and some aspects of DNS flag day 2020 are work 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 suggestion then please join the discussion at dns-operations mailing list.

Action: Authoritative DNS Operators

For the authoritative side what you should do to help with these issues is to answer DNS queries over TCP (port 53), check your firewall(s) also!

You should also use an EDNS buffer size that will not cause fragmentation, recommended here is around 1220 bytes but it is still up for discussion.

And lastly, Authoritative DNS servers MUST NOT send answers larger than requested EDNS buffer size!

NEW! You can now check your domain by entering it below and pressing “Test!”. This tester uses ISC’s EDNS Compliance Tester and will check that it’s edns512tcp test is successful among other tests for general compliance.

Test your domain

Action: DNS Resolver Operators

For the resolver side it’s more or less the same requirement as for the authoritative, answer DNS queries over TCP (port 53) and use an EDNS buffer size (~1220 bytes) that will not cause fragmentation. Remember to check your firewall(s)!

And for that last important part, Resolvers MUST repeat queries over TCP if they receive a truncated UDP response (with TC=1 set)!

Tester for clients DNS resolver is in development!

Action: DNS software vendors

As a DNS software vendor it is important to be standards compliant and to use a default EDNS buffer size (~1220) that will not cause fragmentation.

Relevant standards are mainly RFC 7766, RFC 6891 section 6.2.3. and RFC 6891 section 6.2.4..

Motivation for the change is described in IETF draft intarea-frag-fragile section 6.1 and IETF draft iab-protocol-maintenance.

How to test?

If you’re a domain owner or an authoritative DNS operator you can use our web-based testing tool to check a domain, you will find it under Action: Authoritative DNS Operators.

We are working on a web-based testing tool for clients and DNS resolver operators and once it’s ready you will find it on this page,

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 TXT

All DNS queries must be successful and commands with +tcp option or without it should return the same. If you are a service provider you can also test your authoritative and resolver services by allowing DNS over TCP and changing the configuration for the default EDNS buffer size:

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

Previous flag days

Here is a list of the previous 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 around 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) and please put “DNS Flag Day” in the email subject line.