DNS Infrastructure & Naming Conventions

7/20/2026

Introduced Cloudflare Internal DNS, a new product offering that provides authoritative and recursive DNS for private networks. This new capability consolidates public and private DNS management onto a single platform, simplifies split-horizon DNS configurations through DNS Views, extends Zero Trust policies to DNS resolution via Gateway Resolver policies, and enables the retirement of legacy DNS infrastructure. The system comprises a Gateway Resolver for recursive resolution and policy evaluation, and Internal Authoritative DNS built on Cloudflare's existing authoritative platform. Key components include Internal Zones, DNS Views for context-specific resolution, and Resolver Policies for routing queries. Changes propagate rapidly through a unified API and global replication, with record updates taking effect in seconds.

7/14/2026

Introduced Extended DNS Error (EDE) code 33 to signal the use of Negative Trust Anchors (NTAs) during DNSSEC validation bypasses. This provides transparency to clients and monitoring tools about why a response was served without full DNSSEC validation. Implemented this alongside EDE 9 (DNSKEY Missing) during the .al TLD DNSSEC incident. Updated kdig and submitted a pull request for Unbound to recognize EDE 33. Submitted an Internet-Draft to the IETF DNSOP Working Group for standardization.

5/6/2026

This post details Cloudflare's response to a DNSSEC outage affecting the .de TLD. It explains the technical details of DNSSEC, the observed impact on 1.1.1.1 (spike in SERVFAILs, increased query volume), the effectiveness of 'serve stale' (RFC 8767) in mitigating user impact, and the implementation of a temporary mitigation equivalent to a Negative Trust Anchor (NTA) to bypass DNSSEC validation for .de domains. It also highlights a bug in Extended DNS Error (EDE) propagation for DNSSEC validation failures.

4/15/2026

This post introduces the beta release of the Cloudflare Registrar API, enabling programmatic domain search, availability checks, and registration. This significantly enhances the developer experience by allowing domain management within agentic workflows, editors, and deployment pipelines, aligning with Cloudflare's at-cost pricing model and extending its DNS infrastructure capabilities into automated domain lifecycle management.

4/1/2026

This post reinforces Cloudflare's ongoing commitment to privacy for the 1.1.1.1 public DNS resolver by detailing the results of a recent independent privacy examination. It highlights the unchanged core privacy guarantees (no selling/sharing of data, anonymization of IPs within 25 hours) and mentions the rebuilding of the underlying platform for 1.1.1.1. It also clarifies the evolving use of anonymized logs for services like Cloudflare Radar, while emphasizing that personal privacy is not impacted.

1/14/2026

This post details a critical incident where a memory optimization in the 1.1.1.1 cache implementation led to a change in CNAME record ordering within DNS responses. This change, which moved CNAME records to appear after A/AAAA records, broke specific DNS client implementations that expected CNAMEs to precede other records in the answer section. The post explains the technical details of the code change, the mechanism by which CNAME chains are resolved and cached, and the specific parsing logic in affected clients (glibc's getaddrinfo and Cisco's DNSC) that caused resolution failures and reboot loops. It also delves into the ambiguity of RFC 1034 regarding the order of records in DNS messages, contrasting it with the concept of RRsets where order is explicitly stated as insignificant. The post highlights the lack of specific tests for this ordering behavior and the challenges in defining a universally correct DNS response format.

11/7/2025

This post introduces a self-serve BYOIP API, automating the complex and time-consuming manual process of onboarding customer IP prefixes. It leverages RPKI and other security standards for faster and more secure ownership validation, enhancing Cloudflare's IPAM platform and empowering customers with greater control over their IP addresses on the network.

10/31/2025

This post introduces the concept of 'BGP zombies' and the underlying issue of 'path hunting' within internet routing. It details how delays in BGP prefix withdrawals, exacerbated by factors like router software, processing slowness, and the Minimum Route Advertisement Interval (MRAI), can lead to routes becoming stuck in the Default-Free Zone. The post illustrates these concepts with diagrams and observed network loops, highlighting the impact on traffic and the longer convergence times observed, especially for IPv4. It also connects these issues to Cloudflare's BYOIP and Magic Transit offerings, indicating an active effort to understand and mitigate these routing anomalies within their network and for their customers.

10/27/2025

This post introduces new Top-Level Domain (TLD) insights on Cloudflare Radar, expanding the platform's DNS capabilities. It details the launch of a dedicated TLD page that provides aggregated data on TLD popularity, activity, and security, using metrics like DNS Magnitude. The post also highlights existing security-related insights from email security and Certificate Transparency, and explains the methodology behind DNS Magnitude, which estimates a domain's visibility based on unique network queries. Furthermore, it describes the detailed per-TLD pages offering general information, WHOIS data, and direct registration links via Cloudflare Registrar.

7/15/2025

This post details a specific incident where a misconfiguration in service topologies led to a 62-minute outage of the 1.1.1.1 public DNS Resolver. It explains the root cause involving legacy systems for advertising IP addresses, the accidental inclusion of 1.1.1.1 prefixes in a pre-production Data Localization Suite (DLS) service topology, and how a subsequent change triggered the withdrawal of these prefixes globally. The post also discusses the technical investigation, the interaction between legacy and newer configuration systems, the impact on DNS traffic (UDP, TCP, DoT, but not DoH due to different IP usage), and the BGP route withdrawal. It outlines the incident timeline and the fix deployed, emphasizing the need for progressive deployment methodologies and improved synchronization between configuration systems.

2/27/2025

This post introduces a new dedicated DNS page on Cloudflare Radar, significantly enhancing visibility into aggregate DNS traffic and usage trends. It leverages data from the 1.1.1.1 resolver and the AS112 project to provide insights into query volume, geographical distribution, protocol usage (UDP, DoT, DoH, TCP), query types, and DNSSEC adoption. The post details how this data can be used to understand internet activity beyond web traffic, corroborate reported outages, and highlight regional differences in privacy concerns.

2/10/2025

This post details the discovery and patching of a broadcast amplification vulnerability in Cloudflare's QUIC implementation. It explains how the vulnerability arose from the interaction of QUIC's handshake mechanism, IP broadcast addresses, and Cloudflare's Anycast routing strategy, where IP address ranges are bound to loopback interfaces. The post highlights the specific Linux kernel routing configurations (local and broadcast routes) that, when combined with QUIC's handling of broadcast initial packets, led to an amplification vector. Cloudflare's mitigation involved patching this specific configuration to prevent the amplification.

11/8/2024

This post details the Topaz system, a formal verification framework for Cloudflare's authoritative DNS addressing behavior. It introduces a Lisp-like DSL for encoding DNS business objectives as programs, which are then formally verified using a model checker written in Racket + Rosette. The post explains the components of a Topaz program (config, match, response) and provides examples of how these programs are used to determine IP addresses for proxied domains, including scenarios for attack mitigation, feature testing, and renumbering. It highlights the system's production use and its role in ensuring correctness and preventing conflicts in DNS configuration.

10/29/2024

This post details the technical challenges and solutions involved in migrating Cloudflare's active DNS database, containing billions of records, from a monolithic PostgreSQL cluster (cfdb) to a new, partitioned cluster (dnsdb). Key contributions include the design and implementation of a custom Change Data Capture and Transfer Service (CDCTS) to ensure near real-time data synchronization and minimize downtime, the logical decoupling of DNS record data from zone data, and the introduction of a gRPC API for controlled access to DNS data. The migration also involved partitioning the primary DNS record table (_cf_rec_) based on zone_id and implementing bidirectional data transfer capabilities for rollback.

9/24/2024

