Introducing Cache Response Rules
Today we’re excited to announce Cache Response Rules. These are a new rule type that runs after an origin server replies but before Cloudflare caches the content.
If you've ever been irked watching something that should easily sail out of cache get dragged back to the origin by a stray Set-Cookie or wrong Cache-Control, headers that are sometimes hard or impossible to strip or change on the origin itself, then Cache Response Rules is that fix, applied at exactly the right moment.
When and how caching decisions are made
A CDN cache and an origin server work as a pair. Their goal is to answer from the cache whenever possible and only go back to the origin when the edge can’t respond. Every point of cache hit ratio comes from getting that division of labor right. Check the cache when we shouldn't, and we waste a lookup that was always going to miss. Check it too rarely, the origin serves traffic the edge should have absorbed and the performance win evaporates.
Importantly, the origin guides the cache. When it returns a cacheable asset, its response headers tell Cloudflare how long it’s OK to serve it, when and Continue reading
N4N060: Your First Wi-Fi Network Part 1
Have you ever wondered how data actually travels through a Wi-Fi network? Holly and Ethan break down the fundamentals of wireless networking, including radio frequencies and channel planning. They also address the complexities of roaming, how the Wi-Fi space has changed over the years, and share advice on how to design and maintain a home... Read more »What Happens to a VM’s IP When It Moves During Migration?
Why VM IP identity needs handling on Kubernetes
A KubeVirt VM runs inside a pod. That is the trick that lets Kubernetes schedule a VM like any other workload. It also means the VM and the pod have different lifecycles. The VM is long-lived and has a stable identity. The pod is disposable. When the VM reboots, gets evicted, or live-migrates, the pod underneath is destroyed and a new one is created.
That matters because a VM’s IP is load-bearing. Firewall rules, load balancer entries, and DNS records all point at it. On Kubernetes, standard pod IPAM ties the address to the pod, so a new pod would mean a new IP, and a changed IP is what breaks those dependencies. KubeVirt on its own does not carry the IP across a migration. Its issue tracker has a user reporting exactly this, with a maintainer confirming sticky IPs were never built into the project. The network identity needs something to carry it. That something is Calico.
The diagram below shows the difference this makes. Default pod networking on the left, Calico on the right.
How Calico keeps the IP
Calico’s approach is elegant and specific. Instead of building the IPAM Continue reading
How Google’s Axion CPUs Benefit The Cloud
PARTNER CONTENT: subhead subheadTCG080: Skills Over MCP and More
What if your MCP server shipped with its own manual? Angie Jones, VP of Developer Experience at the Agentic AI Foundation, joins William and Eyvonne to break down the Skills Over MCP working group effort, which delivers Agent Skills through MCP’s existing resources primitive (think voice over IP, not skills versus MCP). Angie shares her... Read more »NAN127: Scaling Network Automation Communities
Eric Chou welcomes Florian Lohden, a NetDevOps engineer and co-founder of the NetAuto Group, to discuss his community-building efforts and his latest adventures in network automation. Together they explore how adopting software development practices can help with network automation, and the importance of sharing knowledge within networking communities. Florian also talks about how he balances... Read more »D2DO308: Exploring the AI Governance Paradox (Sponsored)
In this sponsored episode, Jonah Kowall from Spacelift joins the show to unpack the findings of the 2026 Infrastructure Automation Report. The discussion covers the “governance paradox”, where organizations have confidence in their AI oversight despite a lack of formal policies. Ned and Jonah provide actionable insights on bridging the gap between automation and the... Read more »On the Futility of Opening Ansible Issues
Remember the anonymous troll who chided me for writing a rant instead of opening a GitHub issue in the relevant Ansible repository? Well, I decided to be an open-source poster boy when I stumbled upon the next Ansible bug, and ended up feeling like a sweet summer child :(
HS138: When “One Cloud To Rule Them All” Is NOT the Answer: Repatriation for AI and more
Some enterprises are finding reasons to pull back from a cloud-first IT strategy and run workloads in on-premises data centers. John and Johna dig into why companies are making the change, including cost and AI security. They also discuss and the strategic implications for IT, and what organizations stand to gain—and lose—from repatriation. Episode Links:... Read more »
PP118: IPv6 Risks In Dual-Stack Environments (i.e. Most Environments)
Unless you’ve intentionally migrated to all-IPv6, you’re operating in a dual-stack environment. And if you haven’t accounted for v6 in your monitoring and security, you leave yourself open to risks. Today we dig into some of those risks, including VPN breakouts and how attackers can use unmanaged v6 to bypass security tools. Our guest is... Read more »SONiC – ASIC Programming: Port Characteristics
The previous section described at a high level how the config_db.json file is loaded into the Redis CONFIG_DB database in the Database container. Next we look at the topic in slightly more detail. First, we examine how physical port information, such as the port's default speed and lane configuration, is processed during the initial boot before it is programmed into the switch ASIC.
Step 1: Creating a Config_db.json and Updating CONFIG_DB by Sonic-cogent
Figure
4-2 illustrates how platform-specific port information becomes the PORT and
BREAKOUT_CFG entries stored in the Redis CONFIG_DB database. During the image
initialization process, sonic-cfggen uses the platform-specific port_config.ini
file (1) together with other platform configuration files and templates to
generate the port-related entries in the config_db.json file (2). The
port_config.ini file defines the logical, expected physical characteristics of
the switch ports, including the front-panel alias names, lane mappings, index
values, subport values, and default port speeds. After the config_db.json file
has been generated, its contents are loaded into the Redis CONFIG_DB database
during the SONiC boot process (3).
Figure 4-2 also shows the DEVICE_METADATA table, which contains platform-specific information such as the base MAC address, switch_type, Continue reading
How the 2026 World Cup affected Internet traffic
For 96 years, the World Cup has been a global phenomenon, uniting nations and communities through a shared love of sportsmanship. While its popularity is nothing new, what is novel today is how rare a truly collective global experience has become. In an era defined by microtrends and algorithmic bubbles, it is increasingly uncommon for people across most countries to engage in the exact same event.
That is precisely the unifying power of the World Cup. Fans from all over the globe reshape their daily routines around these once-in-a-lifetime matchups and storylines — and because Cloudflare operates a global network with 330+ points of presence worldwide, we are in a unique position to see exactly how this global ritual reshaped the world’s online activity throughout June and July 2026.
Cloudflare Radar tracks HTTP traffic, DNS, security, and more to highlight global Internet trends. In this blog post we’ll use that data to explore how the World Cup impacted global traffic patterns throughout the tournament’s run.
How did the World Cup change our behavior online?
To understand how traffic changes throughout a match, we had to establish what it is “normally.” One way to do this Continue reading
Cloudflare Internal DNS is now generally available
Starting today, Cloudflare Internal DNS is generally available. Cloudflare Internal DNS provides authoritative and recursive DNS for private networks on the same global network and control plane customers already use for public DNS, Zero Trust, networking, and application services.
Internal DNS — sometimes also referred to as private DNS — is one of the last pieces of enterprise infrastructure still managed separately from the rest of the network. Many organizations operate one platform for public DNS, another for internal DNS, and use cloud-native DNS services inside each cloud environment with separate security policies layered on top. None of these systems share a common control plane. Split-horizon DNS adds another layer of complexity, often requiring multiple DNS environments to remain synchronized so internal and external users receive different answers for the same hostname. When those systems drift, outages follow.
With Cloudflare Internal DNS, you get a single platform to manage public and private DNS resources, enforcing DNS policies and gaining visibility across your entire DNS stack. For Enterprise customers, this is included with Cloudflare Gateway without any additional charge.
Why customers are adopting Internal DNS
Consolidate DNS operations. Public and private DNS run on one platform, with one API, one audit Continue reading