This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
dns_flag_day_2020 [2023/05/24 04:11] – [DNS message fragmentation] -changed head to subhead1 hogwild | dns_flag_day_2020 [2023/05/24 04:17] (current) – [DNS message fragmentation] hogwild | ||
---|---|---|---|
Line 12: | Line 12: | ||
DNS Flag Day is an initiative by several DNS vendors and operators to increase the compliance of implementations with DNS standards. The goal is to make DNS more secure, reliable and robust. Rather than a push for new features, DNS flag day is meant to ensure that workarounds for non-compliance can be reduced and a common set of functionalities can be established and relied upon. | DNS Flag Day is an initiative by several DNS vendors and operators to increase the compliance of implementations with DNS standards. The goal is to make DNS more secure, reliable and robust. Rather than a push for new features, DNS flag day is meant to ensure that workarounds for non-compliance can be reduced and a common set of functionalities can be established and relied upon. | ||
- | Last year’s flag day was February 1, and it set forth that servers and clients must be able to properly handle the Extensions to DNS (EDNS0) protocol (first RFC about EDNS0 are from 1999 - RFC 2671). This way, by assuming clients have a working implementation of EDNS0, servers can resort to always sending messages as EDNS0. This is needed to support DNSSEC, the DNS security extensions. We were, of course, more than thrilled to support the effort, as we’re keen to push DNSSEC adoption forward. | + | 2019's Flag Day was February 1, and it set forth that servers and clients must be able to properly handle the Extensions to DNS (EDNS0) protocol (first RFC about EDNS0 are from 1999 - RFC 2671). This way, by assuming clients have a working implementation of EDNS0, servers can resort to always sending messages as EDNS0. This is needed to support DNSSEC, the DNS security extensions. We were, of course, more than thrilled to support the effort, as we’re keen to push DNSSEC adoption forward. |
===== DNS Flag Day 2020 ===== | ===== DNS Flag Day 2020 ===== | ||
Line 32: | Line 32: | ||
DNS Flag Day 2020 wants to ensure that DNS message fragmentation does not happen. When larger DNS messages need to be sent, we need to ensure it can be done reliably over TCP. | DNS Flag Day 2020 wants to ensure that DNS message fragmentation does not happen. When larger DNS messages need to be sent, we need to ensure it can be done reliably over TCP. | ||
- | DNS servers need to support DNS message transport over TCP in order to be compliant with this year's flag day. Also, DNS messages sent over UDP must never exceed the limit over which they risk being fragmented. | + | DNS servers need to support DNS message transport over TCP in order to be compliant with the 2020 Flag Day. Also, DNS messages sent over UDP must never exceed the limit over which they risk being fragmented. |
- | ====== Cloudflare authoritative DNS and 1.1.1.1 | + | ===== Cloudflare authoritative DNS and 1.1.1.1 ===== |
- | We fully support | + | Cloudflare |
- | Both our public resolver 1.1.1.1 | + | Both our public resolver 1.1.1.1 |
- | Oh, and you can test your domain on the DNS Flag Day site: [[https:// | + | You can use the DNS Flag Day site to test your DNS: [[https:// |
Reference information is available here: [[https:// | Reference information is available here: [[https:// |