This post announces a new partnership program allowing ISPs and network equipment providers to integrate Cloudflare's 1.1.1.1, 1.1.1.2, and 1.1.1.3 DNS resolvers for free. It details the benefits of each resolver (privacy, security, family filtering) and highlights the ease of integration and the scale of Cloudflare's network. It also mentions the availability of Cloudflare Gateway for more advanced, customizable filtering options for multi-tenant environments.

9/23/2024

Introduced batched API calls to the DNS records API, allowing for multiple DNS record operations (POST, PUT, PATCH, DELETE) in a single request. This significantly improves efficiency for managing large numbers of records. The implementation involved backend optimizations to reduce database query latency by removing redundant existence checks and introducing database batching. Propagation to the edge is handled via Quicksilver, with the caveat that edge propagation is not atomic. Also added UI support for batch deletion and proxy status changes.

9/20/2024

This post details an incident where routine maintenance led to the inadvertent withdrawal of fifteen IPv4 prefixes, affecting some Business plan websites for approximately one hour. The root cause was an internal software error in the IP address synchronization mechanism, exacerbated by a legacy code update that suppressed updates for websites without legacy SSL configurations. The incident highlights the importance of explicit verification of website-to-IP address mappings before withdrawing prefixes and the need for improved testing and process controls around IP prefix management and BGP announcements.

7/4/2024

This post details a specific incident on June 27, 2024, where the 1.1.1.1 DNS resolver experienced degradation due to a combination of BGP hijacking (1.1.1.1/32 originated by ELETRONET S.A.) and a route leak (1.1.1.0/24 leaked by Nova Rede de Telecomunicações Ltda). It outlines the technical mechanisms of BGP hijacks (Longest Prefix Matching) and route leaks (RFC7908 Type 1), provides a detailed timeline of the incident and Cloudflare's response, and presents impact data showing affected traffic routing to Brazil with high latency. The post reiterates the importance of RPKI for route origin validation and advocates for its wider adoption, alongside ASPA objects, to prevent future incidents.

6/21/2024

This post analyzes the technical implementation and impact of internet shutdowns in Syria, Iraq, and Algeria during exam periods. It details how these shutdowns are achieved through routing changes (specifically, not announcing IP address space) and examines the resulting traffic patterns observed on Cloudflare's network, including spikes in UDP-based DNS queries to 1.1.1.1 due to failed TCP handshakes and the complete cessation of TCP-based traffic. It also analyzes traffic to Cloudflare's authoritative DNS service, noting increased retry attempts. The post provides specific data on traffic drops and routing changes for Syrian Telecom (AS29256) and discusses the implications for various internet protocols and applications.

4/12/2024

This post announces the official release of Foundation DNS, an enhanced authoritative DNS offering for enterprise customers. Key technical advancements include: advanced nameservers distributed across multiple TLDs and Anycast groups for increased resilience against outages and DDoS attacks; zone-level DNS settings for more flexible configuration; unique DNSSEC keys per account and zone for enhanced security; and GraphQL-based DNS analytics for deeper query insights. The post details the technical rationale behind the new nameserver configuration, explaining how spreading IPs across multiple TLDs and using fewer, but more resilient, Anycast groups improves reliability compared to the previous model.

2/29/2024

This post details the mitigation of two DNSSEC vulnerabilities, CVE-2023-50387 (Keytrap) and CVE-2023-50868 (NSEC3 iteration and closest encloser proof). For Keytrap, Cloudflare implemented signature validation limits per RRSET and a total signature validation limit per resolution task, failing queries that exceed these limits with EDE code 0. For NSEC3, a limit for total hash calculations per resolution task was added, failing queries with EDE code 27. Both mitigations include new metrics for attack detection. The post also outlines the timeline of patching for Cloudflare's public resolver (1.1.1.1) and internal resolvers.

12/14/2023

This post details an experiment using DNS query data from Cloudflare's 1.1.1.1 recursive resolver to estimate worldwide IPv6 adoption on both the client and server sides. It analyzes the ratio of AAAA queries to A queries to gauge client-side adoption and examines the success rate of AAAA queries to infer server-side adoption. The findings are compared with existing HTTP traffic data from Cloudflare Radar, highlighting the nuances and challenges in measuring IPv6 adoption across different perspectives.

12/5/2023

This post details a German court's decision rejecting a request to block websites via public DNS resolvers like 1.1.1.1. It explains the role of DNS resolvers, distinguishes public from private resolvers, and argues why blocking through public resolvers is ineffective, disproportionate, and lacks transparency. The decision highlights that DNS services are protected by the EU's Digital Services Act (DSA) as 'mere conduit' services, reinforcing Cloudflare's position.

10/4/2023

This post details a specific incident where a new DNS record type (ZONEMD) caused parsing failures in Cloudflare's static_zone application, preventing the update of the root zone cache. This led to the use of a stale root zone with expired DNSSEC signatures, resulting in an increase in SERVFAIL responses. The post explains the technical details of the failure, including the binary DNS format, RDLENGTH handling, and the behavior of the static_zone application when parsing fails. It also describes the incident timeline, impact, and the steps taken to resolve the issue, including disabling the static_zone app and the partial impact due to rolling reboots and serve stale mechanisms.

9/22/2023

This post analyzes traffic patterns to `exmaple.com`, a domain intentionally registered to capture typos of the reserved `example.com` domain. It details the volume and nature of traffic, identifying it as predominantly bot-related (99.99%) and often unencrypted HTTP. The analysis highlights specific Autonomous Systems (ASNs), such as Bouygues Telecom (AS5410), as major sources of this traffic, suggesting potential misconfigurations. It also notes the increasing use of IPv6 and generic user agents in this bot traffic, and touches upon the low percentage of traffic categorized as DDoS attacks. The post emphasizes the importance of identifying and resolving such misconfigurations for efficient and secure network operations.

7/14/2023

Introduced 'Version Comparisons' for Zone Versioning, enabling side-by-side visual diffs of configuration changes between two versions. This feature aims to simplify the evaluation of new zone configurations before production deployment by providing a 'diff'-like experience for GUI-managed configurations.

7/11/2023

This post details an incident where expired DNSSEC signatures from Verisign's .com and .net TLD nameservers in the Asia Pacific region caused DNS resolution failures. The issue was remediated by rerouting DNS traffic to US west coast nameservers, and Verisign confirmed the resolution of serving stale data.

3/20/2023

This post explores the complex rules governing TCP port sharing in Linux, detailing how different combinations of local IP addresses, ports, and the use of SO_REUSEADDR affect socket binding and connection establishment. It provides a deep dive into the kernel's internal mechanisms for managing network ports and sockets, which is crucial for understanding the underlying infrastructure that supports Cloudflare's global network and its ability to handle massive amounts of traffic efficiently and reliably.

2/28/2023

This post details the development of BigPineapple, a new Rust-based recursive DNS resolver for Cloudflare's 1.1.1.1 service, replacing the previous Knot Resolver. It addresses limitations in Knot Resolver's Lua plugin system, I/O blocking, cache efficiency, and module isolation. BigPineapple utilizes Rust's async runtime (tokio) for non-blocking I/O and work-stealing, a redesigned module system for better isolation, and a component-based architecture (server, worker, cache, recursor, conductor, sandbox) for improved performance and maintainability. Key improvements include an updated I/O architecture with a "frame" abstraction for unified protocol handling and a conductor component for intelligent upstream nameserver selection and connection management.

12/21/2022

Introduced custom comments and tags for DNS records, allowing users to add metadata for better organization and easier identification of record purposes. Tags are available for Pro, Business, and Enterprise plans. These attributes are supported via the API, dashboard, and zone file imports/exports. New filtering capabilities in the dashboard allow users to search and manage records based on these comments and tags.

12/15/2022

