Dns

The Problem: Selective Network Outages Over Tailscale When users reported that database access through a Tailscale exit node was failing while RDP connections remained functional, the initial symptoms suggested a routing or firewall issue. However, the real culprit was much more subtle: DNS resolution was being silently dropped at the exit node level. Why This Setup Exists at All: Azure Private Link Resolves Differently Depending on Where You’re Standing Before getting into the dnsmasq “bug” itself, it’s worth explaining why this infrastructure exists in the first place, because the root problem isn’t Tailscale or dnsmasq, it’s that Azure Private Link’s DNS behavior is context-dependent, and a VPN mesh network doesn’t naturally live in any single context. ...

The Problem Inbound mail was intermittently producing spf=temperror results in Exchange Online despite a valid, RFC 7208-compliant SPF record and no delivery failures. Messages were accepted and delivered, so no NDRs, no user-visible symptoms, but authentication headers showed this: Authentication-Results: spf=temperror (sender IP is 209.85.128.197) smtp.mailfrom=yourdomain.com Received-SPF: TempError (protection.outlook.com: error in processing during lookup of yourdomain.com: DNS Timeout) External resolvers (Google (8.8.8.8), Cloudflare (1.1.1.1)), direct queries to the authoritative nameserver, all resolved the SPF record cleanly and consistently. The timeout was happening exclusively inside Exchange Online’s MTA infrastructure. ...

We deployed an Azure VPN Gateway to give remote users secure access to Azure SQL databases through private endpoints. The setup looked textbook perfect: private endpoints approved and connected, VNet peering configured, routes in place, TCP connectivity verified. Everything worked except the one thing that mattered—users couldn’t authenticate. Here’s what we learned fighting Azure’s DNS architecture. The Setup That Should Have Worked Standard Azure private endpoint architecture for SQL Server: ...