How Caddy Serves a Static Site: The Request Flow
See how Caddy handles a request for a static site, from DNS resolution through container routing to file_server, and how TLS and redirects fit into the flow.
Loading…
Topic
DNS
13 posts about DNS. Every summary links to the original.
- 13 posts
- 5 companies
- 3 explainers
See the idea
DNS explainers
BIMI: The Identity Proof Behind the Logo
BIMI is a DNS-published claim that ties a verified brand logo to an authenticated domain, so mailbox providers can display it. Here is what each part of that claim requires.
Anycast: One IP, Many Locations
Anycast announces a single IP address from multiple geographic locations so routers automatically direct users to the nearest server, improving latency and resilience without client changes.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Multi-region disaster recovery for Amazon API Gateway WebSocket APIs
WebSocket connections for real-time applications like live auctions and collaborative editors are vulnerable to regional outages because each connection is tied to a single AWS Region. A regional failure severs all active connections and loses session state. This post presents an active-passive multi-region disaster recovery pattern that uses Amazon API Gateway WebSocket APIs, Route 53 failover routing, DynamoDB Global Tables for cross-Region state replication, a canary health probe, and client-side reconnection logic. The canary Lambda function tests the endpoint every minute and drives a CloudWatch alarm that triggers a Route 53 health check to mark the primary Region unhealthy. Clients detect connection drops via application-level heartbeat messages and reconnect with exponential backoff and full jitter to avoid thundering herd. After reconnection, clients retrieve the latest application state from the secondary Region’s DynamoDB replica and resume their session automatically.
The keys to the Internet change on October 11. Are you ready?
On October 11, 2026, the DNS root will replace its DNSSEC key-signing key (KSK) for only the second time, moving from KSK-2017 to KSK-2024. The rollover changes the trust anchor that validating resolvers use to verify the root’s DNSKEY records. Cloudflare has published KSK-2024 in the root’s DNSKEY set since January 11, 2025, and added it to its own resolver’s built-in trust anchors in July 2024. To help operators check readiness, Cloudflare uses RFC 8509 root key trust anchor sentinels, which let a resolver report whether it trusts a given key. Most website operators need no action, but DNSSEC-validating resolvers should confirm they trust KSK-2024 before the switch.
How APRF Helps You Understand Your Email Reputation
Aggregate Performance Reporting (APRF) is a draft standard for email deliverability feedback backed by contributors from Comcast, Google, and Iterable. It gives senders aggregated, intentionally bucketed signals about message classification—such as inbox or unwanted—and user engagement, categorized as positive, negative, or neutral. It also describes daily JSON reports delivered to a DNS-configured address, with provider-specific bucket definitions optionally documented in extra_info. Senders can configure a TXT record derived from the DKIM selector and domain, then use the optional sdi attribute and email header to segment results by business, region, campaign, or other values. The sample shows separate classification and engagement data for marketing and transactional segments, while acknowledging that counts are approximate; APRF is not yet adopted by an IETF working group, Comcast sends reports, and Gmail does not yet.
The New DMARC is Here
DMARCbis is finalized as three Standards Track RFCs: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. Existing DMARC records continue working as before, so most senders do not need immediate changes. The largest behavioral update replaces Public Suffix List lookups with an algorithmic DNS Tree Walk, in which receivers query _dmarc records up the DNS hierarchy; the psd tag can declare hierarchy boundaries. The pct tag is replaced by boolean t, while np can specify a policy for non-existent subdomains, including np=reject. Reporting knobs rf and ri are removed, but rua and ruf remain available; senders using fractional pct should use a none-to-quarantine-to-reject rollout, keep reading reports, and avoid rushing to reject.
Custom Tracking Domains
Resend has launched custom tracking domains, making the feature free for all users. Email tracking typically relies on shared domains, so another sender’s reputation can affect deliverability. Users configure the feature at the domain level by adding a required DNS record, after which Resend routes tracking through the custom domain; both click and open tracking are disabled by default. Click tracking records link clicks through redirects, while open tracking records image downloads from a 1x1 transparent pixel. Custom domains align tracking links with the sending domain, avoid unfamiliar recipient-facing domains, and can improve deliverability; API configuration accepts open and click tracking flags plus a tracking subdomain, while webhooks emit real-time open and click events.
A Foolish Consistency: Consul at Fly.io
Fly.io’s global application platform uses Consul as a service-discovery catalog, but the post argues that a single globally consistent store is a poor fit for every part of the system. Consul Servers run Raft, while lightweight agents register events; fly-proxy consumes generated JSON describing service instances, and separate data tracks network distance. Because load and health are volatile, Fly.io moved load gossip to NATS and lets fly-proxy generate and distribute health hints, while Consul remains useful for orchestration and status. Strong consistency remains important for DNS, where stale or missing addresses can break ordinary applications; the proposed remedy is optional internal Anycast, routing internal traffic through fly-proxy. The conclusion is qualified: Consul is easy to deploy and valuable for infrastructure configuration, but Fly.io’s trajectory is away from using it as the backing store for a global app platform.
The October Fly Changelog: Preview Disks and DNS and Better Builtins
The October Fly changelog records platform and CLI updates, centered on preview persistent disks, configurable builtins, environment-variable configuration, and status monitoring. The new volumes commands let Fly applications create persistent disks whose data survives restarts, deployments, and suspension; the feature remains in preview. Applications can now set environment variables in fly.toml instead of using the secrets feature, while builtin settings expose controls such as Deno permissions and HTTPS auto-upgrading and logging for the static web server. flyctl 0.0.145 also adds Python/Procfile builtin support, a --watch status mode that polls every five seconds, a --rate option, default-org selection in init, and fixes for token checks and wildcard certificate domains.
Stuff Your Pi-Hole From Anywhere
Pi-Hole blocks advertising and tracking domains by acting as a DNS server that returns a dummy address for listed hosts, but a home deployment is difficult to use while traveling and can incur latency. The post presents “Fli-Hole,” a globally reachable Pi-Hole application deployed on Fly’s edge network, using the official Docker image without modifying Pi-Hole itself. Its configuration sets INTERFACE and DNSMASQ_LISTENING, exposes UDP port 53 through fly.toml, stores the web password as a Fly secret, and deploys with fly deploy. Additional Fly regions, such as Frankfurt, can be added so nearby traffic is routed through them. Each regional instance has independent settings and no persistence or sharing, while Dockerfile changes and redeployment provide a way to distribute configuration updates.
An Introduction to DNS Traffic Management
DNS traffic management applies data-driven DNS responses to direct clients to different service endpoints, extending DNS’s basic role of mapping domain names to IP addresses. The post introduces DNS through its history from HOSTS.TXT, explains zones, records, nameservers, root servers, TTL, and negative TTL, then connects caching behavior to routing decisions. Low TTLs can make changes visible sooner, but repeated DNS resolution adds latency: with a one-second resolution time, a 15-second TTL could add 5,760 seconds per day, compared with 1,440 seconds at 60 seconds; resolver behavior can also make delays slightly longer. Use cases include active-passive failover, active-active traffic sharing, progressive green-blue deployments, and location-based routing, while Shopify’s system evolved into an automated, self-served platform serving more than 40 domains across 12 teams and over 100M requests per 24 hours.
Using DNS Traffic Management to Add Resiliency to Shopify’s Services
Shopify consolidated several team-specific DNS traffic-management approaches that relied on manual changes, pull requests, or provider APIs and had uneven failover, redundancy, and active/active capabilities. The replacement was a fully automated, self-served system for more than 40 domains owned by more than 12 teams and handling more than 100M requests per day. It stores domain configuration in Git, deploys it to two DNS providers, and exposes spy commands for fast updates and failovers. Its traffic-management design uses regionalized matching, endpoint-status filtering, weighted sharing, and fallback layers, while globally matching endpoints ensure an existing domain receives an answer. A later provider migration demonstrated the value of centralized ownership: the team updated Terraform and tooling, moved nameservers incrementally, and kept the change transparent to application owners despite concurrent incidents.
How CDNs Generate Certificates
Fly describes how its CDN automatically generates TLS certificates for customer hostnames with Let’s Encrypt and ACME, focusing on why the older tls-sni-01 validation method was unsafe on shared hosting. ACME authenticates an account with an ECDSA/EdDSA key, creates an order, and verifies domain control through challenges; Fly uses tls-alpn-01, which avoids requiring DNS access or port 80. For validation, Fly requests a challenge, creates a self-signed certificate containing Let’s Encrypt’s token, stores it in distributed certificate storage, and signals the CA to connect with a ClientHello selecting acme-tls/1 via ALPN. The Rust proxy recognizes that ALPN case, retrieves the challenge certificate, and serves it to Let’s Encrypt, which completes the challenge and permits certificate issuance. Fly assigns each application a unique routable IPv6 address and requires CNAME resolution to it for ALPN validation; wildcard certificates instead use DNS challenges.
How to do Custom Domains with Fly
Custom Domains with Fly is an application guide for using Fly to proxy traffic or serve applications across multiple custom domains. It explains how to configure an NGINX server for external sites and how to attach host and domain names to Fly applications with the flyctl command line. For automated workflows, it describes the Fly GraphQL API operations for adding, removing, checking, and deleting hosts and associated certificates, and points to a repository of ready-rolled Node applications demonstrating the API. The guide's speed run retrieves an app's IPv4 and IPv6 addresses, adds corresponding A and AAAA DNS records, creates a certificate with flyctl, and uses another command to monitor issuance. The resulting setup provides auto-renewing Let's Encrypt TLS certificates, edge TLS, and HTTP/2 support; the guide also states that Fly applications have no limit on attached certificates and can scale on demand.
Fly Friday - News and Tips
This Fly weekly update collects product news, community announcements, and a flyctl usability improvement. It points to guidance for building GraphQL APIs with Fly and for running a private DNS over HTTPS (DoH) service, while noting Firefox’s default DoH rollout in the USA. It also announces a new Fly user community portal with GitHub or social-media sign-in, alongside Turboku’s Product Hunt launch for faster Heroku apps. The technical note covers flyctl 0.0.96’s -c/--completion option: supplying bash or zsh generates a completion file, with zsh users able to redirect it to $fpath[1]/_flyctl and Bash users required to choose a location and source it from .bashrc.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.