Cloudflare is joining the AS112 project as an operator of its anycast deployment of DNS servers. This initiative aims to handle reverse DNS lookup queries for private-use IP addresses that are misdirected to the public DNS system, reducing unwanted load on the internet. Cloudflare's global network will improve the stability, reliability, and performance of this distributed public service. The post details the problem of misdirected queries for private IP addresses (RFC 1918 ranges and link-local addresses), explains reverse DNS lookups, and describes the AS112 project's history, direct delegation, and DNAME redirection mechanisms.

11/23/2022

Introduced Cloudflare Radar's route leak data and API, enabling public access to information about route leaks across the Internet. Developed a comprehensive system that ingests data from public sources and Cloudflare's global network view to detect and report route leaks. Integrated this data into Cloudflare Radar's ASN pages and made it available via an API. Detailed the BGP protocol, the definition and types of route leaks (Type 1, 2, 3, and 4 as per RFC7908), and the technical implementation of Cloudflare's route leak detection system.

8/25/2022

This post is a curated list of blog posts that explain how the Internet works and delve into various technical topics. It references posts on TCP optimization, Linux kernel live-patching with eBPF, Early Hints, Internet Explorer's demise, TCP stack behavior, Ramadan's impact on internet trends, Hertzbleed attack, future-proofing SaltStack for quantum security, QUIC proxying with MASQUE, HPKE for public-key encryption, post-quantum signatures, and the evolution of internet privacy. It also includes historical context on the internet's development and its underlying technologies like BGP and DNS.

5/25/2022

This post announces the expansion of Extended DNS Error (EDE) code support in Cloudflare's 1.1.1.1 DNS resolver. It details how EDE codes provide richer debugging information for SERVFAIL responses, specifically demonstrating their utility in diagnosing DNSSEC validation failures by returning specific error codes like 'DNSKEY Missing' and 'Unsupported DNSKEY Algorithm'. The post also lists the newly supported EDE codes and provides examples of how to use `dig` and `kdig` to observe these enhanced error messages.

5/25/2022

Introduced a per-record build system for DNS records, replacing the previous full-zone build approach for most changes. This involved creating a new Kafka event pipeline for record changes, separating the Zone Builder into distinct scheduler types (full-zone and per-record), implementing ordered event processing for per-record builds, and adapting the Quicksilver interface. Addressed bugs related to stale record cleanup during updates, particularly when record names changed, by treating updates as a delete followed by a create.

5/3/2022

This post announces the general availability of wildcard DNS record proxying, a feature previously restricted to Enterprise customers. It details the functionality of wildcard DNS records, including their behavior and limitations as defined by RFC4592. The post explains how proxying these records allows Cloudflare's network features to be applied to all subdomains not explicitly defined, and how Cloudflare automatically manages TLS certificates for these proxied wildcards.

4/3/2022

This post details observations on how the Russian government is asserting control over its internet infrastructure, including the implementation of Russian DNS servers and blocking of external websites. It also highlights the increased adoption of tools like Cloudflare WARP/1.1.1.1 by Russian citizens seeking access to the open internet, and the detection of increased cyberattacks originating from Russia.

3/9/2022

This post details a specific DNSSEC misconfiguration at the .fj ccTLD that caused widespread outages. It explains how a missing DNSKEY record in the root zone, likely due to an improperly timed rollover, led to SERVFAIL errors for resolvers performing strict DNSSEC validation. The post uses `dig` output and Cloudflare's 1.1.1.1 resolver data to illustrate the problem and its resolution, emphasizing the significant impact of ccTLD-level DNSSEC errors.

3/8/2022

This post introduces and details the experimental deployment of Discovery of Designated Resolvers (DDR) in Cloudflare's 1.1.1.1 service. It explains the motivation for DDR, focusing on increasing the adoption of encrypted DNS transports. The post elaborates on the threat model, the mechanics of DDR (utilizing certificate-based authentication and SVCB records), and provides a concrete example of how to test it using `dig`. The implementation allows clients to discover and upgrade to secure DNS connections with the same resolver, ensuring authenticity.

12/8/2021

Introduced Foundation DNS, a premium DNS offering with advanced nameservers for enhanced resilience against route leaks. This includes support for outgoing zone transfers for Secondary DNS and Logpush for authoritative and secondary DNS queries. Pricing is simplified to be based on total DNS queries per month, with unmetered DDoS mitigation.

11/12/2021

This post highlights the user-friendly aspects of Cloudflare DNS for individuals and small businesses, emphasizing its role in domain registration, DNS record configuration, and security best practices like DNSSEC and DMARC. It also introduces Cloudflare for Teams' DNS Gateway for network-level security and logging, and the 1.1.1.1 app with WARP for encrypted DNS resolution and traffic security on end-user devices. The post showcases how these free offerings simplify and enhance DNS management and security for a broad range of users.

10/14/2021

This post introduces 'Addressing Agility,' a novel approach to decouple IP addresses from names and services. It argues that IP addresses should represent reachability, not names, and proposes an inversion of the traditional DNS lookup process. Instead of pre-assigning IP addresses to names, policies are defined with attributes (e.g., location, account type) that map to pools of equivalent IP addresses. These addresses are then assigned dynamically at query time, making the IP-to-name binding ephemeral and enabling greater flexibility in service provisioning, migration, and innovation.

10/13/2021

This post details Cloudflare's active participation in the IETF, contributing to the development and standardization of key internet protocols like DNS-over-HTTPS (DoH), Oblivious DNS-over-HTTPS (ODoH), QUIC, and TLS Encrypted Client Hello (ECH). These contributions aim to incrementally improve metadata privacy, advance architectural capabilities, and enable new use cases by developing and advocating for open standards.

10/8/2021

This post analyzes the impact of the Facebook outage on Cloudflare's 1.1.1.1 DNS resolver, detailing a significant increase in SERVFAIL responses across DNS, DoT, and DoH protocols. It quantifies the load increase on the resolver and demonstrates its resilience by maintaining low response times. The post also uses DNS query data to illustrate traffic shifts to other internet services (social media, messaging, gaming, news) during the outage and analyzes Network Error Logging (NEL) data and WARP traffic to Facebook's network. Finally, it examines the silence of Facebook's crawlers and the impact on traffic with Facebook User-Agents hitting Cloudflare's CDN.

10/4/2021

This post details the external observation of Facebook's outage from Cloudflare's perspective, focusing on the BGP route withdrawals that led to DNS SERVFAIL responses for Facebook services. It explains the role of BGP and ASNs in internet routing and how Facebook's lack of BGP announcements caused its services to become unreachable. The post also analyzes the surge in DNS queries to other platforms and the impact on Cloudflare's 1.1.1.1 resolver, demonstrating its scalability.

9/28/2021

This post announces the full availability of Cloudflare Registrar to all customers, enabling new domain registrations and transfers at cost. It introduces over 40 new TLDs, starting with .uk, and outlines plans to support more country-code TLDs, premium domains, and Internationalized Domain Names (IDNs) in the future. The post also provides a primer on the registrar and registry roles and details Cloudflare's journey from managing its own domains to offering a secure, privacy-focused, and cost-effective registrar service to everyone.

9/12/2021

This post details the technical reasons behind the speed of Cloudflare's 1.1.1.1 DNS resolver and its authoritative DNS services. It explains the importance of caching and geographical proximity (closeness) in reducing DNS lookup latency. It also touches upon the role of DNS in the overall web request lifecycle, including its dependency on TLS and TCP handshakes, and the impact of network congestion and packet loss.

8/2/2021

This post details the delivery of Cloudflare's protective DNS resolver solution to the US Federal Government via CISA, in partnership with Accenture Federal Services. It highlights the use of Cloudflare Gateway to filter DNS queries from government offices and stream events to Accenture's analysis platform. The post explains how protective DNS resolvers apply a Zero Trust model to DNS queries by checking hostnames against a list of known malicious destinations, preventing connections to threats. It also mentions the enrichment of Cloudflare's threat data with Accenture's Cyber Threat Intelligence (ACTI) feed and the use of AI and machine learning for threat detection. The post also touches upon the ongoing work towards FedRAMP approval for Cloudflare's Zero Trust solutions.

