

Cloudflare Area 1 is a cloud-native email security service that identifies and blocks attacks before they hit user inboxes, enabling more effective protection against spear phishing, Business Email Compromise (BEC), and other advanced threats. Cloudflare Area 1 is part of the Cloudflare Zero Trust platform and an essential component of a modern security and compliance strategy, helping organizations to reduce their attackers surface, detect and respond to threats faster, and improve compliance with industry regulations and security standards.
This announcement is another step in our commitment to remaining strong in our security posture.
Many customers want assurance that the sensitive information they send to us can be kept safe. One of the best ways to provide this assurance is a SOC 2 Type II report. We decided to obtain the report as it is the best way for us to demonstrate the controls we have in place to keep Cloudflare Area 1 and its infrastructure secure and available.
Cloudflare Area 1’s SOC 2 Type II report covers a 3 month period from 1 January 2023 to 31 March 2023. Our auditors assessed the operating effectiveness of the 70 controls we’ve implemented to meet the Continue reading
Got this question from a networking engineer attending the Building Next-Generation Data Center online course:
Has anyone an advice on LACP fast rate? When and why should you use it instead of normal LACP?
Apart from forming link aggregation groups, you can use LACP to detect link- and node failures (more details). However:
Got this question from a networking engineer attending the Building Next-Generation Data Center online course:
Has anyone an advice on LACP fast rate? When and why should you use it instead of normal LACP?
Apart from forming link aggregation groups, you can use LACP to detect link- and node failures (more details). However:
In Kubernetes, the Domain Name System (DNS) plays a crucial role in enabling service discovery for pods to locate and communicate with other services within the cluster. This function is essential for managing the dynamic nature of Kubernetes environments and ensuring that applications can operate seamlessly. For organizations migrating their workloads to Kubernetes, it’s also important to establish connectivity with services outside the cluster. To accomplish this, DNS is also used to resolve external service names to their corresponding IP addresses. The DNS functionality in Kubernetes is typically implemented using a set of core-dns pods that are exposed as a service called kube-dns. The DNS resolvers for workload pods are automatically configured to forward queries to the kube-dns service.
The output below shows the implementation of the kube-dns services in a Kubernetes cluster.
kubectl get service kube-dns -n kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) kube-dns ClusterIP 10.0.0.10 <none> 53/UDP,53/TCP
The core-dns pods have to rely on external DNS servers to perform domain name resolution for services outside the cluster. By default, the pods are configured to forward DNS queries to the DNS server configured in the underlying host in the /etc/resolv.conf file. The output below displays Continue reading
IT organisations tend towards two strategic approaches - enduring, permanent and susatined. Or short term, consumable and fungible IT.
The post HS049 Evanescent vs Enduring IT appeared first on Packet Pushers.
Today's Day Two Cloud explores some design themes that emerged from the Cloud Field Day event. These themes include platform engineering, data protection and recovery, and how to deal with the fact that old technology never dies. Guest Michael Levan joins Ned Bellavance and Ethan Banks to discuss these themes and their implications for cloud application builders and operators.
The post Day Two Cloud 198: Modern Cloud Design Themes From CFD 17 appeared first on Packet Pushers.


In January 2021, we gave you a behind-the-scenes look at how we built Waiting Room on Cloudflare’s Durable Objects. Today, we are thrilled to announce the launch of Waiting Room Analytics and tell you more about how we built this feature. Waiting Room Analytics offers insights into end-user experience and provides visualizations of your waiting room traffic. These new metrics enable you to make well-informed configuration decisions, ensuring an optimal end-user experience while protecting your site from overwhelming traffic spikes.
If you’ve ever bought tickets for a popular concert online you’ll likely have been put in a virtual queue. That’s what Waiting Room provides. It keeps your site up and running in the face of overwhelming traffic surges. Waiting Room sends excess visitors to a customizable virtual waiting room and admits them to your site as spots become available.
While customers have come to rely on the protection Waiting Room provides against traffic surges, they have faced challenges analyzing their waiting room’s performance and impact on end-user flow. Without feedback about waiting room traffic as it relates to waiting room settings, it was challenging to make Waiting Room configuration decisions.
Up until now, customers could only monitor their waiting room's Continue reading
Distributed systems are complicated. Add networking to the mix, and you get traumatic challenges like the CAP theorem and Byzantine fault tolerance. Most of those challenges are unknown to engineers who have to suffer through the vendor marketing presentations, making it hard to determine whether the latest shiny gizmo works outside of PowerPoint.
I started collecting articles describing distributed-system gotchas years ago, wrote numerous blog posts on the topic in the heydays of the SDN Will Save the World lemming run, and organized them into the Distributed Systems Resources page.
Distributed systems are complicated. Add networking to the mix, and you get traumatic challenges like the CAP theorem and Byzantine fault tolerance. Most of those challenges are unknown to engineers who have to suffer through the vendor marketing presentations, making it hard to determine whether the latest shiny gizmo works outside of PowerPoint.
I started collecting articles describing distributed-system gotchas years ago, wrote numerous blog posts on the topic in the heydays of the SDN Will Save the World lemming run, and organized them into the Distributed Systems Resources page.