TechPrufer
Get started
Cloudflare
Cloudflare logoCloudflare · Feature trail

DNS Infrastructure & Naming Conventions

152 posts · May 2011 – Oct 2026

What this trail covers

Cloudflare's DNS infrastructure has evolved to include Internal DNS, providing a unified platform for managing both public and private DNS resources. This integrates authoritative and recursive DNS for private networks onto Cloudflare's global network and control plane, simplifying split-horizon DNS, extending Zero Trust policies to DNS, and modernizing legacy infrastructure by retiring hardware appliances and cloud-locked resolvers. The system comprises a Gateway Resolver for recursive resoluti

All Cloudflare trails
  1. The keys to the Internet change on October 11, 2026. Are you ready?This post details the upcoming DNS root KSK rollover on October 11, 2026. It explains the importance of DNSSEC, the role of the Key-Signing Key (KSK), and the process of trust anchor updates for resolvers. Cloudflare has proactively updated its resolvers (1.1.1.1 and Gateway DNS) to trust the new KSK-2024 by embedding it directly into software trust anchors. The post introduces RFC 8509, the root key trust anchor sentinel, and provides a readiness test website and dig commands to verify resolver trust in KSK-2024. It also discusses the continued use of RSA/SHA-256 for the KSK and the reasons for the delay in algorithm changes.
  2. 1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of itIntroduces the validation of ML-DSA-44 post-quantum DNSSEC signatures by 1.1.1.1. Details the challenges of large signature sizes (2,420 bytes) exceeding DNS UDP limits and the risk of downgrade attacks when supporting both conventional and post-quantum algorithms. Explains the mechanism used by 1.1.1.1 to prevent downgrades by requiring at least one valid post-quantum path and the importance of ecosystem-wide adoption for a complete post-quantum chain of trust.
  3. How we saved 100 terabytes of memory by optimizing 1.1.1.1’s DNS cacheIntroduced five successive changes to the Big Pineapple platform's DNS cache storage in memory, reducing the per-entry footprint by over 50%. These changes included: 1. Replacing `Vec<T>` and `String` with `Box<[T]>` and `Box<str>` to eliminate capacity fields and reserved heap space. 2. Storing offsets for answer, authority, and additional record sections in a single list instead of separate lists with pointers and lengths. 3. Dropping the owner field for DNS records when it is identical to the queried domain, inferring it at read time. 4. Boxing larger variants of the `RecordData` enum to reduce memory waste on smaller, more common record types. 5. Implementing bitflags for boolean fields to reduce padding. These optimizations freed up ~100TB of memory, increased insert throughput by 43%, and decreased lookup latency by 19%.
  4. BGP ORIGIN attribute manipulation and its impact on the InternetThis post details an investigation into the manipulation of the BGP ORIGIN attribute. It quantifies the extent of this manipulation (approximately 70% of observed paths) and identifies specific Autonomous Systems (ASes) that rewrite the ORIGIN attribute, primarily to 'IGP', to influence traffic forwarding and revenue. The analysis covers both IPv4 and IPv6, noting differences in manipulation behavior between the two address families. It also discusses the historical context and operational impact of this practice, including the creation of an Internet-Draft recommending its deprecation. The methodology involves announcing prefixes with different ORIGIN values from Cloudflare's peering locations and analyzing BGP Update messages from RIPE RIS and RouteViews collectors, as well as local BMP data.
  5. Cloudflare Internal DNS is now generally availableThis post announces the general availability of Cloudflare Internal DNS, a new capability that extends Cloudflare's existing DNS infrastructure to manage private networks. It introduces the Gateway Resolver and Internal Authoritative DNS components, along with key objects like Internal Zones, DNS Views, and Resolver Policies. The post details how queries resolve and changes propagate, and provides API examples for setting up internal zones, records, and views. It also highlights integration with Cloudflare Gateway and other Connectivity Cloud services.
  7. A broken DNSSEC rollover took down .AL. Now 1.1.1.1 tells you when validation is bypassedThis post details the incident where the .al TLD experienced a DNSSEC key rollover failure, leading to validation errors and service unavailability. Cloudflare's 1.1.1.1 resolver applied a Negative Trust Anchor (NTA) to restore resolution, a measure previously used for the .de TLD. For the first time, 1.1.1.1 implemented and signaled the use of an NTA via Extended DNS Error (EDE) code 33, as defined in a new Internet-Draft. This EDE code, along with EDE 9 (DNSKEY Missing), provided clients with explicit information that DNSSEC validation was bypassed due to the NTA, closing a transparency gap in RFC 7646. The post also discusses the technical breakdown of the .al DNSSEC failure, including the DS record mismatch and the subsequent removal of the DNSKEY and DS records.
  8. Iran's Internet is partially restored, Cloudflare Radar data showsThis post analyzes Cloudflare Radar data to show the partial restoration of internet connectivity in Iran following a prolonged national shutdown. It details the observed increases in traffic and DNS queries, regional and network-specific traffic volume, and the persistent impact on IPv6 connectivity compared to IPv4. The analysis suggests that the shutdown was likely achieved through means other than IP address space removal, such as application filtering or whitelisting.
  9. When DNSSEC goes wrong: how we responded to the .de TLD outageThis post details Cloudflare's response to a DNSSEC signing outage for the .de TLD. It explains how the incident impacted 1.1.1.1 and the CDN platform, highlighting the role of 'serve stale' (RFC 8767) in mitigating user impact. The post describes the deployment of a Negative Trust Anchor (NTA) equivalent override rule for .de on 1.1.1.1 to bypass DNSSEC validation and restore service. It also details applying a similar mitigation to the internal origin resolution resolver and identifies a bug in the propagation of DNSSEC EDE codes, specifically EDE 6 (DNSSEC Bogus), which was incorrectly reported as EDE 22 (No Reachable Authority).
  10. Register domains wherever you build: Cloudflare Registrar API now in betaThis 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.
  11. What came first- the CNAME or the A recordThis post details a DNS resolution incident caused by a change in the order of CNAME records within 1.1.1.1's responses. The change, intended to reduce memory usage, broke DNS clients that expected CNAMEs to appear before A/AAAA records, such as glibc's getaddrinfo and Cisco's DNSC process. The post explains the RFC 1034 ambiguity regarding the ordering of RRs in message sections versus RRsets, and how this led to the incident. It also discusses the importance of robust parsing logic in DNS clients to handle variations in response ordering.
  12. DIY BYOIP- a new way to Bring Your Own IP prefixes to CloudflareThis post introduces a self-serve BYOIP API that automates the onboarding of customer IP prefixes to Cloudflare. The process leverages RPKI ROAs for intent verification and IRR/rDNS record modification for ownership verification, replacing the manual LOA process. This significantly reduces onboarding time from weeks to minutes and enhances security by relying on cryptographic validation rather than manual document review. The initial scope is limited to prefixes originated from Cloudflare's ASN (AS13335) due to ROA availability.
  13. Fresh insights from old data: corroborating reports of Turkmenistan IP unblocking and firewall testingThis post details how Cloudflare Radar's analysis of TCP connection resets and timeouts can be used to corroborate external reports of network events, such as IP unblocking and firewall testing in Turkmenistan. It demonstrates how surges in HTTP requests and shifts in TCP connection anomaly patterns (e.g., Post-PSH, Post-ACK, Later connection stages) correlate with reported network changes. The analysis also highlights the importance of examining individual autonomous systems (AS) within a country to reveal more pronounced trends and the need to consider request volume alongside anomaly data for a comprehensive understanding.
  14. BGP zombies and excessive path huntingThis 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.
  15. From .com to .anything- introducing Top-Level Domain (TLD) insights on Cloudflare RadarThis post introduces a new TLD page on Cloudflare Radar, which provides insights into TLD popularity, activity, and security. It details the implementation of DNS Magnitude as a metric for ranking TLDs based on unique network queries, and explains the different TLD types (gTLD, grTLD, ccTLD, iTLD, sTLD). It also describes the information available on individual TLD pages, including DNSSEC and RDAP support, WHOIS data, and registration options via Cloudflare Registrar. The post highlights the inclusion of non-delegated TLDs in the DNS Magnitude ranking and the sourcing of delegated TLD data from IANA's Root Zone Database.
  16. Making the Internet observable- the evolution of Cloudflare RadarThis post details the evolution of Cloudflare Radar, highlighting new features and data sets that enhance Internet observability. Key contributions include the integration of Certificate Transparency (CT) data, visibility into TCP resets and timeouts to detect connection tampering, tracking of post-quantum encryption adoption, and detailed AI Insights for measuring AI bot and crawler activity. The post also emphasizes Radar's role in improving Internet resilience through routing visibility, including data on route leaks and origin hijacks.
  17. Introducing new regional Internet traffic and Certificate Transparency insights on Cloudflare RadarCloudflare Radar has launched regional traffic insights, allowing users to view traffic trends at a more local level, including bytes, requests, desktop/mobile device shares, and bot/human traffic shares. This is achieved by matching IP addresses to GeoNames IDs and their associated first-order administrative divisions. The platform now includes a 'Traffic characteristics by region' card on country-level pages, time series graphs for regional traffic, and enhanced Data Explorer capabilities for customizing regional analysis with ASN breakdowns.
  18. Cloudflare 1.1.1.1 Incident on July 14, 2025This post details a 62-minute outage of the 1.1.1.1 DNS Resolver service caused by a misconfiguration in service topology management. A configuration error on June 6 inadvertently linked the 1.1.1.1 Resolver service prefixes to a pre-production DLS service. A subsequent change on July 14 to this DLS service triggered a global refresh of network configuration, causing the 1.1.1.1 Resolver prefixes to be withdrawn from production data centers. The incident highlights the risks of legacy configuration systems and the importance of staged deployments and comprehensive health monitoring.
  19. Some TXT about, and A PTR to, new DNS insights on Cloudflare RadarIntroduced a new dedicated DNS page on Cloudflare Radar, expanding analysis of 1.1.1.1 resolver traffic to include detailed metrics on DNS transport protocols (UDP, TCP, DoT, DoH), query and response characteristics, DNSSEC usage, and geographical distribution. The page leverages anonymized DNS query logs to provide insights into traffic trends and can be used to corroborate reported Internet outages or shutdowns.
  20. QUIC action: patching a broadcast address amplification vulnerabilityThis 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.
  21. The fall and rise of TikTok (traffic)This post details the observed DNS traffic patterns for TikTok and its alternatives in the US and globally during the US ban and subsequent restoration. It quantifies the drop in TikTok DNS traffic by up to 85% and the surge in traffic for alternatives like RedNote by up to 291% in the US, and significant increases in other countries. It also notes the partial recovery of TikTok traffic and the sustained growth of alternatives. The analysis leverages data from Cloudflare's 1.1.1.1 DNS resolver and autonomous system-level data.
  22. How we prevent conflicts in authoritative DNS configuration using formal verificationThis post details the technical implementation of formal verification within Cloudflare's Topaz system for authoritative DNS configuration. It explains the structure of Topaz programs (config, match, response functions), the domain-specific language (topaz-lang) based on Scheme, and how these programs are executed sequentially to determine IP addresses for proxied domains. The post provides concrete examples of Topaz programs, including one for a specific tag ('orange') and a more complex one involving datacenter selection, traffic percentage, and IP prefix distribution. It highlights the use of functions like `fetch_datacenters`, `rand_gen`, `hash`, `member?`, `random_number`, `range`, `select_from`, and `ttl` within the DSL. The core contribution is the application of formal methods to ensure correctness and prevent conflicts in a critical network system.
  23. Migrating billions of records: moving our active DNS database while it’s in useThis post details the migration of Cloudflare's active DNS database, containing billions of records, from the main cfdb cluster to a new dnsdb cluster. The migration was driven by storage strain on cfdb and the need for better control over DNS data access. Key technical challenges and solutions included: decoupling zone data from DNS record data, creating a gRPC API for DNS records to centralize access and enable rate limiting/caching, migrating over 20 services to use this API, and moving auditing and zone setting logic to the application level. A Change Data Capture and Transfer Service (CDCTS) was built to handle the initial data copy and near real-time change replication, prioritizing data integrity and minimal downtime. The CDCTS design considered bidirectional migration capabilities, partitioning of the _cf_rec table by zone_id, and the use of foreign tables for emergency access. The _cf_rec table contained 1.7 billion records and 1.5 TB of data, with millions of daily inserts, updates, and deletes. The _cf_archived_rec table contained 4.3 billion records. The migration process involved an initial copy and a continuous change copy mechanism.
  24. Making zone management more efficient with batch DNS record updatesIntroduced a new /dns_records/batch API endpoint that allows for multiple DNS record operations (POST, PUT, PATCH, DELETE) in a single API call, executed within a database transaction. Optimized database queries by removing redundant existence checks and leveraging PostgreSQL's auto_explain for latency analysis. Implemented a specific execution order for operations (deletes, patches, puts, posts) to handle conflicts. Added UI support in the dashboard for batch deletion and proxy status changes of selected DNS records.
  25. Cloudflare incident on September 17, 2024This 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.
  26. Cloudflare 1.1.1.1 incident on June 27, 2024This 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.
  27. Exam-ining recent Internet shutdowns in Syria, Iraq, and AlgeriaThis 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.
  28. Improving authoritative DNS with the official release of Foundation DNSThis post announces the official release of Foundation DNS, an enhanced authoritative DNS offering for enterprise customers. Key technical contributions include the introduction of advanced nameservers that leverage multiple TLDs and a single Anycast group per TLD to provide three IP addresses that resolve to the same physical location, improving resilience. It also details new zone-level DNS settings, unique DNSSEC keys per account and zone, GraphQL-based DNS analytics, and a new release process for enhanced stability.
  29. From .com to .beauty: The evolving threat landscape of unwanted emailThis post analyzes the prevalence of spam and malicious emails associated with various Top-Level Domains (TLDs) throughout 2023. It reveals that recently introduced generic TLDs (gTLDs), particularly those related to the beauty industry, have a high percentage of unwanted emails. The analysis also highlights that while .com accounts for the largest volume of spam and malicious emails, newer gTLDs are emerging as significant sources of these threats. The post details trends in TLD usage for malicious purposes, including changes observed in the latter half of 2023, and provides a list of the top 50 spam and malicious TLDs. This data is now integrated into Cloudflare Radar's email security insights.
  30. Free network flow monitoring for all enterprise customersIntroduces a free version of Magic Network Monitoring for all Enterprise Customers, enabling them to send NetFlow or sFlow data to Cloudflare for analysis. Details its application in monitoring core data center traffic during security incidents, IoT device traffic, and cloud network traffic. Outlines the self-serve onboarding process and the future integration with native cloud VPC flow logs.
  31. Remediating new DNSSEC resource exhaustion vulnerabilitiesThis post details the implementation of specific resource exhaustion mitigations for DNSSEC vulnerabilities Keytrap and NSEC3 iteration count. For Keytrap, Cloudflare implemented limits on the number of keys accepted at a zone cut, and added signature validation limits per RRSET and per resolution task. For NSEC3, a limit on total hash calculations per resolution task was added. Both mitigations involve failing resolution for queries exceeding these limits and returning an Extended DNS Error (EDE) code. Metrics were also added to detect exploitation attempts.
  32. Using DNS to estimate the worldwide state of IPv6 adoptionThis 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.
  33. Latest copyright decision in Germany rejects blocking through global DNS resolversThis post details a German court's decision rejecting a request to compel Cloudflare's public DNS resolver (1.1.1.1) to block websites based on copyright infringement allegations. It explains the role of DNS resolvers, the ineffectiveness and lack of transparency of DNS-based blocking, and the distinction between public and ISP-provided resolvers. The decision highlights that public DNS resolvers are protected under the EU's Digital Services Act (DSA) as 'mere conduit' services, reinforcing Cloudflare's long-held position against using public resolvers for content moderation.
  34. 1.1.1.1 lookup failures on October 4, 2023This post details an incident where a new ZONEMD record in the root zone caused parsing failures in Cloudflare's static_zone WebAssembly app, preventing updates to the root zone. This led to the use of a stale root zone with expired DNSSEC signatures, resulting in SERVFAIL responses for some 1.1.1.1 users. The incident was resolved by disabling the static_zone app and implementing a new override rule. The post also explains the binary DNS format, the role of RDLENGTH, and the challenges of handling unknown resource record types.
  35. Typo traps: analyzing traffic to exmaple.com (or is it example.com?)This post analyzes traffic patterns to exmaple.com, a domain used to capture typosquatting and misconfiguration-related traffic. It details the volume, type (bot-dominated, mostly unencrypted HTTP), origin (specific ASNs like Bouygues Telecom, Google Cloud, Worldstream), and IP version (increasing IPv6 usage) of this traffic. The analysis reveals that much of this traffic is likely due to misconfigurations in routers or network settings intended for example.com, and highlights the financial cost of handling such unintentional traffic. It also touches upon the use of example.com for testing and educational purposes in network configurations.
  36. Quickly see differences between Zone Versions with Version ComparisonsIntroduced '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.
  37. The day my ping took countermeasuresThis post details how the `ping` utility handles clock adjustments by examining its source code and debugging techniques. It explains the 'taking countermeasures' message, the use of `gettimeofday` and `SO_TIMESTAMP` for RTT measurement, and the challenges of debugging VDSO calls. The author demonstrates fault injection using `strace` to trigger the countermeasure message and discusses the implications of `ping` sockets and capabilities.
  38. Connection errors in Asia Pacific region on July 9, 2023This 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 for Cloudflare customers. The issue impacted customers using CNAME records for origin DNS resolution. Cloudflare mitigated the impact by rerouting DNS traffic to Verisign's US west coast nameservers. The post explains the technical details of DNSSEC validation, the incident timeline, and the root cause of expired signatures.
  39. The quantum state of a TCP portThis 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.
  40. How Rust and Wasm power Cloudflare's 1.1.1.1This 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.
  41. One of our most requested features is here: DNS record comments and tagsIntroduced DNS record comments and tags, allowing users to add metadata to DNS records for better organization and filtering. Comments are available to all plans, while tags are available to Pro, Business, and Enterprise plans. Enhanced the dashboard UI with filtering capabilities for these new attributes and updated the import/export zone file functionality to include comments and tags. Increased the width of the DNS record table.
  42. The unintended consequences of blocking IP addressesThis post details the unintended consequences of IP address blocking, explaining how court-ordered blocks on specific IP addresses can render thousands of unrelated websites inaccessible. It highlights the technical realities of IP blocking, including the limitations of DNS as a control point and the fact that identity is attached to names, not addresses. The post argues that brute-force IP blocking is opaque, has unavoidable collateral effects, and is technically infeasible to manage effectively, advocating for addressing content challenges at the source or through more precise legal and technical mechanisms.
  43. Cloudflare is joining the AS112 project to help the Internet deal with misdirected DNS queriesCloudflare is joining the AS112 project to operate DNS servers that handle misdirected reverse DNS lookup queries for private-use IP addresses. This initiative aims to improve the stability, reliability, and performance of the AS112 service by leveraging Cloudflare's global network. The post details the problem of these misdirected queries, the history and operation of the AS112 project, including direct delegation and DNAME redirection methods, and the technical implementation of reverse DNS lookups.
  44. How we detect route leaks and our new Cloudflare Radar route leak serviceIntroduced 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.
  45. Goodbye, Alexa. Hello, Cloudflare Radar Domain RankingsThis post details the technical approach behind Cloudflare Radar's new Domain Rankings feature. It explains the nuances of domain name structures and the Public Suffix List, defines 'popularity' as user population size rather than traffic volume, and outlines the use of aggregated 1.1.1.1 resolver data. The post describes the development of two machine learning models: one for the top 100 domains using more features, and another for the top one million domains divided into unordered buckets. It also addresses privacy considerations and potential biases in the data.
  46. Protests spur Internet disruptions in IranThis post details how Cloudflare Radar data was used to analyze internet disruptions in Iran, specifically focusing on the impact of government-directed shutdowns and DNS blocking. It presents graphs showing traffic drops on major Iranian ISPs (TCI, Iran Mobile Communications Company, RighTel, MTN Irancell) and DNS resolution requests to Cloudflare's resolver (1.1.1.1) for social media platforms (instagram.com, whatsapp.com) and DNS-over-HTTPS/TLS endpoints (cloudflare-dns.com). The analysis highlights the correlation between reported disruptions and observed traffic patterns, demonstrating Cloudflare's capability to monitor and report on large-scale internet censorship.
  47. Crawler Hints supports Microsoft’s IndexNow in helping users find new contentThis post details the integration of Cloudflare's Crawler Hints with Microsoft's IndexNow protocol. Crawler Hints sends signals to web indexers based on cache data and origin status codes to indicate content changes. IndexNow allows search engines to receive these signals and shift from a 'pull' model to a 'push' model for crawling. The post highlights the benefits of this approach, including reduced wasted crawl traffic, bandwidth, and compute. It also explains how to enable Crawler Hints and announces plans to default it on for all customers. Future work will involve incorporating additional signals like etags and last-modified headers.
  48. Internet disruptions overview for Q2 2022This post details observed internet disruptions in Q2 2022, including those caused by fiber optic cable damage (Comcast, South Africa, Venezuela, AAE-1 & SMW-5, Castor canadensis) and government-directed shutdowns (Syria, Sudan, Algeria), analyzing traffic patterns and their impact on various metrics like mobile vs. desktop client mix and IPv4 vs. IPv6 traffic share.
  49. Exam time means Internet disruptions in Syria, Sudan and AlgeriaThis post details internet disruptions in Syria, Sudan, and Algeria during exam periods, observing nationwide shutdowns and targeted blocking. It analyzes traffic patterns via Cloudflare Radar and NEL reports, highlighting the impact of these government-imposed restrictions on internet connectivity and the shift from full shutdowns to content blocking in Algeria.
  50. Dig through SERVFAILs with EDEThis post announces the expansion of Extended DNS Error (EDE) code support for DNS queries to 1.1.1.1. It details the benefits of EDE codes for debugging SERVFAIL responses, provides examples of dig commands with and without EDE support, and lists additional error codes now supported, including 'Unsupported DNSKEY Algorithm', 'No Reachable Authority', and 'Network Error'. It also directs users to developer documentation for a comprehensive list of supported codes.
  51. How we improved DNS record build speed by more than 4,000xIntroduced a per-record build type for the DNS Zone Builder, complementing the existing full build type. This involved creating a new Kafka event pipeline for record changes, separating the Zone Builder into distinct scheduler types (full and per-record), implementing a new Quicksilver interface for the per-record scheduler, and ensuring locking between schedulers to prevent stale data overwrites. Addressed a bug where record name changes led to stale records in Quicksilver by treating updates as separate create and delete events. This resulted in a 150x average improvement in build times and a 4250x improvement for large zones.
  52. Wildcard proxy for everyoneThis post announces the general availability of wildcard DNS record proxying for all Cloudflare plan levels, previously an Enterprise-only feature. It details the functionality of wildcard DNS records, including their behavior with deeper levels and specific record overrides, referencing RFC4592. The post explains how proxying wildcard records enables Cloudflare's features (Caching, Firewall, Workers) to be applied to all subdomains and highlights the automatic TLS certificate issuance for wildcard subdomains.
  53. What Cloudflare is doing to keep the Open Internet flowing into Russia and keep attacks from getting outThis 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.
  54. DNSSEC issues take Fiji domains offlineThis post details an incident where DNSSEC misconfiguration at the .fj ccTLD level caused widespread domain outages. It explains how Cloudflare's 1.1.1.1 resolver data and traffic metrics indicated a DNS-related issue, not a general connectivity problem. The root cause was identified as a missing DNSKEY record for the .fj zone, indicated by EDE: 9. The post explains the relationship between DS and DNSKEY records and how the misconfiguration likely occurred during a scheduled rollover without updating the root zone. The resolution involved updating the DS record in the root zone.
  55. Announcing experimental DDR in 1.1.1.1This post introduces experimental support for Discovery of Designated Resolvers (DDR) on Cloudflare's 1.1.1.1 resolver. DDR enables clients to discover and automatically upgrade to encrypted DNS transports (DoT/DoH) by leveraging certificate-based authentication and SVCB records. This mechanism verifies that the designated encrypted resolver is authoritative for the original resolver's IP address, providing a secure upgrade path against active network attackers.
  56. Announcing Foundation DNS — Cloudflare’s new premium DNS offeringThis post introduces Foundation DNS, a new premium DNS offering. It simplifies enterprise DNS pricing to a single input: total DNS queries per month, with unmetered DDoS mitigation. It highlights the importance of DNS and Cloudflare's authoritative DNS offering, emphasizing its global anycast network, DDoS mitigation experience, and commitment to DNSSEC. The post details how Foundation DNS nameservers (foundationdns.com and foundationdns.net) will offer enhanced resilience through diverse IP subnet allocation, making them more robust against route leaks than default nameservers. Additionally, it announces two new features for Foundation DNS and enterprise customers: support for outgoing zone transfers for Secondary DNS and Logpush for authoritative and secondary DNS queries.
  57. Sudan: seven days without Internet access (and counting)This post details the impact of a national internet shutdown in Sudan on global network traffic, as observed through Cloudflare Radar. It highlights the near-complete internet outage and the minimal traffic fluctuations. The post also provides historical context on internet shutdowns in Sudan and references Cloudflare Radar as a tool for monitoring global internet traffic.
  58. Sudan woke up without InternetThis post details the impact of a national internet shutdown in Sudan on October 25, 2021, using Cloudflare Radar data. It shows a drastic drop in Internet traffic, affecting all major ISPs, mobile, and desktop usage. The post also notes a change in Layer 3&4 DDoS attack patterns due to the lack of data. It references a previous post about internet shutdowns for exam cheating in Sudan, highlighting the evolving reasons for such disruptions.
  59. Unbuckling the narrow waist of IP: Addressing Agility for Names and Web ServicesThis post introduces the concept of 'Addressing Agility' to decouple IP addresses from names and policies. It explains how traditional DNS binds IP addresses to names, creating a bottleneck for innovation. The proposed solution inverts this relationship, allowing IP addresses to be computed and assigned at runtime based on policies, rather than being statically bound to names. This enables any-to-any mapping between names and addresses, and allows for dynamic changes without regard to previous bindings. The work is presented as a continuation of previous efforts in breaking IP-to-interface bindings and virtual hosting.
  60. Cloudflare and the IETFThis 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.
  61. What happened on the Internet during the Facebook outageThis post details the impact of the Facebook outage on Cloudflare's 1.1.1.1 DNS resolver, observing a 60x spike in SERVFAIL responses for Facebook/WhatsApp queries and an overall increase in A/AAAA query rates. It highlights the resilience of 1.1.1.1, which maintained its performance metrics. The post also analyzes traffic shifts to other platforms (social media, messaging, gaming, news) and presents data from Network Error Logging (NEL) and WARP traffic to Facebook's ASN, showing a significant drop during the outage. Additionally, it notes a decrease in traffic from Facebook's crawlers and user agents to Cloudflare's CDN.
  62. Understanding how Facebook disappeared from the InternetThis 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.
  63. Registrar for EveryoneThis 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.
  64. Tackling Email Spoofing and PhishingIntroduced the Email Security DNS Wizard, a new tool to help users configure SPF, DKIM, and DMARC DNS records. The wizard guides users through the process of creating these records to prevent email spoofing and phishing, and it also warns about and recommends fixes for insecure DNS configurations.
  65. Welcome to Speed Week and a Waitless InternetThis post details the factors contributing to fast DNS resolution, including the role of caching and network proximity. It highlights Cloudflare's 1.1.1.1 DNS resolver and its global network of 250 cities as key to reducing latency. It also touches upon the importance of fast authoritative DNS services and the need for secure DNS (DoH/DoT) built on TLS.
  66. Helping Keep Governments Safe and SecureThis post details the delivery of a protective DNS resolver solution to the Department of Homeland Security (DHS) in partnership with Accenture Federal Services (AFS). The solution consists of Cloudflare's protective DNS resolver, which filters DNS queries from US government offices and streams events to Accenture's analysis platform. This aims to defend against cybersecurity attacks by blocking connections to malicious hostnames. The solution builds on Cloudflare Gateway and leverages Cloudflare's network visibility into threats, analyzing billions of DNS queries and enriching data with Accenture's Cyber Threat Intelligence (ACTI) feed, further analyzed by AI and machine learning.
  67. Upgrading the Cloudflare China Network: better performance and security through product innovation and partnershipThis post details the expansion of Cloudflare's DNS services within Mainland China through a partnership with JD Cloud. Key technical contributions include: enabling local DNS queries from JD Cloud PoPs to reduce latency and improve reliability for users in China; assigning two nameservers from different TLDs (cf-ns.com, cf-ns.net, cf-ns.tech) to achieve "glueless delegations" and avoid the need for glue records; dynamically assigning nameservers to the nearest PoP for performance and load balancing; and improving DDoS mitigation by pushing L7 attack detection and mitigation to the edge and augmenting L3/L4 mitigation with remote signaling to Chinese ISPs. Performance improvements include at least a 30% reduction in latency and TTFB for static and dynamic content.
  68. The benefits of serving stale DNS entries when using ConsulThis post details the implementation and benefits of serving stale DNS entries from cache using Unbound, improving resilience and reducing latency for Consul service discovery. The configuration of Unbound with `serve-expired: yes`, `serve-expired-ttl: 3600`, and `serve-expired-client-timeout: 500` addresses issues with low TTLs and network blips, ensuring faster recovery times and a more robust service discovery experience. It also addresses previous concerns about Unbound serving indefinite stale records or incomplete information, confirming that current versions and configurations mitigate these issues.
  69. Conntrack turns a blind eye to dropped SYNsThis 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.
  70. A Name Resolver for the Distributed WebIntroduced 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.
  71. Improving Cloudflare’s products and services, one feature request at a timeThis post details the development and implementation of a new feature called 'Secondary DNS Override'. This feature allows Cloudflare to act as a Secondary DNS provider and, in specific cases, respond to DNS queries with Cloudflare's own IP space, thereby enabling HTTP proxy services (Layer 7 DDoS mitigation, WAF, CDN). This was developed in response to customer feedback from a large financial institution (Customer A) and another organization (Customer B) who wanted to leverage Cloudflare's proxy services while using Cloudflare as a Secondary DNS provider. The feature was initially released via API in November 2019, with UI parity following in the subsequent quarter.
  72. Improving DNS Privacy with Oblivious DoH in 1.1.1.1This post introduces Oblivious DNS over HTTPS (ODoH) as a new protocol to enhance DNS privacy. It details the ODoH message flow, involving three players: client, proxy, and target (resolver). ODoH uses HPKE for end-to-end encryption between the client and target, and TLS for communication between the client and proxy, and proxy and target. It leverages DNSSEC-validated public keys to authenticate the target. Initial performance measurements indicate a less than 1ms overhead at the 99th percentile compared to proxied DoH.
  73. Improving the Resiliency of Our Infrastructure DNS ZoneThis post details the implementation of a multi-primary DNS zone strategy for Cloudflare's infrastructure zone. This involves adding a third-party DNS provider as a second primary authority, managed using OctoDNS for synchronized record updates. The setup leverages DNSDist for weighted, health-checked routing of internal DNS queries, prioritizing Cloudflare's edge DNS and failing over to the third-party provider during outages. The post also describes the automation of DNS record provisioning using OctoDNS integrated with TeamCity for CI/CD, including a review step for changes.
  74. SAD DNS ExplainedThis post details the SAD DNS attack, which exploits OS networking stack features (like Linux's) to enable DNS cache poisoning by reviving classic attacks. It explains how the attack leverages UDP fragmentation and ICMP error messages to defeat source port randomization. Cloudflare has mitigated this by implementing source port randomization, careful checking of security ranking of cached data, and by eliminating support for fragmented DNS packets, aligning with DNS Flag Day 2020.
  75. Unwrap the SERVFAILThis post introduces Extended DNS Errors (EDE) as a new option within EDNS to provide more detailed information about DNS resolution failures, specifically for SERVFAIL responses. This allows clients to understand the root cause of failures (e.g., DNSSEC Bogus, Network Error) without altering the existing RCODE, maintaining backward compatibility. The 1.1.1.1 service has initial support for the draft version of EDE, and the post demonstrates its usage with `dig`.
  76. DNS Flag Day 2020This post details Cloudflare's compliance with DNS Flag Day 2020, which focuses on reducing IP fragmentation of DNS packets. Cloudflare already enforces reasonable DNS message size limits over UDP and ensures availability over TCP, making its services compliant without further action. The post explains the problem of UDP fragmentation, the importance of EDNS0 and DNSSEC, and the role of TCP for larger DNS messages.
  77. NTS is now an RFCThis 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.
  78. Speeding up HTTPS and HTTP/3 negotiation with... DNSThis 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.
  79. Secondary DNS - Deep DiveThis post details the migration of Cloudflare's Secondary DNS service from Mesos Marathon to Kubernetes. It outlines the challenges of creating a distributed and reliable system in Kubernetes while protecting individual data centers from DDoS attacks. The solution involved proxying egress traffic from Kubernetes to primary DNS servers using Shadowsocks-libev for SOCKS5 implementation, and using Spectrum for DDoS protection of the Notify Listener service. The post also explains the underlying concepts of Secondary DNS, including SOA serial tracking, zone transfers (AXFR and IXFR), and the use of TSIG for security.
  80. Orange Clouding with Secondary DNSIntroduced Secondary DNS Override, a feature that builds on the 'Secondary DNS with a hidden primary' model. This allows customers to proxy A/AAAA/CNAME records through Cloudflare's network, hiding the origin IP and ensuring resolvers query Cloudflare's servers. The feature handles CNAME at the apex as an exception, overriding other A/AAAA records, and merges secondary, override, and CNAME at the apex records at edit time for efficient record resolution.
  81. Why is there a "V" in SIGSEGV Segmentation Fault?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.
  82. Making DNS record changes more reliableIntroduced a 'Save' button for DNS record edits in the Cloudflare dashboard to provide a confirmation step before changes propagate. This aims to prevent accidental 'fat-finger' errors, such as toggling the proxy icon or mistyping record content, which could lead to website or API outages. This feature applies to all record types and affects content, TTL, and proxy status changes.
  83. Secondary DNS — A faster, more resilient way to serve your DNS recordsIntroduced a new, simplified onboarding experience for Secondary DNS via the Cloudflare Dashboard, reducing setup time and preventing common configuration errors. Detailed the technical mechanisms of zone transfers (AXFR/IXFR) and the role of SOA records and NOTIFY messages. Emphasized the security implications of zone transfers and the necessity of TSIGs for authentication and integrity. Extended DNS analytics capabilities to Secondary DNS customers, providing insights into traffic by record type, response code, and geography.
  84. The Mistake that Caused 1.1.1.3 to Block LGBTQIA+ Sites TodayThis 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.
  85. Introducing 1.1.1.1 for FamiliesIntroduced 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.
  86. Announcing the Results of the 1.1.1.1 Public DNS Resolver Privacy ExaminationThis post details the results of an independent examination of Cloudflare's 1.1.1.1 public DNS resolver privacy commitments. It confirms that personal data is not retained and that IP addresses are truncated and anonymized for network troubleshooting and DoS mitigation. Commitments regarding data handling and retention have been clarified and refined, including specific details on IP truncation, log retention periods, and data sharing with APNIC for research purposes. The post also acknowledges past ambiguities in communication regarding anonymous log data handling and outlines updated privacy commitments.
  87. DNS Encryption ExplainedThis post explains the mechanisms of DNS over TLS (DoT) and DNS over HTTPS (DoH) for encrypting DNS queries and responses. It details the underlying TLS handshake for DoT and the reuse of HTTPS for DoH, highlighting the advantages of DoH in using port 443 to avoid firewall blocking and potential fallback attacks. It also touches upon the potential performance benefits of HTTP/3 and DNS over QUIC.
  88. Introducing time.cloudflare.comThis 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.
  89. RFC8482 - Saying goodbye to ANYThis post details the historical context, technical challenges, and community efforts leading to the deprecation of the DNS ANY query type via RFC8482. It explains how Cloudflare's authoritative DNS server and resolver implementations were updated to handle ANY queries by returning HINFO or NOTIMP respectively, simplifying codebases and mitigating DNS amplification attacks.
  90. Cloudflare Registrar at three monthsThis 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.
  91. One-Click DNSSEC with Cloudflare RegistrarThis post introduces a one-click DNSSEC enablement feature for domains registered with Cloudflare Registrar. It leverages CDS and CDNSKEY records to automate the process of provisioning and maintaining DS records with the registry, removing the manual steps previously required. This simplifies DNSSEC setup for users and aims to increase its adoption.
  92. Encrypting DNS end-to-endThis post details a pilot with Facebook to test the feasibility of securing the connection between 1.1.1.1 and Facebook's authoritative name servers using TLS. It found that while initial connection adds some latency, the overhead is amortized over many queries, resulting in DNS latency on par with average UDP connections.
  93. 1 Thing You Can Do To Make Your Internet Safer And FasterThis post announces the launch of the 1.1.1.1 mobile app, which simplifies the use of Cloudflare's public DNS resolver on mobile devices. It aims to increase adoption of 1.1.1.1, thereby improving internet speed and privacy for more users and indirectly benefiting websites that use Cloudflare by increasing traffic from users on 1.1.1.1.
  94. Cloudflare Registrar: what happens when you register a domain?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.
  95. Introducing Cloudflare Registrar: Domain Registration You Can LoveThis 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.
  96. Roughtime: Securing Time with Digital SignaturesThis 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.
  97. Introducing the Cloudflare Onion ServiceThis post introduces the Cloudflare Onion Service, a feature that allows Tor Browser users to connect to Cloudflare-hosted websites via the Tor network using HTTP/2 Alternative Services. This leverages the Tor onion service protocol and Cloudflare's existing infrastructure to provide improved security and performance for anonymous browsing. The mechanism involves using HTTP Alternative Services to advertise the .onion address, establishing a Tor circuit, and verifying a valid certificate for the original hostname. This approach increases the cost of denial-of-service attacks against the onion service by requiring a cryptographic key exchange for each connection.
  98. Expanding DNSSEC AdoptionThis post announces the General Availability and full support for CDS and CDNSKEY records for all Cloudflare managed domains that enable DNSSEC. This allows for setting up DNSSEC without requiring users to log in to their registrar to upload a DS record, automating the process of provisioning and managing DS records. It also details how parent registries can scan for and utilize these records, and encourages industry adoption of RFC8078.
  99. Welcome to Crypto WeekThis post announces Cloudflare's participation in 'Crypto Week,' highlighting new technologies that use cryptography to improve the Internet. It details announcements for Day 1 (IPFS Gateway), Day 2 (DNSSEC adoption), Day 3 (RPKI for BGP routing), Day 4 (Onion Service), and Day 5 (Roughtime). The post explains the fundamental trust issues on the Internet and how cryptography (hashes and digital signatures) can address them, specifically in routing, DNS, and HTTPS. It introduces RPKI for routing security and DNSSEC for trusted DNS resolution.
  100. Refresh Stale DNS Records on 1.1.1.1Introduced 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).
  101. Enable Private DNS with 1.1.1.1 on Android 9 PieThis post introduces the configuration of Cloudflare's 1.1.1.1 DNS resolver using the new Private DNS Mode in Android 9 Pie, which supports DNS over TLS (DoT). It details the steps to enable DoT on Android devices and explains the privacy benefits of encrypted DNS queries. The post also touches upon the ongoing work to encrypt SNI and the implications of IPv6 adoption on DNS resolution, particularly the requirement for hostnames instead of IP addresses for Private DNS configuration.
  102. Additional Record Types Available with Cloudflare DNSThis post introduces and explains the usage of nine new DNS record types: DNSKEY, DS, SSHFP, TLSA, SMIMEA, CERT, PTR, and NAPTR. It details how DNSKEY and DS facilitate delegated DNSSEC for child zones. It explains how SSHFP, TLSA, SMIMEA, and CERT can be used to enhance TLS and SSH security by specifying trusted certificates and keys within DNS, emphasizing the critical need for DNSSEC enablement. PTR records are explained for reverse DNS lookups and IP address ownership validation. NAPTR records are described in the context of service discovery, particularly for SIP. The post provides examples using `kdig` and `openssl` to demonstrate record configuration and verification.
  103. DNS-Over-TLS Built-In & Enforced - 1.1.1.1 and the GL.iNet GL-AR750SThis post details the integration of Cloudflare's 1.1.1.1 resolver with DNS-Over-TLS (DoT) support in the GL.iNet GL-AR750S router. It highlights the router's UI options for enabling DoT and enforcing encrypted DNS traffic for all clients. The post also includes technical details on how to verify encrypted DNS traffic using tcpdump and references previous work on configuring DoT on OpenWRT routers. The core contribution is the demonstration of a partner product natively supporting and enforcing DoT with Cloudflare's DNS service.
  104. Introducing DNS Resolver for TorIntroduced a Tor onion service for the 1.1.1.1 DNS resolver, accessible via dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion and tor.cloudflare-dns.com. This service forwards DNS queries through the Tor network, preventing the resolver from seeing client IP addresses and obscuring DNS requests from ISPs. It utilizes a single-onion configuration for improved latency and relies on a certificate for tor.cloudflare-dns.com with the .onion address as a subject alternative name. Alt-Svc headers are used to enable browsers like Firefox Nightly to route traffic to the .onion address.
  105. Today we mitigated 1.1.1.1This 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.
  106. Fixing reachability to 1.1.1.1, GLOBALLY!This post details the discovery and resolution of widespread reachability issues to Cloudflare's 1.1.1.1 DNS resolver. Investigations using RIPE Atlas probes revealed that a significant percentage of users were unable to reach 1.1.1.1 due to ISP routers misusing the IP address internally, ISPs blackholing or filtering traffic to 1.1.1.1, and customer premises equipment (CPE) devices hardcoding internal IP addresses that conflicted with 1.1.1.1. Cloudflare actively contacted ISPs and CPE manufacturers to resolve these issues, leading to a substantial increase in 1.1.1.1 availability globally. The post also highlights instances of Cisco Wireless LAN Controllers misusing 1.1.1.1 for captive portals and analyzes the unsolicited background traffic observed on 1.1.1.1 and 1.0.0.0/8 IP ranges.
  107. Privacy-Protecting Portable Router: Adding DNS-Over-TLS support to OpenWRT (LEDE) with UnboundThis post details the technical steps required to configure an OpenWRT (LEDE) router to use DNS-over-TLS (DoT) with Cloudflare's 1.1.1.1 resolver. It covers replacing the default Dnsmasq with Unbound and odhcpd, configuring Unbound to forward requests to Cloudflare's DoT endpoints, and merging DHCP configurations. The post provides concrete commands and configuration snippets for SSHing into the router, installing packages, and modifying configuration files. It demonstrates the successful encryption of DNS traffic using TLS v1.2.
  108. Announcing 1.1.1.1: the fastest, privacy-first consumer DNS serviceThis 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.
  109. Introducing DNS Resolver, 1.1.1.1 (not a joke)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'.
  110. It’s Hard To Change The Keys To The Internet And It Involves Destroying HSM’sThis post details the operational challenges and realities of rolling the root DNS zone's Key Signing Key (KSK) using the RFC5011 mechanism. It explains the states of cryptographic keys (Generated, Published, Active, Retired, Revoked), the difference between the root KSK and Zone Signing Key (ZSK), and the trust anchor mechanism for the root zone. The post highlights the postponement of the KSK rollover in 2017 due to issues with RFC5011 implementation adoption by validating resolvers, particularly with BIND-9. It discusses the operational complexities of resolvers maintaining state and persistent storage, and identifies failure modes in RFC5011 implementations. The post also touches upon the potential for switching to different cryptographic algorithms like elliptic curves in the future.
  111. CAA of the Wild: Supporting a New StandardThis post announces the removal of the beta flag for Certification Authority Authorization (CAA) Resource Records, making the feature available to all Cloudflare users. It details the purpose of CAA records in preventing certificate mis-issuance, explains the three property tags (`issue`, `issuewild`, `iodef`), and describes the recursive search algorithm for CAA records, highlighting potential issues with CNAME chains and the need for careful implementation.
  112. Delivering DotThis post details the performance improvements of F-Root instances hosted on Cloudflare's network. It shows a reduction in median RTT from 8.24ms to 4.24ms and a significant drop in 90th percentile response times. The post also presents data indicating an increase in traffic to F-Root due to its improved speed, citing external reports that named F-Root as the fastest root server in many regions.
  113. Less Is More - Why The IPv6 Switch Is MissingThis 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.
  114. Meet The Brand New DNS Analytics DashboardThis post introduces a new DNS analytics dashboard that provides detailed insights into DNS traffic for Cloudflare customers. It breaks down queries by response codes (NOERROR, NXDOMAIN), shows top queries and NXDOMAIN queries, and offers geographical breakdowns of query origins. Enterprise customers can filter by hostname and record type, including DNSSEC queries. The dashboard also provides access to a Grafana plugin and an API for custom data analysis, including IPv6 vs. IPv4 and UDP vs. TCP distributions.
  115. Changing Internet Standards to Build A Secure InternetThis 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.
  116. How we made our DNS stack 3x fasterCloudflare's DNS service has been made 3x faster by replacing two core elements: the authoritative DNS server (rrDNS) and the data pipeline that distributes DNS record changes to edge machines. The data pipeline was rewritten to use a new data model that groups RRSets by RRSet and combines values for common record types (A/AAAA/CNAME) into single keys, reducing KV store lookups. MessagePack was adopted as the serialization format for its speed and ease of integration with the existing Go codebase and the miekg/dns library. The new data pipeline, written in Go, propagates zone changes globally in seconds. The authoritative rrDNS server was also rewritten (v2) to align with the new data model, improving performance and test coverage. The new system has resulted in a 9x reduction in storage space at the edge and a 3x faster response time for DNS queries.
  117. How and why the leap second affected Cloudflare DNSThis post details a bug in Cloudflare's RRDNS software that caused DNS resolutions to fail for customers using CNAME records. The bug was triggered by a leap second, causing a time value to become negative when calculating the performance of upstream DNS resolvers. This negative value caused the weighted selection algorithm to panic. The fix involved ensuring that time differences are always non-negative, preventing negative values from being passed to the selection code.
  118. Manage Cloudflare records with SaltThis post introduces the Cloudflare Salt module, enabling users to manage DNS records via SaltStack. This provides a single source of truth for DNS configurations, peer-reviewed and versioned changes, and aims to offer a feature that customers would want to use. The module allows for configuration of zone records, including name, content, and proxy status, with dry-run capabilities before deployment. Future plans include extending Salt integration to other Cloudflare settings like WAF and caching.
  119. Debugging war story: the mystery of NXDOMAINThis 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.
  120. TLD glue sticks around too longThis post identifies an obscure feature in the core DNS protocol: TLD glue records with custom TTL values. It argues that the current hardcoded 48-hour TTL for glue records by TLD operators hinders aggressive DDoS mitigation techniques like 'DNS auth scattering,' where nameserver IPs could be rotated during an attack. The post explains DNS glue, its necessity to resolve the chicken-and-egg problem, and demonstrates through an experiment that glue record changes take 8-18 hours to propagate globally due to caching. It advocates for configurable glue TTLs to improve DDoS recovery time.
  121. How the Dyn outage affected CloudflareThis post details Cloudflare's response to the Dyn DDoS outage, focusing on improvements to its internal DNS infrastructure. The key technical contributions include: 1. Analysis of DNS error rates across data centers during the Dyn outage to understand the impact of third-party DNS provider unavailability. 2. Identification of the need for 'serve stale while revalidating' for DNS records to mitigate the effects of upstream DNS outages. 3. Implementation and rollout of this 'serve stale while revalidating' strategy to improve resilience for customers using CNAME'd DNS records that rely on third-party DNS providers.
  122. Dyn issues affecting joint customersThis post addresses an ongoing large-scale Denial-of-Service attack against Dyn DNS, which may affect joint Cloudflare and Dyn customers. It explains that CNAME records pointing to Dyn-hosted zones can cause website unavailability (1001 error) due to failed DNS queries to Dyn. Workarounds include updating Cloudflare DNS records from CNAMEs to A/AAAA records pointing directly to the origin IP, or migrating the authoritative DNS hosting to Cloudflare. The post also notes that Cloudflare's status page and support system might be affected due to their reliance on third-party hosting.
  123. Announcing New Features To Help Hosting Providers Run Their Own Reliable DNS InfrastructureCloudflare Virtual DNS now offers Serve Stale and DNS Rate Limiting features. Serve Stale allows Virtual DNS to answer queries from cache even if the customer's nameservers are down, providing a backup. DNS Rate Limiting allows configuration of query thresholds sent to customer nameservers, shielding their infrastructure from excessive load. These features enhance reliability for hosting providers running their own DNS infrastructure.
  124. How the Consumer Product Safety Commission is (Inadvertently) Behind the Internet’s Largest DDoS AttacksThis 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.
  125. Economical With The Truth: Making DNSSEC Answers CheapThis post details Cloudflare's optimization of DNSSEC negative answers (NXDOMAIN and NODATA) to reduce compute cost and response size. It explains the standard DNSSEC negative answer structure involving SOA, NSEC, and NSEC3 records, highlighting the computational expense and information leakage associated with NSEC's zone walking. Cloudflare's RRDNS server, built in Go and using a key-value store instead of zone files, dynamically generates answers. To address the cost and complexity of returning previous/next names for negative answers, Cloudflare implements a custom solution that avoids returning NSEC records for NXDOMAIN responses. Instead, it returns a specific RRSIG record that proves the non-existence of the name without revealing zone structure. For NODATA responses, it still returns an NSEC record but only one, proving the existence of the name and specifying the types that do exist.
  126. New for Virtual DNS Customers: Self-Service Dashboard and APIs, and Two New FeaturesIntroduced a new self-service dashboard and API for Virtual DNS, enabling programmatic management of settings via a REST API with example cURL command. Added Multi-User access control with mandatory 2FA option. Enhanced cache control by allowing customers to set minimum and maximum cache TTLs. Introduced the option to deprecate ANY queries.
  127. What happened next: the deprecation of ANYThis post details Cloudflare's decision and implementation to deprecate the DNS ANY query type. It explains the rationale behind this decision, including the lack of legitimate use, abundance of malicious use, and its role in DNS amplification DDoS attacks. The post discusses the conversation within the DNS community regarding the interpretation of ANY queries and the high cost of answering them, especially with DNSSEC. It outlines the chosen approach of returning a "harmless" HINFO record to recursive resolvers, which is small and cacheable, thereby reducing amplification potential. This approach is documented in the IETF draft 'Refuse ANY'.
  128. The revenge of the listening socketsThis 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.
  129. A Deep Dive Into DNS Packet Sizes: Why Smaller Packet Sizes Keep The Internet SafeThis post details Cloudflare's proactive measures to mitigate DDoS amplification attacks by optimizing DNS packet sizes. It highlights the use of ECDSA with 256-bit keys for DNSSEC signatures, resulting in significantly smaller response sizes compared to RSA implementations. Additionally, the post announces the deprecation of the ANY query type, which was often exploited for DDoS attacks, and explains the rationale and implementation of this change. The combined effect of these measures is to keep DNS answers within a 512-byte UDP packet limit, thereby preventing abuse.
  130. A tale of a DNS exploit: CVE-2015-7547This post details the discovery and analysis of CVE-2015-7547, a buffer overflow vulnerability in GNU libc's DNS stub resolver. It provides proof-of-concept exploits for both on-path and off-path scenarios, demonstrating how attackers can achieve memory corruption and remote code execution by manipulating DNS responses. The post critically evaluates and debunks proposed mitigations like limiting DNS response sizes, highlighting their ineffectiveness and potential for harm. It emphasizes the critical need for immediate patching and suggests running local caching resolvers as a partial defense, while also illustrating a cache traversal attack against djbdns' dnscache.
  131. Flexible, secure SSH with DNSSECThis 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.
  132. Announcing Universal DNSSEC: Secure DNS for Every DomainThis post announces the general availability of Universal DNSSEC for all Cloudflare users, aiming to secure DNS for every domain. It highlights the vulnerability of traditional DNS to on-path attacks and introduces DNSSEC as a solution. The post details the delegation of trust in DNSSEC and the manual process of activation, which involves copying keys between Cloudflare and registrar dashboards. To address this friction and promote wider adoption, Cloudflare has published an Internet Draft proposing a protocol for direct communication between DNS providers and registries/registrars. This protocol aims to automate DNSSEC activation, with initial support from registries like .ca, .cl, and .ee. The post also mentions early adoption by registrars like OVH and Hover, and the use of ECDSA as Cloudflare's chosen cipher for DNSSEC.
  133. Creative foot-shooting with Go RWMutexThis post details a bug in the Go RWMutex implementation within Cloudflare's RRDNS server. A background goroutine periodically reloaded an IP table, acquiring a write lock. A consumer function used read locks. When the table reload function ran while queries were being processed, its pending write lock call blocked subsequent read lock calls, causing a deadlock. This highlights a subtle concurrency bug where a blocked Lock call can prevent new readers from acquiring the RLock, leading to a deferred deadlock. The post suggests improvements in tooling for static and dynamic analysis of mutex usage.
  134. DNSSEC is Open for BetaThis post announces the opening of the DNSSEC beta to all websites using Cloudflare for DNS, allowing them to implement cryptographic hashes and signatures for authenticating DNS records to mitigate on-path attacker attacks. Previously, access was limited to a private beta.
  135. DNS parser, meet Go fuzzerThis 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.
  136. A deep look at CVE-2015-5477 and how CloudFlare Virtual DNS customers are protectedThis post details a specific DNS exploit (CVE-2015-5477) in BIND9 that causes a crash due to a failed assertion when handling TKEY queries. It provides a deep dive into the vulnerable code, tracing the bug flow from the `dns_message_findname` function to the `dns_tkey_processquery` function. The post explains how a non-TKEY record in the EXTRA section, combined with a subsequent call to `dns_message_findname` without resetting the `name` pointer, triggers the assertion failure. It also highlights that Cloudflare's Virtual DNS customers were protected because their custom Go DNS server, RRDNS, sanitizes queries and does not relay EXTRA section records for TKEY queries.
  137. Quick and dirty annotations for Go stack tracesThis 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.
  138. The Internet is a cooperative system: CNAME to Dyn DNS outage of 6 July 2015This post details an outage caused by an upstream DNS provider (Dyn) experiencing configuration issues, which impacted Cloudflare customers using CNAME records. Cloudflare engineers identified the issue by observing CNAME-based sites being affected, while domains hosted entirely on Cloudflare or external sites remained unaffected. The company collaborated with Dyn to resolve the issue and implemented temporary workarounds on their side.
  139. Blue Light Special: Ensuring fast global configuration changesThis 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.
  140. The oldest trick in the ASCII bookThis 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.
  141. Announcing Virtual DNS: DDoS Mitigation and Global Distribution for DNS TrafficThis post introduces Virtual DNS, an authoritative DNS proxy service that extends Cloudflare's DDoS mitigation and global distribution capabilities to any organization's DNS nameservers. It acts as an edge cache for DNS responses, reducing load on origin nameservers, and filters malicious traffic before it reaches the origin. It also masks origin IP addresses and provides continued DNS resolution even if the origin nameserver is offline, leveraging Cloudflare's edge network for performance and resilience.
  142. Deprecating the DNS ANY meta-query typeThis post announces the deprecation of the DNS ANY meta-query type. Cloudflare will begin responding to ANY queries with a 'Not Implemented' (rcode 4) response in a few weeks. The rationale is that ANY queries are not widely used by legitimate software, are primarily used for debugging, and are often exploited for DNS reflection attacks due to their large response sizes. Deprecating ANY simplifies Cloudflare's DNS server codebase and enhances security by mitigating amplification attacks.
  143. Updating the DNS Registration Model to Keep Pace with Today’s Internet.This post identifies a critical limitation in the current domain industry registration model that prevents automated updates of Name Server (NS) and Delegation Signer (DS) records. This manual process hinders Cloudflare's ability to provide a seamless signup experience and automate DNSSEC implementation. Cloudflare advocates for a new model where DNS operators can directly communicate with registrars and registries to automate these updates, which would improve stability, DDoS resilience, and enable broader DNSSEC adoption.
  144. Path MTU discovery in practiceThis 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.
  145. DNSSEC Done RightThis post details Cloudflare's approach to implementing and deploying DNSSEC, focusing on generating signatures at the edge on demand. It highlights the use of ECDSA P-256 for smaller signatures and faster generation, and NSEC with ECC keys for negative answers to minimize data volume and prevent zone walking. The goal is to keep most signed answers under 512 bytes.
  146. Help us test our DNSSEC implementationThis post announces the public release of Cloudflare's first DNSSEC signed zone (www.cloudflare.com) for community analysis and feedback. It highlights the company's approach to modern DNSSEC implementation, including signing on the fly to prevent NSEC record exposure, using ECDSA for smaller answers and reduced reflection attack risk, and offering a managed solution. The post also includes a call for beta testers and a technical question about ECDSA algorithm numbers.
  147. DNSSEC: Complexities and ConsiderationsThis post details the complexities of DNSSEC, specifically focusing on zone content exposure through NSEC and NSEC3 records, and the challenges of key management. It explains how NSEC records can reveal all subdomains in a zone and how NSEC3, while intended to mitigate this, can still be vulnerable to dictionary attacks. The post also discusses 'DNSSEC white lies' as a mitigation technique requiring real-time signing, and contrasts different key management modes (offline, centralized online, live signing).
  148. DNSSEC: An IntroductionThis post introduces DNSSEC as a set of security extensions to DNS that provide 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. The post details how DNS works, including its hierarchical namespace and the role of authoritative servers and resolvers. It announces Cloudflare's plan to introduce DNSSEC in the next six months, with Olafur Gudmundsson, one of the inventors of DNSSEC, leading the project.
  149. Making code better with reviewsThis post details a specific code improvement within Cloudflare's DNS server related to filtering invalid DNS packet flags. The author initially added a comment to explain a bitmask check (`0x86` and `0x4f`). A code review led to a refactoring that replaced the magic numbers with named constants (`QR`, `AA`, `TC`, `Z`, `RCODE`) and a more explicit bitwise OR operation, significantly improving code readability and maintainability. This demonstrates the impact of code reviews on improving code quality and security.
  150. Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain's RootIntroduced CNAME Flattening, a feature that allows CNAME records at the root of a domain while still adhering to DNS RFCs by resolving the CNAME chain to an A record. This addresses edge cases, particularly with Microsoft Exchange email servers, and provides flexibility for users of cloud services. The feature also offers an ancillary benefit of decreasing CNAME resolution time by approximately 30% on average due to caching and direct connections to authoritative servers.
  151. The weird and wonderful world of DNS LOC recordsThis post details the debugging and resolution of an issue where Cloudflare's RRDNS server was not serving LOC records. The root cause was identified as a missing parser for the textual LOC record format, which needed to be converted into RRDNS's internal binary format. The author implemented a parser for the LOC text record type and associated tests, which has now been rolled out to production, enabling RRDNS to serve existing LOC records.
  152. CloudFlare DNS is simple, fast and flexibleThis post introduces Cloudflare's DNS service, highlighting its core features and advantages over traditional DNS providers. It explains the fundamental concepts of DNS resolution, the limitations of traditional DNS (latency due to geographical distance and long TTLs), and how Cloudflare's Anycast network addresses these issues by routing requests to the nearest data center. The post emphasizes the benefits of short TTLs (5 minutes by default) for rapid DNS record updates, enabling dynamic IP address changes for services like DynDNS and quick failover for enterprise services. It also details how low TTLs aid in on-the-fly attack mitigation by allowing rapid null-routing of malicious traffic. The post concludes by mentioning ongoing investigations into future DNS-related services, such as geo-based routing.
  153. What we've been doing with GoThis 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.
  154. Details Behind Today's Internet HacksThis post details a specific incident of a registrar compromise (MelbourneIT) that led to unauthorized DNS name server updates for multiple high-profile domains, including The New York Times, Twitter, and The Huffington Post. Cloudflare collaborated with OpenDNS and Google to mitigate the impact by correcting DNS records and advising on registry locks. It explains the roles of registries, registrars, and recursive DNS providers in the DNS chain and highlights the vulnerability of the system to registrar-level attacks. The post also discusses the use of registry locks as a protective measure.
  155. The story of a little DNS easter eggThis post details the replacement of PowerDNS with a custom-built authoritative name server called RRDNS. RRDNS addresses challenges faced by PowerDNS under heavy DDoS loads and limitations in extending its functionality. The post highlights RRDNS's modular framework, which allows for easy integration of application logic, demonstrated by an 'easter egg' feature that dynamically retrieves job listings via a CH record query. A critical safeguard is also described: forcing TCP retries for specific queries to prevent DNS reflection attacks by leveraging TCP's handshake mechanism.
  156. What's the story behind the names of CloudFlare's name servers?Introduced a novel naming convention for Cloudflare's name servers using a pool of 2- to 4-letter names (e.g., Bob, Lola, Woz) to create unique combinations for customer signups. This system was designed to resolve conflicts when multiple users attempt to sign up the same domain simultaneously, ensuring that the correct DNS records are served by identifying the authoritative name servers. The names were chosen to be non-obvious to prevent users from attempting to add more name servers than necessary, which could cause verification failures. The system provides 2,550 unique combinations (51 boy names, 50 girl names) and indirectly references hundreds of servers across Cloudflare's global data centers, enabling load balancing and scalability.
  157. CloudFlare: Fastest Free DNS, Among Fastest DNS PeriodThis post announces Cloudflare's achievement of being the second fastest DNS provider globally according to SolveDNS tests, with an average response time of 4.51ms. It highlights the company's investment in making its DNS fast and responsive, leveraging its Anycast network. A future release, RRDNS, is planned to further enhance DNS lookup speeds.
  158. CloudFlare (aka. KickassDNS)This post details Cloudflare's authoritative DNS network, highlighting its speed and resilience as demonstrated by a SolveDNS report. It explains the use of Anycast routing across 17 (soon to be 23) data centers, where every server can answer any DNS query for any client, ensuring high availability and speed. The post also introduces 'KickassDNS,' the user-friendly control panel for DNS management, emphasizing its rapid update propagation (under a second) and the ability to change backend IPs without DNS propagation delays. Custom DNS servers for Business and Enterprise plans, and offering the DNS infrastructure to hosting provider partners, are also mentioned as advancements.
  159. Never Deal With DNS Propagation AgainThis post describes how Cloudflare's DNS service, by acting as an intermediary and using its own stable IP addresses, eliminates DNS propagation delays for customers when they change their origin servers or IP addresses. This is presented as a customer benefit that simplifies development and deployment.
  160. CloudFlare & OpenDNS Work Together to Help the WebThis post details a collaboration between Cloudflare and OpenDNS to address the DNSChanger malware. Cloudflare contributed by providing authoritative DNS services for the DNSChanger Working Group (DCWG) website to handle high load, and by developing and releasing an open-source 'Visitor DNSChanger Detector App' that injects JavaScript into websites to detect and inform users about DNSChanger infections. OpenDNS provided recursive DNS services and remediation guidance. The post explains the roles of recursive and authoritative DNS servers and how DNSChanger malware manipulates recursive DNS settings. It highlights the importance of DNS and the complementary nature of Cloudflare's and OpenDNS's services in improving Internet speed and safety.
  161. CloudFlare's New UI: Managing DNS recordsThis post details updates to the Cloudflare UI for managing DNS records. It introduces clearer explanations for the orange and gray cloud icons, provides step-by-step instructions for editing existing DNS records (e.g., changing server IP addresses), and guides users on adding new DNS records. It also addresses common issues such as subdomains not working and mail not functioning, offering specific configurations for A, CNAME, and MX records, with a visual example for Google Apps email.
  162. Non-Latin/UTF8 International Domains (IDNs) Now Fully SupportedThis post announces the full support for Internationalized Domain Names (IDNs) directly within the Cloudflare interface. Previously, users had to use Punycode representations for non-Latin domains. Cloudflare now handles the conversion to Punycode seamlessly for DNS resolution and has upgraded its UI site-wide to support the entire UTF8 character set, removing restrictions on Latin characters in forms.
  163. Post Mortem: The Ugly, the Bad & the GoodThis post details a significant incident where the primary DNS database was accidentally deleted during a push of a new, faster DNS update system. The new system's rapid propagation across 10 data centers resulted in widespread outages for sites hitting those centers. The recovery process involved retrieving backups and pushing them to production, which took approximately 5 minutes. Two data centers experienced further issues processing the large update, extending the outage for some users. The incident also highlighted the impact of external DNS caches and the presence of invalid DNS entries for certain TLDs. As a result, new safeguards were added to prevent similar incidents, and the team learned from the experience to build further redundancy and resiliency.
  164. Wow, That's Fast! Instant DNS Updates and More...Introduced KTFS (Key-Value based File System) for faster deployment of SSL certificates and DNS updates. KTFS allows for changes to be made in one location and branched out to the entire network following a tree-like path, similar to BitTorrent. This reduced DNS update propagation time from ~5 minutes to under 1 minute.
  165. Robust, Free DNS FTWThis post introduces Cloudflare's authoritative DNS service, highlighting its use of Anycast for global distribution and resilience, contrasting it with underinvested ISP and registrar DNS offerings. It explains the roles of recursive and authoritative DNS servers and positions Cloudflare's service as a robust, free alternative that rivals commercial offerings in terms of data center count and server capacity.
  166. EveryDNS Magic Data Liberation BookmarkletThis post introduces a 'Data Liberation Tool' and a 'Data Liberation Bookmarklet' that allow EveryDNS users to export their DNS data in BIND format. This tool was developed in response to EveryDNS requiring users to pay to export their data upon shutdown. The post highlights Cloudflare's commitment to data ownership and ease of migration, contrasting it with other companies' practices. It also promotes Cloudflare's own DNS service as a free, globally distributed, Anycast DNS solution.
  167. CloudFlare and SEOThis post details how Cloudflare addressed issues with search engine crawlers being restricted due to shared IP addresses. The company invented a technology to automatically change a site's Cloudflare IP addresses to isolate it from other sites when a problem is detected. They also worked with search engine crawl teams to get Cloudflare's IP ranges categorized, allowing for maximum crawl velocity and preventing sites from being clustered to a least performant denominator or incorrectly geo-tagged. This resulted in improved page speed scores and SEO rankings.
  168. Zone Apex / Naked Domain / Root Domain CNAME Support for Amazon EC2, Google App Engine and Other Cloud HostsIntroduced support for CNAME Flattening, a feature that allows the zone apex (root domain) to be configured as a CNAME record. This overcomes the DNS RFC limitation that requires the zone apex to be an A Record, enabling users to point their root domain directly to cloud hosting services like AWS EC2, Rackspace Cloud, and Google App Engine without resorting to workarounds. This feature enhances flexibility for users of cloud hosting providers.