7/22/2021

Introduced a new China Network built in partnership with JD Cloud, enabling DNS queries to be answered from within mainland China. This involves assigning two nameservers from a set of custom TLDs (.com, .net, .tech) to achieve 'glueless delegations' and avoid the need for glue records. This allows for dynamic nameserver IP assignment, ensuring queries are answered from the nearest Point of Presence (PoP) for faster response times and improved reliability, while also enabling better load distribution and attack mitigation.

3/8/2021

This post details the implementation and testing of Unbound's `serve-expired` feature to improve DNS resolution latency and resilience when using Consul for service discovery. It covers the configuration of `serve-expired`, `serve-expired-ttl`, and `serve-expired-client-timeout`, and demonstrates successful testing scenarios for serving stale records indefinitely, handling negative/incomplete information, and background cache refreshing. It also notes an upstream fix for prefetching logic blocking stale cache serving.

3/4/2021

This post investigates why conntrack does not record entries for SYN packets dropped by the firewall. It details the reliance of conntrack on Netfilter hooks and the `enable_hooks` parameter for module load time hook registration. The analysis uses BPF kprobes to trace conntrack callbacks (`ipv4_conntrack_defrag` and `ipv4_conntrack_in`) and demonstrates that these callbacks are not invoked for dropped SYN packets by default, leading to their absence in the conntrack table.

1/13/2021

Introduced a new resolver for the Distributed Web that allows access to IPFS content indexed by ENS. This resolver is built on Cloudflare Workers and leverages Cloudflare's Ethereum and IPFS Gateways. It handles '.link' appended ENS domains, resolving CIDs from Ethereum and fetching content from IPFS.

12/14/2020

Introduced 'Secondary DNS Override' feature, enabling Cloudflare's HTTP proxy services to be used in conjunction with Cloudflare's Secondary DNS offering. This was achieved by allowing Cloudflare to selectively respond to DNS queries with its own IP space, thereby activating proxy services for specific web applications. The feature was developed based on customer feedback and use cases from a large financial institution and another organization with automated DNS record updates.

12/8/2020

This post introduces Oblivious DNS over HTTPS (ODoH), a new proposed DNS standard co-authored by Cloudflare engineers. ODoH enhances DNS privacy by separating IP addresses from DNS queries using a proxy and public key encryption. It ensures that no single entity can see both the query and the client's IP address simultaneously. The post details the ODoH message flow, the roles of the target, proxy, and client, and the cryptographic mechanisms (HPKE, DNSSEC) involved. It also addresses performance considerations, showing that the additional encryption overhead is marginal.

11/30/2020

Introduced a multi-primary authoritative nameserver setup for the infrastructure DNS zone, using both Cloudflare's edge and a third-party DNS provider. Implemented OctoDNS for managing zone data across providers and developed custom source modules (ProvAPI, NetBox) for automated record provisioning. Modified DNSDist configuration to implement weighted routing and active checks for internal DNS resolution, preferring Cloudflare's infrastructure when available and failing over to the third-party provider during outages.

11/13/2020

This post details the SAD DNS attack, which exploits UDP fragmentation and ICMP error messages to bypass source port randomization in DNS resolvers, enabling DNS cache poisoning. Cloudflare has mitigated this vulnerability by disabling fragmented DNS responses and enhancing its recursive resolver to reject malformed ICMP error messages. The post also provides background on DNS basics, the DNS ecosystem, and previous attacks like Kaminsky's attack, highlighting the ongoing challenges in securing DNS communications over UDP.

10/30/2020

Introduced support for Extended DNS Errors (EDE) in Cloudflare Resolver, allowing for more detailed diagnostic information to be returned alongside SERVFAIL responses. This involves leveraging EDNS OPT records to convey INFO-CODEs and EXTRA-TEXT, providing clients with specific reasons for DNS resolution failures without altering the existing RCODE.

10/2/2020

This post details Cloudflare's compliance with DNS Flag Day 2020, an initiative focused on increasing DNS messaging reliability by addressing IP fragmentation of DNS packets. It explains the problems with UDP transport for DNS, the importance of DNS over TCP, and how Cloudflare's authoritative DNS and 1.1.1.1 resolver already adhere to the standards by enforcing UDP message size limits and supporting TCP, thus requiring no action from existing users.

10/1/2020

This post announces that Network Time Security (NTS) for NTP has become an official RFC (RFC 8915). It highlights Cloudflare's role in developing, promoting, and implementing NTS, including releasing source code and providing a public time service that supports NTS. The post emphasizes the security implications of accurate time synchronization and the vulnerabilities addressed by NTS, urging wider adoption by operating systems and administrators.

9/30/2020

This post details Cloudflare's rollout of support for the SVCB/HTTPS DNS record type. It explains how this record type allows clients to discover support for HTTP/3 and HTTP/2 directly from DNS, enabling faster secure connection negotiation and skipping initial unencrypted HTTP requests. It also covers the 'alias form' of SVCB/HTTPS records, which provides CNAME-like functionality for apex domains. Cloudflare automatically generates these records for customers enabling HTTP/3.

9/15/2020

This post details the implementation of Cloudflare's Secondary DNS service, including its microservice architecture (Zone Transferer, Zone Transfer Scheduler, Rest API, Notify Listener) communicating via Kafka. It describes the migration from Mesos Marathon to Kubernetes, addressing challenges related to distributed reliability and IP allowlisting by proxying egress traffic with Shadowsocks-libev. It also covers protecting the Notify Listener from attacks by leveraging Cloudflare's DDoS protection and Spectrum.

8/20/2020

Introduced Secondary DNS Override, a feature that allows customers to serve DNS records through Cloudflare's network while using a different primary DNS provider. This feature enables proxying of A/AAAA/CNAME records through Cloudflare's network, hiding origin IPs and leveraging Cloudflare's security and performance benefits. It also details the handling of CNAME at the apex and the record merging logic.

6/18/2020

This post delves into the historical evolution of the SIGSEGV signal's naming convention, tracing its origins from 'SIGSEG' in early UNIX systems to 'SIGSEGV' in userspace and kernel, highlighting how even fundamental system signals have a rich history of development and standardization. It showcases Cloudflare's deep dive into the historical context of system-level behaviors and their naming, which is relevant to understanding the foundational aspects of internet infrastructure.

5/25/2020

Introduced a confirmation step for DNS record edits in the UI to prevent accidental changes and improve reliability. This applies to all record types and affects content, TTL, and proxy status changes.

5/25/2020

Introduced a new, simplified onboarding experience for Secondary DNS through the Cloudflare Dashboard, reducing setup time to under two minutes. This includes error prevention mechanisms to ensure primary server configuration before zone addition and allows customers to review transferred records before completion. The post also details the technical intricacies of secondary DNS, including zone transfers (AXFR/IXFR), SOA record updates, NOTIFY queries, and the importance of securing zone transfers with TSIGs.

4/2/2020

This post details an incident where a mistake in the categorization data for the 1.1.1.1 for Families service led to the inadvertent blocking of LGBTQIA+ sites. The issue was caused by selecting the wrong 'Adult Content' feed from a licensed provider, which included a broader set of topics than intended. The fix involved pulling the incorrect data feed, regenerating the data structure with the correct definition, and pushing it out to all data centers. Additionally, individual sites were added to an allow list immediately as they were reported. Future protections include setting up checks for known sites that should fall outside the intended categories before defaults are updated.

4/1/2020

