This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
dns_flag_day_2020 [2023/05/24 04:01] – [Cloudflare authoritative DNS and 1.1.1.1] -removed https section from links hogwild | dns_flag_day_2020 [2023/05/24 04:16] – [Cloudflare authoritative DNS and 1.1.1.1] -remove marketing hype, references to "we", since "we" is not FT contributors hogwild | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | Ref: [[https:// | ||
- | |||
{{ : | {{ : | ||
- | October 1 2020 was this year’s DNS Flag Day. Read on to find out all about DNS Flag Day and how it affects Cloudflare’s DNS services (hint: it doesn’t, we already did the work to be compliant). | ||
- | ====== 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 . | + | 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 ===== |
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, | ||
- | ====== Problem with DNS transport over UDP ====== | + | ===== Problem with DNS transport over UDP ===== |
A potential issue with sending DNS messages over UDP is that the sender has no indication of the recipient actually receiving the message. When using TCP, each packet being sent is acknowledged (ACKed) by the recipient, and the sender will attempt to resend any packets not being ACKed. UDP, although it may be faster than TCP, does not have the same mechanism of messaging reliability. Anyone still wishing to use UDP as their transport protocol of choice will have to implement this reliability mechanism in higher layers of the network stack. For instance, this is what is being done in QUIC, the new Internet transport protocol used by HTTP/3 that is built on top of UDP. | A potential issue with sending DNS messages over UDP is that the sender has no indication of the recipient actually receiving the message. When using TCP, each packet being sent is acknowledged (ACKed) by the recipient, and the sender will attempt to resend any packets not being ACKed. UDP, although it may be faster than TCP, does not have the same mechanism of messaging reliability. Anyone still wishing to use UDP as their transport protocol of choice will have to implement this reliability mechanism in higher layers of the network stack. For instance, this is what is being done in QUIC, the new Internet transport protocol used by HTTP/3 that is built on top of UDP. | ||
Line 21: | Line 24: | ||
Even the earliest DNS standards (RFC 1035) specified the use of sending DNS messages over TCP as well as over UDP. Unfortunately, | Even the earliest DNS standards (RFC 1035) specified the use of sending DNS messages over TCP as well as over UDP. Unfortunately, | ||
- | ====== DNS message fragmentation | + | ===== DNS message fragmentation ===== |
Sending data over networks and the Internet is restricted to the limitation of how large each packet can be. Data is chopped up into a stream of packets, and sized to adhere to the Maximum Transmission Unit (MTU) of the network. MTU is typically 1500 bytes for IPv4 and, in the case of IPv6, the minimum is 1280 bytes. Subtracting both the IP header size (IPv4 20 bytes/IPv6 40 bytes) and the UDP protocol header size (8 bytes) from the MTU, we end up with a maximum DNS message size of 1472 bytes for IPv4 and 1232 bytes in order for a message to fit within a single packet. If the message is any larger than that, it will have to be fragmented into more packets. | Sending data over networks and the Internet is restricted to the limitation of how large each packet can be. Data is chopped up into a stream of packets, and sized to adhere to the Maximum Transmission Unit (MTU) of the network. MTU is typically 1500 bytes for IPv4 and, in the case of IPv6, the minimum is 1280 bytes. Subtracting both the IP header size (IPv4 20 bytes/IPv6 40 bytes) and the UDP protocol header size (8 bytes) from the MTU, we end up with a maximum DNS message size of 1472 bytes for IPv4 and 1232 bytes in order for a message to fit within a single packet. If the message is any larger than that, it will have to be fragmented into more packets. | ||
Line 31: | Line 34: | ||
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 this year's 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: [[dnsflagday.net/ | + | You can use the DNS Flag Day site to test your DNS: [[https://dnsflagday.net/ |
- | Reference information is available here: [[blog.cloudflare.com/ | + | Reference information is available here: [[https://blog.cloudflare.com/ |