User Tools
dns_flag_day_2020
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
| dns_flag_day_2020 [2023/05/24 04:03] – -removed marketing hype hogwild | dns_flag_day_2020 [2023/05/24 04:10] – [DNS Flag Day 2020] -changed head to subhead hogwild | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| {{ : | {{ : | ||
| - | October 1 2020 was this year’s DNS Flag Day. | ||
| - | ====== What is DNS Flag Day? ====== | + | |
| + | ====== DNS Flag Day ====== | ||
| + | |||
| + | October 1 was the date of DNS Flag Day in 2020. | ||
| + | |||
| + | ===== What is DNS Flag Day? ===== | ||
| 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 . | + | 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. |
| - | ====== DNS Flag Day 2020 ====== | + | ===== DNS Flag Day 2020 ===== |
| The goal for this year’s flag day is to increase DNS messaging reliability by focusing on problems around IP fragmentation of DNS packets. The intention is to reduce DNS message fragmentation which continues to be a problem. We can do that by ensuring cleartext DNS messages sent over UDP are not too large, as large messages risk being fragmented during the transport. Additionally, | The goal for this year’s flag day is to increase DNS messaging reliability by focusing on problems around IP fragmentation of DNS packets. The intention is to reduce DNS message fragmentation which continues to be a problem. We can do that by ensuring cleartext DNS messages sent over UDP are not too large, as large messages risk being fragmented during the transport. Additionally, | ||
dns_flag_day_2020.txt · Last modified: 2023/05/24 04:17 by hogwild
Page Tools