Introduced 1.1.1.1 for Families, a new DNS resolver service with two options: 1.1.1.2 for malware blocking and 1.1.1.3 for malware and adult content blocking. This leverages existing site categorization and filtering technology from Cloudflare Gateway to provide enhanced security and parental controls for home networks.

10/29/2019

This post explains the concepts and mechanisms behind DNS over TLS (DoT) and DNS over HTTPS (DoH), detailing how they encrypt DNS queries and responses to enhance user privacy and security. It contrasts unencrypted DNS with these encrypted methods, illustrating the packet structures and TLS handshake involved in DoT, and the use of HTTPS for DoH. The post also discusses potential attacks like SSL stripping and the advantages of DoH in using standard HTTPS ports to avoid firewall blocking.

6/21/2019

This post introduces time.cloudflare.com, a free time service supporting NTP and the emerging Network Time Security (NTS) protocol. It highlights the critical role of accurate and secure time synchronization for internet security, detailing vulnerabilities in the original NTP protocol and the need for cryptographic authentication. This expands the scope of the DNS Infrastructure thread to include the security of other fundamental internet protocols that rely on accurate time for their security guarantees.

3/15/2019

This post announces the publication of RFC8482, which deprecates the DNS ANY query type. It details the historical context, the challenges ANY posed for modern DNS servers (difficulty in retrieving 'all records' due to dynamic response generation), clients (unpredictable semantics), and network operators (amplification attacks). Cloudflare's proactive stance on deprecating ANY is highlighted, along with their implementation of responding with HINFO or NOTIMP codes. The post encourages other implementers to clean up their ANY handling code.

2/22/2019

This post announces the general availability of Cloudflare Registrar, highlighting its key benefits: at-cost domain registration, simplified DNSSEC enablement (leading to 25% adoption among its users), and efficient domain transfers. It also provides insights into domain registration trends, noting the dominance of gTLDs and Cloudflare's commitment to expanding TLD support, particularly for ccTLDs.

1/16/2019

Introduced a one-click DNSSEC enablement feature for domains registered with Cloudflare Registrar. This feature automates the generation and submission of DS records to domain registries, leveraging CDS and CDNSKEY records, thereby simplifying DNSSEC setup for users and increasing its adoption.

12/21/2018

This post details a pilot with Facebook to test the feasibility of encrypting DNS connections between 1.1.1.1 and Facebook's authoritative name servers using TLS. It reports that the end-to-end latency impact was minimal, with overhead amortized over many queries, resulting in DNS latency on par with average UDP connections.

9/27/2018

This post introduces Cloudflare Registrar, a new product that addresses the initial step of website creation: domain registration. It highlights the opaque and often expensive practices of traditional registrars and positions Cloudflare Registrar as a transparent, cost-effective alternative, charging only the wholesale price paid to registries and including free WHOIS privacy. This expands Cloudflare's DNS-related offerings beyond just DNS resolution and management to encompass the entire domain lifecycle.

9/27/2018

This post introduces Cloudflare Registrar, a new service that extends Cloudflare's offerings into domain registration. It highlights the internal need for secure domain management due to a past registrar compromise, which led to the development of both an enterprise-level custom domain protection and the publicly available registrar. The registrar is built on principles of trust, security, and always-fair pricing, promising to charge only wholesale prices for domains and including features like two-factor authentication and DNSSEC by default. This addresses common consumer pain points with existing registrars, such as bait-and-switch pricing and upsells.

9/21/2018

This post introduces Roughtime, a new authenticated time service offered by Cloudflare. It addresses the critical problem of clock skew in client systems, which negatively impacts TLS certificate validation and overall internet security. Roughtime provides an accurate and secure time synchronization protocol that is auditable, making time servers accountable. Cloudflare's deployment of Roughtime aims to improve the validity of TLS artifacts they serve and contribute to a more robust Roughtime ecosystem.

9/18/2018

Introduced General Availability and full support for CDS and CDNSKEY records (RFC 8078) for all Cloudflare managed domains that enable DNSSEC. This allows for automated DNSSEC setup by enabling it with a single click in the Cloudflare dashboard, eliminating the need for manual DS record uploads at registrars. Also supports CDS0 for automated removal of DS records.

9/17/2018

This post, 'Welcome to Crypto Week,' significantly expands the DNS Infrastructure & Naming Conventions thread by detailing Cloudflare's proactive efforts to enhance Internet trust through cryptography. It introduces support for DNSSEC with automatic provisioning and maintenance, directly addressing the security and integrity of DNS resolution. Furthermore, it announces broader cryptographic initiatives like IPFS gateways, RPKI for BGP routing security, Onion Services for privacy, and Roughtime for secure time synchronization, all contributing to a more trustworthy Internet infrastructure.

8/21/2018

Introduced a cache purge tool for the 1.1.1.1 DNS resolver, allowing users to manually refresh stale DNS records. This tool propagates cache purges across Cloudflare's data centers within seconds and supports various DNS record types (A, AAAA, CNAME, DNSKEY, DS, MX, NAPTR, NS, PTR, SPF, SRV, SSHFP, TLSA, TXT).

8/16/2018

This post details the integration of Cloudflare's 1.1.1.1 DNS resolver with Android 9 Pie's new Private DNS mode, which supports DNS over TLS (DoT). It provides step-by-step instructions for enabling DoT on Android devices and explains the privacy benefits of encrypted DNS queries. The post also discusses the challenges and solutions related to DNS in an IPv6-only network environment, including the requirement for hostnames in Private DNS and the mechanisms like DNS64 and NAT64 for IPv4/IPv6 coexistence.

8/6/2018

This post introduces support for nine new DNS record types: DNSKEY, DS, SSHFP, TLSA, SMIMEA, CERT, PTR, NAPTR, and APL. It details their usage for enabling DNSSEC on child zones, restricting trusted TLS certificates, authenticating SSH hosts, generic certificate storage, reverse DNS lookups, and advanced protocols like SIP. The post emphasizes the critical importance of enabling DNSSEC when using certificate-related record types and provides examples of how to query and verify these records.

7/14/2018

This post details the integration of Cloudflare's 1.1.1.1 DNS Resolver with DNS-Over-TLS (DoT) support into the GL.iNet GL-AR750S router. It highlights the router's ability to encrypt DNS queries by default using DoT and an option to force all client DNS traffic to be encrypted before leaving the local network. The post includes technical details on how this is achieved, including intercepting and rewriting unencrypted DNS traffic, and provides examples of using tcpdump to verify encrypted DNS traffic.

6/5/2018

Introduced a Tor onion service for the 1.1.1.1 DNS resolver, accessible via dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion and tor.cloudflare-dns.com. This service routes DNS queries through the Tor network to enhance user anonymity, preventing the resolver from seeing client IP addresses and shielding queries from ISPs and malicious Tor exit nodes. It utilizes Alt-Svc headers for integration with Firefox Nightly and optimizes Tor's relay count for reduced latency while preserving client privacy.

6/1/2018

This post details an incident where a change to the Gatebot DDoS mitigation system, specifically its integration with the Provision API, incorrectly triggered DNS mitigations for the 1.1.1.1 resolver IP ranges. This was due to a manual exception for these special IP ranges not being accounted for during the integration, leading to a 17-minute outage of the 1.1.1.1 service. The incident underscores the importance of thorough testing of changes impacting critical infrastructure and the complexity of managing IP address metadata within automated mitigation systems.

4/10/2018

This post details the discovery and resolution of widespread reachability issues to the 1.1.1.1 DNS resolver. It outlines the methodology used (RIPE Atlas probes, traceroutes), identifies three main causes (ISP routers using 1.1.1.1 internally, blackholing, and filtering), and describes the process of contacting ISPs and CPE manufacturers to fix these issues. It also presents statistics on availability improvements and discusses unsolicited background traffic observed on the 1.0.0.0/8 and 1.1.1.0/24 IP ranges.

