<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on The Cloud Wire</title><link>https://wire.zerotrust-network.de/posts/</link><description>Recent content in Posts on The Cloud Wire</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Thu, 28 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://wire.zerotrust-network.de/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>One Private Endpoint, Many SQLs: Port-Multiplexed Private Link to On-Prem</title><link>https://wire.zerotrust-network.de/posts/private-link-service-to-onprem-sql/</link><pubDate>Thu, 28 May 2026 00:00:00 +0000</pubDate><guid>https://wire.zerotrust-network.de/posts/private-link-service-to-onprem-sql/</guid><description>Introduction Picture a data platform in an isolated VNet. It needs to read from SQL Servers that still live on-premises. You can&amp;rsquo;t peer to the hub, because the address space overlaps. The only way out of that VNet is a Private Endpoint.
So you reach for Private Link. One Private Link Service and one Private Endpoint per SQL Server. It works for the first one. By the fourth, every new backend is its own approval, its own DNS record, and another line on the bill.</description></item><item><title>Breaking Up the Flat Zone: Sharding Azure Private DNS</title><link>https://wire.zerotrust-network.de/posts/sharding-azure-private-dns-zones/</link><pubDate>Tue, 28 Apr 2026 00:00:00 +0000</pubDate><guid>https://wire.zerotrust-network.de/posts/sharding-azure-private-dns-zones/</guid><description>TL;DR Split your one flat private DNS zone (zerotrust-network.de) into per-team or per-environment shards (infra.zerotrust-network.de, apps.zerotrust-network.de, and so on), then put an Azure DNS Private Resolver in the hub to glue them back together.
The reason to shard is blast radius and admin scope, not scaling. Each shard becomes its own RBAC and lifecycle boundary. Each shard is registration-linked to as few VNets as possible (typically the one VNet whose workloads it represents) and resolution-linked to the hub VNet.</description></item><item><title>Delivering Anycast DNS in Azure with Infoblox Universal DDI and Virtual WAN</title><link>https://wire.zerotrust-network.de/posts/delivering-anycast-dns-azure/</link><pubDate>Sun, 20 Jul 2025 00:00:00 +0000</pubDate><guid>https://wire.zerotrust-network.de/posts/delivering-anycast-dns-azure/</guid><description>Originally published on LinkedIn.
Introduction In my previous blog, I walked through how to deploy Anycast DNS with Infoblox Universal DDI on AWS using Cloud WAN. That design showed how enterprises can build a globally available and resilient DNS fabric by combining centralized Infoblox management with AWS&amp;rsquo;s global networking backbone.
As promised, in Part Two, we shift focus to Microsoft Azure. Many of the customers I work with operate hybrid or multi-cloud environments, and a common pattern I see is that the DNS challenges on AWS also appear on Azure.</description></item><item><title>Delivering Anycast DNS in AWS with Infoblox Universal DDI and AWS Cloud WAN</title><link>https://wire.zerotrust-network.de/posts/delivering-anycast-dns-aws/</link><pubDate>Sun, 15 Jun 2025 00:00:00 +0000</pubDate><guid>https://wire.zerotrust-network.de/posts/delivering-anycast-dns-aws/</guid><description>Originally published on LinkedIn.
Introduction Over the past few months, in conversations I&amp;rsquo;ve had with enterprises running workloads across multiple regions and hybrid clouds, one theme kept coming up: DNS keeps biting them. Everyone wants the same thing: consistent, resilient DNS services that just work everywhere. But when you start layering in multi-cloud topologies, global reach and the need for fast failover, Anycast DNS quickly shifts from &amp;ldquo;nice to have&amp;rdquo; to &amp;ldquo;hard to manage.</description></item></channel></rss>