English (US)
Le Français

DNS Flag Day logo

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.

2020-10-01 (October 1st 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,

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.

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

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

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

  • BIND
    options {
      edns-udp-size 1232;
      max-udp-size 1232;
  • Knot DNS
      max-udp-payload: 1232
  • Knot Resolver
  • PowerDNS Authoritative
  • PowerDNS Recursor
  • Unbound
      edns-buffer-size: 1232
  • NSD
      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

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.

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





NLnet Labs


Alibaba Cloud

BlueCat Networks


Space available for the next supporter!

  • Q: TL;DR RFC 7766

    A: DNS MUST work over TCP!

  • Q: Is DNS over UDP dead?

    A: No, DNS over UDP will still be the primary mode of transmission, as it
    is massively scalable, very resource-efficient, and fault-tolerant.

  • Q: Will everything break on 2020-10-01?

    A: No! Latest measurements shown that only
    a tiny percentage
    of sites will be affected. On the
    flag day software vendors will change their default
    behavior in new software releases so that the default message size
    used over UDP will be 1232 bytes. As these new releases are
    deployed, sites that return DNS responses larger than 1232 bytes,
    but which cannot answer DNS queries via TCP, may fail to resolve.
    Note that these sites are already unreliable today.

  • Q: Why is TCP support so important?

    A: Blocking TCP, or failure to support TCP, may result in resolution
    failure and application-level timeouts.

    Furthermore, TCP normally implements Path MTU Discovery and can avoid
    IP fragmentation of TCP segments. It also makes it harder to spoof
    DNS responses.

    TCP support was recommended in the earliest DNS standard
    specifications. Some implementers may have taken that to mean TCP
    was optional, and so in August 2010
    RFC 5966 made it clear that TCP
    support is absolutely required for compliance with the Internet
    standards for DNS.

  • Q: Why not just switch to TCP only?

    A: DNS over UDP is fine for small packets that do not require IP
    fragmentation. It can still be used for that class of DNS messages,
    which is the majority of DNS traffic. Switching everything
    over to TCP may cause stress on DNS services. While in principle
    DNS over TCP only should be feasible, it is slower than DNS over UDP
    by at least a factor of 4 (based on Baptiste Jonglez work
    presented at RIPE76),
    and it may limit the number of connections a DNS server can accept

  • Q: What if we want to use bigger packet sizes in the future?

    A: Our goal is simply to avoid IP fragmentation by choosing a default
    EDNS buffer size that will work well on typical networks today. This
    is not a permanent change to any DNS specification. Default values
    can always be overridden locally if better information is avaialble.
    If a standard method for retrieving MTU data from the kernel becomes
    available, that can be used as well.

  • Q: Will DNS Flag Day 2020 require a software update?

    A: In most cases, no. DNS software which follows published standards does
    not require upgrade and will continue to work. All supported versions
    of major open source DNS servers work correctly now and will continue
    to do so. They can all be configured to use the recommended EDNS
    buffer sizes, even if they have not yet been updated to use those
    sizes by default.

    Whether a particular deployment is compliant depends on the way the
    software is configured, and on the firewall configuration used at
    that site. Less commonly-used and custom or proprietary DNS software
    may not be compliant, and may require updates.

  • Q: Is the requirement for DNS over TCP actually a DNS standard?

    A: Yes, it is. The RFC 1035
    Section 4.2 Transport explicitly lists UDP and TCP transports as
    equals. Furthermore, RFC 7766
    makes the requirement for DNS over TCP mandatory to implement for DNS
    vendors. While it’s at operator’s discretion to allow traffic on the
    TCP port 53, the inability to respond over TCP might lead to resolution
    failure in case of DNS answers bigger than EDNS buffer size chose at
    the client side.

  • Q: I want to support DNS Flag Day 2020, what do I do?

    A: Great to hear! You can add yourself as a supporter by making a
    pull request and
    add name, image and URL to _data/2020_supporters.yml, or make
    an issue
    and supply the same information in that.

Here is a list of the previous DNS Flag Days:

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

Read More

ترك الرد

من فضلك ادخل تعليقك
من فضلك ادخل اسمك هنا