4/9/2018

This post details the technical steps to configure an OpenWRT router to use DNS-over-TLS (DoT) with Cloudflare's 1.1.1.1 resolver. It involves replacing the default Dnsmasq with Unbound and odhcpd, configuring Unbound to forward queries to Cloudflare's DoT endpoints (port 853), and ensuring proper integration with the router's DHCP configuration. The post demonstrates how to verify the encrypted DNS traffic using packet sniffing.

4/1/2018

This post announces the launch of 1.1.1.1, a consumer-facing DNS resolver. It details the motivation behind the service, focusing on the privacy and censorship issues inherent in traditional DNS resolvers. The post explains the technical approach of leveraging Cloudflare's global network for speed and outlines the privacy commitments, including not logging querying IP addresses and wiping logs within 24 hours. It also discusses the acquisition of memorable IP addresses 1.1.1.1 and 1.0.0.1 from APNIC and the rationale for launching on April 1st.

4/1/2018

This post introduces Cloudflare's public recursive DNS resolver, 1.1.1.1, built upon the Knot Resolver. It details the goals of speed, security, and privacy, highlighting features like DNS-over-TLS, DNS-over-HTTPS, Query Minimization (RFC7816), and aggressive negative caching (RFC8198). The post also discusses the use of Cloudflare's global Anycast network, pre-filling caches, and an innovative distributed cache strategy to achieve high performance. It mentions the collaboration with APNIC for IP addresses and the use of DNSSEC validation with a mechanism for handling misconfigurations via 'Negative Trust Anchors'.

2/6/2018

This post details the operational challenges and technical considerations involved in rolling the root DNSSEC Key Signing Key (KSK) according to RFC5011. It explains the importance of the KSK for the DNS chain of trust, the states of cryptographic keys, the differences in trust derivation for the root zone, and the specific reasons for the KSK rollover (testing RFC5011 and enabling algorithm switching). It also describes the history of the rollover process, including ICANN's postponement due to issues with RFC8145 adoption and Bind-9 implementations, and highlights operational realities versus protocol design assumptions regarding resolver state persistence and storage.

9/10/2017

This post details the integration of Cloudflare's Anycast DNS service with ISC's F-Root, highlighting performance improvements observed through RIPE Atlas probe measurements and internal metrics from a public DNS resolver. It shows a reduction in median RTT from 8.24ms to 4.24ms and a significant improvement in the 90th percentile response time. The post also notes an increase in traffic to F-Root as a result of these performance gains and mentions the use of Cloudflare's in-house DNS software written in Go for the F-root nodes.

5/25/2017

This post details Cloudflare's decision to make IPv6 always-on for free domains, removing the toggle. It also introduces a collaborative effort with OpenDNS to prototype a new DNS metatype (TYPE65535) that combines A and AAAA records into a single query, aiming to improve DNS lookup efficiency and accelerate IPv6 adoption.

5/5/2017

Introduced a new DNS analytics dashboard with detailed breakdowns of DNS traffic, response codes, top queries (including NXDOMAIN), geographic query origins, and record types. Provided API access and a Grafana plugin for custom dashboard creation.

4/12/2017

This post details an initiative to automate DNSSEC configuration by working with registrars and registries, specifically enabling DNSSEC automatically for .dk domains by proposing and implementing a new protocol for DNS operators, registries, and registrars to communicate and authorize changes.

4/11/2017

Replaced the data pipeline and the authoritative DNS server (rrDNS) to achieve a 3x speed improvement. Optimized the data model to group RRSets and use MessagePack for serialization, reducing storage space by 9x. Re-architected the authoritative filter (rrDNS v2) for better performance and scale, resulting in zero delays in the new pipeline and faster DNS query responses.

1/1/2017

This post details a specific bug in Cloudflare's RRDNS software caused by a leap second. The bug occurred in the CNAME lookup code when calculating the performance of upstream DNS resolvers. The non-monotonic nature of Go's time.Now() function, combined with the leap second, caused perceived negative time differences. These negative values were then fed into a weighted selection algorithm, causing a panic. A one-character fix was implemented to check for negative time differences and prevent them from being recorded, thus resolving the issue.

12/14/2016

This post introduces the Cloudflare Salt module, enabling users to manage their DNS records programmatically using SaltStack. This move aims to establish DNS records as part of a single source of truth for infrastructure configuration, facilitate peer-reviewed and versioned changes through Git integration, and make advanced DNS management accessible to customers. The post also signals future plans to 'saltify' other Cloudflare settings like WAF, caching, and page rules.

12/7/2016

This post details a debugging war story where transient packet loss on the internal network caused DNS lookups to fail with NXDOMAIN errors. The root cause was identified as the interaction between DNS query timeouts, the `search` option in `/etc/resolv.conf`, and a custom DNS server that dropped specific requests while returning NXDOMAIN for others. The post outlines the investigation process, including load testing, network packet analysis, and the creation of a proof-of-concept DNS server to replicate the issue. Solutions proposed include tuning `timeout` and `retries` in `resolv.conf` to better handle transient network issues.

12/5/2016

This post identifies an opportunity to improve DDoS mitigation by allowing TLD operators to configure custom TTL values for DNS glue records. Currently, hardcoded 48-hour TTLs prevent effective 'DNS auth scattering' techniques, which involve rotating authoritative nameserver IPs during attacks. The author demonstrates through testing that it takes 8-18 hours for new glue records to propagate globally, significantly hindering rapid response to L3 attacks on authoritative DNS servers. The post advocates for configurable glue TTLs to enable faster recovery and more aggressive DDoS mitigation strategies.

10/27/2016

The post details the impact of the Dyn DDoS outage on Cloudflare's DNS infrastructure, specifically focusing on how CNAME-based origin configurations were affected due to external DNS resolution failures. It introduces the concept of 'serve stale while revalidating' as a change being implemented to mitigate similar future incidents by leveraging longer DNS record caching when upstream providers are unavailable.

10/21/2016

This post describes a specific incident where an external DNS attack on Dyn affected joint Cloudflare and Dyn customers. It details the mechanism of failure (CNAME records pointing to Dyn causing DNS query failures) and the resulting error (1001). Workarounds are provided: switching to A/AAAA records or migrating to Cloudflare as the authoritative DNS provider. It also highlights the potential impact on Cloudflare's own status page and support system due to third-party hosting.

10/6/2016

Introduced two new features for Virtual DNS: Serve Stale, which allows Virtual DNS to answer queries from cache even if the customer's authoritative DNS servers are down, and DNS Rate Limiting, which allows hosting providers to configure a threshold for queries sent to their DNS servers, shielding their infrastructure from excessive load.

8/25/2016

This post details how the CPSC.gov DNS record is being exploited for DNS amplification attacks, contributing to large DDoS attacks. It explains the mechanism of DNS reflection and highlights the specific vulnerability of the CPSC.gov record due to its large response size. The post also offers recommendations for optimizing DNS records to mitigate such attacks, showcasing Cloudflare's role in analyzing and addressing security threats related to DNS infrastructure.

6/24/2016

This post details an optimization for DNSSEC negative answers (NXDOMAIN and NODATA) by reducing the number of records and signatures returned. It addresses the computational cost and potential information leakage associated with NSEC/NSEC3 records by proposing a more economical approach to proving non-existence, particularly for zones with dynamic record generation or key-value store backends.

4/13/2016

Introduced a self-service dashboard and APIs for Virtual DNS, enabling programmatic configuration of all aspects, including instance creation with origin IPs, minimum/maximum cache TTLs, and ANY query deprecation. Added Multi-User access control with 2FA enforcement. Enhanced cache control by allowing customers to set minimum and maximum cache TTLs. Enabled deprecation of the ANY query type for Virtual DNS customers.

4/13/2016

This post details Cloudflare's decision and process for deprecating the DNS ANY query type. It explains the rationale behind this decision, citing the lack of legitimate use, abundance of malicious use (particularly in DDoS amplification attacks), and the high computational cost of serving ANY queries, especially with DNSSEC. The post also discusses the community's reaction and the eventual adoption of a 'Refuse ANY' strategy, where a harmless HINFO record is returned instead of a full ANY response, to mitigate amplification attacks while maintaining compatibility.

4/5/2016

This post details a specific latency issue encountered within Cloudflare's datacenter related to DNS services. It identifies the root cause as the Linux kernel's listening hash table (LHTABLE) becoming a bottleneck when a large number of TCP sockets (16k) were bound to specific IP addresses on port 53. The post explains how this led to slow lookups in the LHTABLE, impacting ping times. It then describes the implemented solutions: changing TCP binding to 'bind to star' (0.0.0.0:53) and increasing the LHTABLE size, which resolved the latency problem and ensured consistent performance.

3/4/2016

This post details Cloudflare's technical approach to mitigating DNS amplification attacks by optimizing DNS packet sizes. It introduces the adoption of ECDSA for smaller DNSKEY sets, comparing its size and security benefits to RSA. It also explains the deprecation of the ANY query type and its role in reducing large DNS responses, thereby preventing abuse for DDoS attacks. The post highlights the use of assembler optimizations for ECDSA signing speed and the creation of an Internet Draft to standardize the deprecation of ANY queries.

2/29/2016

This post details the analysis and exploitation of CVE-2015-7547, a buffer overflow vulnerability in the GNU libc DNS stub resolver. It demonstrates multiple attack vectors, including on-path and off-path scenarios, and evaluates the effectiveness of proposed mitigations like limiting UDP response sizes. The post highlights the challenges of cache traversal attacks against resolvers like dnsmasq and dnscache, and emphasizes the critical need for patching systems to address this vulnerability.

1/13/2016

This post introduces a new application of DNSSEC by demonstrating how public SSH keys can be securely stored in DNS TXT records. It details the technical implementation using OpenSSH's AuthorizedKeysCommand feature and unbound-host for DNSSEC validation, effectively turning Cloudflare's DNS into a Public Key Infrastructure (PKI) for SSH access. This enhances security by allowing dynamic revocation of access through DNS record removal and simplifies key management across multiple hosts.

11/10/2015

This post announces the launch of Universal DNSSEC, making DNSSEC available for free to all Cloudflare customers. It details the vulnerability in DNS that DNSSEC addresses (lack of authentication leading to man-in-the-middle attacks). It explains how trust is delegated in DNSSEC and the manual process of activation involving registrars. To overcome these limitations, Cloudflare is proposing a new Internet Draft protocol for direct communication between DNS providers and registries/registrars to automate DNSSEC activation. The post highlights early successes with registries and registrars supporting ECDSA, Cloudflare's chosen cipher, and encourages broader adoption.

10/29/2015

This post details a critical bug found and fixed in the RRDNS authoritative DNS server related to the incorrect usage of Go's RWMutex, which led to a deadlock and query failures. It highlights the importance of careful concurrency management in high-throughput systems like DNS servers and suggests improvements in static and dynamic analysis tooling for detecting such issues.

10/20/2015

This post announces the opening of the DNSSEC beta program to all websites using Cloudflare for DNS. It provides a brief background on DNS vulnerabilities and introduces DNSSEC as a solution for authenticating DNS records through cryptographic hashes and signatures.

8/6/2015

This post details the application of go-fuzz to the miekg/dns library, uncovering and fixing bugs related to DNS packet parsing, pointer handling, and potential Denial of Service vulnerabilities. It also demonstrates how fuzzing can be used to compare the behavior of different parser versions and identify issues with buffer reuse in packing functions.

8/4/2015

This post details the analysis of CVE-2015-5477, a critical remotely exploitable vulnerability in BIND9 DNS servers. It explains the root cause of the crash, which is a failed assertion in `dns_message_findname` due to a dirty `name` pointer being passed in a second call after a previous call failed to find a TKEY record but still populated the `name` pointer. The post also highlights how Cloudflare's Virtual DNS customers were protected from this vulnerability due to their use of RRDNS, which sanitizes queries and does not relay EXTRA section records for TKEY queries.

8/3/2015

This post introduces a technique for improving the debuggability of Go stack traces within Cloudflare's RRDNS service. It details how converting IPv4 addresses to their uint32 representation and passing them as blank identifier parameters to goroutines allows for easier identification of listening IPs in stack traces, thereby aiding in the management of a large number of goroutines.

7/6/2015

This post details a specific incident where an outage at Dyn, a major DNS operator, caused DNS resolution errors for Cloudflare customers using CNAME records. It explains the technical mechanism of CNAME resolution and how upstream DNS provider issues can cascade. The post also highlights Cloudflare's immediate response, debugging process, and collaboration with Dyn to resolve the issue, emphasizing the cooperative nature of the internet.

7/3/2015

This post details the challenge of ensuring near-instantaneous global propagation of DNS record changes and other customer configurations across Cloudflare's vast network. It introduces a custom alert system, visualized by a blue rotating police light, that monitors DNS propagation times from external machines and alerts the office if thresholds are exceeded, ensuring rapid awareness and action for potential network issues.

4/12/2015

This post introduces a low-level optimization technique for case-insensitive string comparison using bitwise AND operations (AND 0xDF). This technique is particularly relevant for high-performance scenarios like processing millions of DNS packets per second, where efficient filtering decisions are crucial. It highlights how understanding ASCII character encoding can lead to significant performance gains in network protocols that use USASCII characters.

3/10/2015

Introduced Virtual DNS, an authoritative DNS proxy service that leverages Cloudflare's global DNS and proxying infrastructure to provide DDoS mitigation and global distribution for any organization's DNS nameservers. This service caches DNS responses at the edge, reducing load on origin nameservers, and blocks malicious traffic before it reaches the origin. It also masks the origin IP addresses of the provider's nameservers.

3/6/2015

This post announces the deprecation of the DNS ANY meta-query type. Cloudflare will begin responding to ANY queries with '4 / Not Implemented' in a few weeks. The rationale includes the lack of legitimate software use cases, security concerns related to DNS reflection attacks (amplification), and the significant complexity ANY queries add to DNS server code, especially with features like load-balancing and geoip. The post notes that only unpatched qmaild and Firefox versions 36.0-36.0.1 were known to issue ANY queries, and Firefox has since reverted this behavior. It also mentions that other operators have disabled or throttled ANY queries with minimal impact.

2/5/2015

This post identifies a critical limitation in the current ICANN domain registration model, which excludes third-party DNS operators like Cloudflare. This exclusion necessitates manual NS record updates by customers, hindering automation and the adoption of advanced features like DNSSEC. Cloudflare advocates for an automated channel for DNS operators to update NS and DS records, proposing a new model for communication between DNS operators, registrars, and registries.

2/4/2015

This post details a specific networking challenge encountered with Path MTU discovery, particularly affecting users with IPv6 tunnels. It explains the underlying mechanisms of MTU, fragmentation, and ICMP messages, and how Cloudflare's internal ECMP routing inadvertently broke Path MTU discovery by misrouting ICMP messages. The post outlines temporary fixes (reducing MTU for IPv6, enabling RFC4821 for IPv4) and introduces their open-sourced Path MTU Daemon (pmtud) as a comprehensive solution to ensure correct ICMP routing within their datacenters.

1/29/2015

This post details Cloudflare's approach to implementing and deploying DNSSEC, focusing on signing at the edge on demand. It highlights the use of ECDSA P-256 for smaller signatures and improved performance, and a specialized NSEC implementation for negative answers to minimize response size and prevent zone walking. The author, a long-time DNSSEC expert, joined Cloudflare to contribute to this effort, emphasizing a fresh perspective and questioning prior assumptions.

1/29/2015

This post marks the initial public release of Cloudflare's DNSSEC implementation by publishing a signed zone for www.cloudflare.com. It details the use of 'signing on the fly' to prevent NSEC record exposure of subdomains, the adoption of ECDSA for smaller DNS answers to mitigate reflection attacks, and the provision of a managed solution to abstract DNSSEC complexity from users. It also includes a DiG output example and a visualization of domain signatures.

11/5/2014

This post details the complexities of DNSSEC, specifically the zone content exposure problem caused by NSEC and NSEC3 records. It explains how NSEC records can be used to enumerate all subdomains in a zone, and how NSEC3, while intended to mitigate this, can still be vulnerable to dictionary attacks on hashed domain names. The post also discusses the concept of 'DNSSEC white lies' as a potential mitigation, which requires real-time signing capabilities on authoritative DNS servers, a departure from traditional offline signing methods.

10/7/2014

This post introduces DNSSEC as a set of security extensions to DNS that provides the means for authenticating DNS records. It explains the inherent insecurity of traditional DNS, highlighting on-path attacker attacks and Kaminsky's cache poisoning attack. It details how DNSSEC can be used to improve trust in DNS by providing authentication for DNS records, and announces Cloudflare's plan to introduce DNSSEC in the next six months.

7/2/2014

Introduced named constants (QR, AA, TC, Z, RCODE) for DNS header flags to improve code readability and maintainability in the DNS server's packet filtering logic. Refactored a bitwise check from magic numbers (0x86, 0x4f) to a more explicit check using these constants.

4/3/2014

Introduced CNAME Flattening, a feature that allows CNAME records at the root of a domain while adhering to DNS specifications. This is achieved by Cloudflare's authoritative DNS infrastructure recursively resolving the CNAME chain to an A record, effectively "flattening" it. This resolves edge cases like Microsoft Exchange email issues and improves DNS resolution time by approximately 30% through caching.

4/1/2014

This post details the debugging and resolution of an issue with the implementation of the DNS LOC record type within Cloudflare's RRDNS server. The problem was identified as a missing parser for the textual LOC record format, which prevented RRDNS from correctly serving these records. The author implemented a parser for the LOC text record type and associated tests, which was then rolled out to production, enabling RRDNS to serve existing LOC records.

1/30/2014

This post introduces Cloudflare's Anycast DNS service, highlighting its advantages over traditional DNS providers. Key technical contributions include: 1. Explanation of Anycast routing for reduced latency by directing queries to the nearest data center. 2. Discussion of low TTLs (5 minutes by default) for rapid DNS record updates, enabling dynamic IP changes for failover and scripting. 3. Explanation of how low TTLs aid in DDoS mitigation by allowing on-the-fly IP address changes for null-routing.

11/11/2013

This post details the development and use of RRDNS, a DNS proxy written in Go, which significantly enhances the scalability, reliability, and resilience of Cloudflare's DNS infrastructure. It introduces features like response rate limiting, caching, load balancing, and seamless binary upgrades to address DNS attacks and improve performance.

8/27/2013

This post details a specific incident of DNS hijacking affecting NYTimes.com due to a registrar compromise. It explains the roles of registries, registrars, and recursive DNS providers, and the technical steps taken by Cloudflare, OpenDNS, and Google to mitigate the attack. It also highlights the importance of registry locks as a security measure.

8/27/2013

This post details the replacement of PowerDNS with a custom-built authoritative name server called RRDNS. RRDNS was developed to address challenges with DDoS load handling, abuse detection, and rate limiting that were encountered with PowerDNS. The post highlights RRDNS's modular framework, which allows for the easy addition of application logic, exemplified by the implementation of DNS 'Easter Eggs' that query job listings and 'whois' information. It also describes the security safeguards implemented to prevent these features from being used in DNS reflection attacks, specifically by forcing TCP retries for certain queries.

8/6/2013

Introduced a new naming convention for Cloudflare's name servers, using a list of 100 common 2- to 4-letter names (50 male, 50 female) to create unique combinations (e.g., bob.ns.cloudflare.com, lola.ns.cloudflare.com). This was a technical solution to prevent users from attempting to game the signup process by adding multiple name servers, ensuring a clear authoritative source for DNS records during concurrent signups. An additional name, 'Woz', was later added to accommodate a specific request. The names lose technical importance after verification, with all servers in the infrastructure configured to respond to any request, enabling load balancing.

1/7/2013

This post details Cloudflare's early efforts in optimizing DNS speed, achieving a 4.51ms average response time and ranking second in SolveDNS's monthly survey. It announces an upcoming major DNS release, RRDNS, aimed at further improving lookup speeds.

8/1/2012

This post details the performance and architecture of Cloudflare's authoritative DNS network, highlighting its use of Anycast for speed and resilience, and the development of an easy-to-use control panel. It also introduces custom DNS servers for business plans and partnerships with hosting providers.

5/19/2012

This post highlights how Cloudflare's DNS service, by maintaining stable public IP addresses, eliminates the need for users to wait for DNS propagation when changing their origin servers or IP addresses. This provides an 'instantaneous' update for users, removing a common pain point in website development and deployment.

5/3/2012

Introduced a Javascript-based 'Visitor DNSChanger Detector App' that can be enabled by Cloudflare customers to inform visitors if they are infected with DNSChanger malware. Released the code as open source to allow broader adoption. Collaborated with OpenDNS to provide a resource for infected users.

4/11/2012

This post details the UI changes to the Cloudflare DNS editor, making it easier for users to manage DNS records. It covers how to access DNS settings, toggle Cloudflare proxying for records (orange vs. gray cloud), edit existing records (e.g., change server IP), and add new records. It also addresses common troubleshooting scenarios for subdomains and mail delivery by explaining how to correctly configure A, CNAME, and MX records, with specific examples for Google Apps.

2/24/2012

This post details a critical incident involving the deletion of the primary DNS database and the subsequent rapid propagation of a new, faster DNS update system, leading to widespread outages. It describes the 'ugly' of the database deletion, the 'bad' of cache propagation and issues in two data centers, and the 'good' of the team's response and the benefits of the new instant DNS update system. Safeguards were added to prevent recurrence.

11/8/2011

Introduced KTFS, a new scalable, key-value based file system designed for rapid deployment of changes across the global network. This system was initially built for SSL certificate provisioning and was subsequently leveraged to significantly reduce DNS update propagation time from approximately five minutes to under a minute.

10/18/2011

This post introduces Cloudflare's authoritative DNS system, emphasizing its use of Anycast for global distribution and redundancy. It explains the difference between recursive and authoritative DNS and highlights that Cloudflare's authoritative DNS service is included free with every account.

8/20/2011

Developed a bookmarklet to liberate EveryDNS user data, enabling users to export their DNS records in BIND format, thereby circumventing EveryDNS's data export fees and demonstrating Cloudflare's commitment to data portability.

5/16/2011

Introduced support for CNAME Flattening, allowing zone apex records to be CNAMEs. This resolves an RFC limitation that prevented direct CNAME pointing of root domains to cloud hosts like EC2, Rackspace, and Google App Engine, which often reallocate IP addresses. This feature enables users to use their naked domain without workarounds.

9/2/2010

Introduced the concept of 'Ninja Nameservers' to represent Cloudflare's globally distributed DNS infrastructure, emphasizing the use of anycast and load balancing for deployment. This post focuses on the branding and conceptualization of the nameservers rather than deep technical implementation details.