sota.io
2026-05-02·12 min read·sota.io team
# AWS Route 53 EU Alternative 2026: DNS Query Logs, Resolver Data, and the CLOUD Act Problem DNS infrastructure occupies an unusual position in the GDPR compliance conversation. Because it is infrastructure — a utility layer that resolves domain names to IP addresses — it is rarely included in data protection impact assessments. The GDPR analysis focuses on the application database, the email processor, the analytics platform. DNS resolution is treated as a technical necessity that happens outside the data-protection perimeter. This assumption is wrong for Amazon Route 53, and the gap it creates is significant. Route 53 Resolver, when query logging is enabled, records every DNS query made by resources in your VPC. That record includes the querying IP address and the domain name queried. A DNS query log for a corporate network is effectively a browsing history — which domains employees accessed, at what times, in what sequence. For application infrastructure, it reveals which external services your applications call, which third-party APIs they depend on, and which security tools, analytics platforms, and monitoring services are active. This data is stored in Amazon CloudWatch Logs or Amazon S3 — both operated by Amazon Web Services, Inc., a Delaware corporation subject to the CLOUD Act. A compelled disclosure request served on Amazon yields not just what is in your application databases, but the complete DNS query history for every resource in your VPC. Route 53 also processes personal data in contexts beyond query logging: health check targets, traffic policy routing decisions based on geolocation, and the hosted zone data that maps your domain names to infrastructure. This article examines each vector. --- ## What Route 53 Processes: Data Flows Across Five Components Route 53 is not a single service but a collection of DNS-related capabilities. Each creates distinct GDPR exposure: **1. Hosted Zones (Authoritative DNS):** Route 53 stores DNS record sets for domains you control — A, AAAA, CNAME, MX, TXT, and other record types. The zone data itself (record names and values) is typically not personal data. But the query logs generated when resolvers query your hosted zone do contain personal data: the IP addresses of querying resolvers. **2. Route 53 Resolver (Recursive DNS for VPC):** The default DNS resolver for resources in an Amazon VPC. When query logging is enabled, Resolver captures every DNS lookup: source IP, queried domain, response type, and timestamp. **3. Route 53 Resolver for Hybrid Clouds (Inbound/Outbound Endpoints):** Enables DNS resolution between VPCs and on-premises networks. Creates forwarding rules for specific domains. The endpoint configuration reveals internal network architecture; query logs reveal internal-to-cloud and cloud-to-internal DNS traffic. **4. Route 53 Health Checks:** Periodically probe endpoints (URLs, IP addresses, other Route 53 records) from multiple AWS regions to assess availability. Health check configuration and results are stored in Route 53 and CloudWatch. **5. Route 53 Traffic Policies:** Route traffic based on geolocation, latency, weighted distribution, or failover. Traffic policy routing decisions use the source IP address of the querying resolver to determine geolocation — a form of processing that creates location-linked routing records. --- ## GDPR Failure Vector 1: Resolver Query Logs as Employee and User Browsing History Route 53 Resolver query logging is an optional feature that many organisations enable for security monitoring and debugging. When enabled, it creates a continuous log of every DNS query made by EC2 instances, Lambda functions, containers, and other VPC resources. **What Resolver query logs contain:** - `srcids`: The VPC ID and the AWS resource ID (e.g., EC2 instance ID) that made the query - `srcaddr`: The source IP address of the querying resource - `srcport`: The source port - `queryName`: The domain name queried (e.g., `api.stripe.com`, `telemetry.example.com`, `internalapp.yourcompany.com`) - `queryType`: Query type (A, AAAA, MX, etc.) - `responseCode`: DNS response code (NOERROR, NXDOMAIN, SERVFAIL, etc.) - `queryTimestamp`: UTC timestamp with millisecond precision For corporate environments using Route 53 Resolver on-premises via Outbound Endpoints, the `srcaddr` is the IP address of an on-premises machine — potentially identifiable as a specific employee workstation. **The personal data classification:** Under GDPR Art.4(1), personal data includes any information relating to an identified or identifiable natural person. An IP address that can be linked to a specific device — which can be linked to a specific employee — is personal data. The domain queried, when combined with the timestamp and IP, creates a record of browsing behaviour attributable to a specific person. This is not a theoretical concern. DNS query logs for a corporate network show: which employees accessed which internal applications (HR systems, payroll, benefits portals), which external services they used (mental health platforms, medical information sites, political news sources), and when they were active (implying work hours, rest patterns, timezone activity). **The CLOUD Act exposure:** Resolver query logs are delivered to CloudWatch Logs or S3 — both US-entity services. A compelled disclosure request for your Route 53 Resolver query logs yields the complete DNS history for every resource in your VPC. For an organisation with employees whose workstations route through VPC-based DNS, this is the browsing history of every employee — including health-seeking behaviour, union-affiliated site visits, and political news consumption that may constitute Art.9 special category data in combination. --- ## GDPR Failure Vector 2: Hosted Zone Query Logs as Infrastructure Intelligence Route 53 query logging (distinct from Resolver query logging) captures DNS queries directed at your public hosted zones. When enabled, it logs every query to your authoritative nameservers. **What hosted zone query logs contain:** - The queried domain and record type - The IP address of the recursive resolver that made the query (typically a public resolver like Google 8.8.8.8, Cloudflare 1.1.1.1, or an ISP resolver) - The edge location of the Route 53 authoritative server that responded - The timestamp **The personal data nuance:** The querying IP in hosted zone logs is typically the recursive resolver, not the end user. However: - When users are querying from networks that use a unique resolver per user or per subnet, the resolver IP can identify the user's network. - When users bypass recursive resolvers and query authoritative nameservers directly (uncommon but possible), their client IP appears in the logs. - The query itself — which subdomain of your application was queried, at what time — reveals application usage patterns. A query to `api.yourapp.com` at a specific timestamp may be correlatable with user activity records to identify the user. **The Art.5(1)(e) retention problem:** DNS query logs for hosted zones accumulate in CloudWatch Logs. Without explicit log group retention policies (which CloudWatch does not set by default), these logs persist indefinitely. GDPR requires retention only as long as necessary for the stated purpose. Security monitoring of authoritative DNS traffic does not require indefinite retention; 30-90 days is typically sufficient. Indefinite retention of query logs is an Art.5(1)(e) violation. --- ## GDPR Failure Vector 3: Health Check Probes as Operational Exposure Route 53 Health Checks are configured to monitor the availability and performance of your endpoints. They make HTTP/HTTPS/TCP requests to your specified URLs from multiple AWS edge locations globally. **What health checks create:** - **Your application logs receive requests from AWS IP ranges:** Every health check probe appears in your application's access logs as a request from an AWS IP address. For applications that log request bodies or header content for debugging, health check payloads (if any) appear in your logs. - **Health check results are stored in CloudWatch:** Status history, latency measurements, and failure events are stored in CloudWatch Metrics and CloudWatch Logs — US entity services. - **Health check configuration reveals application architecture:** The health check endpoint, expected response content, and alarm thresholds document your application's internal structure in Route 53's US-entity-hosted configuration. **The Art.32 security consideration:** Health check endpoints must be reachable from AWS IP ranges. This requires firewall rules that allow inbound access from a large set of AWS IP addresses. An organisation that has implemented IP allowlisting for security must open its firewall to thousands of AWS IP addresses for health checks — potentially expanding the attack surface. --- ## GDPR Failure Vector 4: Geolocation Routing as Art.22 Automated Decision-Making Route 53 Traffic Policies include geolocation routing: Route 53 inspects the source IP of a DNS query, infers the querying user's country or continent from a geolocation database, and returns the appropriate DNS record. **The geolocation inference chain:** 1. User's device queries a recursive resolver 2. Recursive resolver queries Route 53 authoritative nameserver 3. Route 53 uses EDNS Client Subnet (ECS) — the querying resolver may include the client's /24 subnet — or falls back to the resolver IP for geolocation 4. Route 53 matches the IP/subnet to a country in its geolocation database 5. Route 53 returns the geolocation-specific DNS response **The Art.22 question:** If geolocation routing results in users being directed to different application versions (different feature sets, different prices, different content availability) based solely on their inferred location, this may constitute automated decision-making under Art.22 — a decision made solely by automated processing, based on personal data (IP address), that produces effects on the data subject's interaction with your service. The geolocation inference is imperfect: VPNs, Tor, and mobile carrier NAT can produce incorrect country inferences. A user receiving a geolocation-based routing outcome based on incorrect inference has no mechanism to contest it under the standard Route 53 configuration. Art.22(3) requires operators to implement "suitable measures to safeguard the data subject's rights and freedoms" including "at least the right to obtain human intervention on the part of the controller." --- ## GDPR Failure Vector 5: DNSSEC Key Material Under US Jurisdiction Route 53 supports DNSSEC for signed zones. When Route 53 manages DNSSEC signing, the zone-signing keys (ZSK) are managed by Route 53's key management infrastructure — AWS KMS (US entity). **The key management exposure:** The DNSSEC keys used to sign your zone are stored in AWS KMS under US-entity management. A compelled disclosure request could theoretically reach the KMS key material, depending on the scope of the order and the technical implementation. More practically: the DNSSEC signing infrastructure — which keys were used, when, for which domains — is operational data stored in Route 53 and AWS CloudTrail (if API logging is enabled). This infrastructure data documents which domains are DNSSEC-enabled and the history of signing key rotations. **The Art.32 consideration:** DNSSEC signing keys protect the integrity of your DNS zone. Having those keys managed by a US entity that is subject to compelled disclosure creates a theoretical integrity risk: a sophisticated adversary with access to signing keys can create fraudulent DNS responses that pass DNSSEC validation. --- ## EU-Sovereign Route 53 Alternatives: Comparison | Platform | HQ | DNSSEC | Geo-Routing | Health Checks | GDPR DPA | CLOUD Act Risk | |----------|-----|--------|-------------|---------------|----------|----------------| | **deSEC** | Germany | ✅ | Limited | No | ✅ German DPA | None (DE entity) | | **Hetzner DNS** | Germany | ✅ | No | No | ✅ German DPA | None (DE entity) | | **Bunny DNS** | Slovenia | ✅ | ✅ | ✅ | ✅ EU DPA | None (EU entity) | | **Gcore DNS** | Luxembourg | ✅ | ✅ | ✅ | ✅ EU DPA | None (EU entity) | | **OVHcloud DNS** | France | ✅ | Limited | ✅ | ✅ French DPA | None (FR entity) | | **INWX** | Germany | ✅ | No | No | ✅ German DPA | None (DE entity) | | **PowerDNS (self-hosted)** | Netherlands | ✅ | ✅ | Via plugin | N/A (self-hosted) | None | --- ## Option A: deSEC — EU DNS for Security-Conscious Operators deSEC is a non-profit DNS hosting provider incorporated in Germany (Berlin), operated by a German registered association (Verein). It provides free DNSSEC-enabled DNS hosting as a public service, with strong privacy commitments and German legal jurisdiction. **Key GDPR advantages:** - No query logging at the zone level — deSEC does not retain DNS query logs for user zones - Minimal personal data collection — only email address for account management - German data protection law applies (DSGVO/GDPR) - No US entity involvement at any level - DNSSEC fully supported with automated key management **API-compatible migration from Route 53:** The deSEC REST API follows a similar pattern to Route 53's change batching. To create a zone, send a POST request to `https://desec.io/api/v1/domains/` with the domain name as a JSON body. To create an A record, POST to the rrsets endpoint for your domain with the subname, type (A), TTL, and IP address array. A Terraform provider is available for declarative management — the `desec_rrset` resource covers all standard record types. **Limitations:** deSEC does not offer geolocation routing, health checks, or traffic policies. It is a pure authoritative DNS service. For applications requiring advanced routing, Bunny DNS or Gcore DNS are more appropriate. --- ## Option B: Bunny DNS — EU Anycast with Advanced Routing Bunny.net (Slovenia, EU) offers a full-featured DNS service as part of its CDN platform. Bunny DNS provides anycast routing, DNSSEC, geo-routing, and health checks — functional parity with Route 53's advanced routing features, from an EU entity. **Key capabilities:** - Anycast DNS with 30+ PoPs globally, EU edge nodes available - Smart DNS routing: load balancing, failover, geo-routing, latency-based routing - Health check integration for automatic failover - DNSSEC support - API-first design with straightforward Terraform support **Geo-routing configuration:** Bunny DNS Smart Routing is configured via a JSON rule specifying the routing type (`geo`) and an array of regions — each region maps a list of country codes to a target IP address, with a default fallback. For an EU-primary setup, you would map DE/AT/CH to your EU server IP and set the EU IP as the default, with US/CA routing to a US server only when explicitly required. The Bunny API accepts these rules as straightforward JSON payloads. **Health check failover:** Bunny DNS health checks probe endpoints from multiple locations. Failover is automatic: if the primary record fails health checks, traffic routes to the failover record. This replicates Route 53's health check + failover routing combination. --- ## Option C: Self-Hosted PowerDNS — Complete Control PowerDNS (maintained by Open-Xchange, a German company) is an open-source authoritative DNS server that can be deployed on any Linux infrastructure. Self-hosting eliminates all third-party data processing for DNS. **Architecture:** ```bash # PowerDNS authoritative server with PostgreSQL backend # Debian/Ubuntu install: apt install pdns-server pdns-backend-pgsql # /etc/powerdns/pdns.conf: # launch=gpgsql # gpgsql-host=localhost # gpgsql-dbname=pdns # gpgsql-user=pdns # gpgsql-password=... # PowerDNS Admin (web UI): # docker run -d -p 9191:80 powerdnsadmin/pda-legacy:latest # API for programmatic zone management (Route 53-compatible workflow): # POST to /api/v1/servers/localhost/zones with JSON body specifying # the zone name, kind (Native/Master/Slave), and empty nameservers array. # See PowerDNS API docs for full record management endpoints. ``` **GDPR advantages:** Complete control over all data processing. No logs leave your infrastructure. Retention policies under your management. No Art.28 processor relationship required. **Operational requirements:** DNS is critical infrastructure — availability requirements are high. Self-hosted PowerDNS requires secondary nameservers, monitoring, and operational expertise. For most organisations, a managed EU-entity DNS provider is more appropriate. --- ## Migration Path: Route 53 to EU DNS ### Phase 1: Audit (1 day) 1. **List all hosted zones:** `aws route53 list-hosted-zones` 2. **Check query logging:** `aws route53 list-query-logging-configs` 3. **Check Resolver logging:** `aws route53resolver list-resolver-query-log-configs` 4. **Export zone records:** `aws route53 list-resource-record-sets --hosted-zone-id ZONE_ID` 5. **Document health checks:** `aws route53 list-health-checks` 6. **Document traffic policies:** `aws route53 list-traffic-policies` 7. **Identify DNSSEC-signed zones:** `aws route53 list-hosted-zones-by-name | grep DNSSEC` ### Phase 2: New DNS Setup (1-2 days) 1. **Create zones** in EU DNS provider 2. **Import records** — most providers accept BIND zone file format: ```bash # Export from Route 53 (via aws cli, save to file manually): aws route53 list-resource-record-sets --hosted-zone-id Z1234 --output json # Or use cli53: cli53 export yourdomain.eu (redirect output to .zone file) ``` 3. **Configure DNSSEC** if used 4. **Set up health checks** and failover routing in new provider 5. **Verify record propagation** before changing nameservers ### Phase 3: Resolver Logging Cleanup Before migration, address the Resolver query log data: 1. **Disable Resolver query logging** if enabled: `aws route53resolver disassociate-resolver-query-log-config` 2. **Set CloudWatch log group retention** on existing query log groups: `aws logs put-retention-policy --log-group-name /aws/route53 --retention-in-days 30` 3. **Document in ROPA** that query logging has been disabled and historical logs have a retention policy ### Phase 4: Nameserver Cutover 1. **Lower TTL** on current zone to 60 seconds — do this 24 hours before cutover 2. **Update nameservers** at your domain registrar to point to new EU provider's nameservers 3. **Monitor resolution** during propagation (typically 24-48 hours for full global propagation) 4. **Verify DNSSEC chain** if applicable — new DNSSEC DS records must be submitted to registrar ### Phase 5: Route 53 Decommission 1. **Disable and delete query logging configs** 2. **Delete health checks** associated with Route 53 3. **Delete hosted zones** (after confirming new nameservers are resolving correctly) 4. **Delete Resolver endpoints** for hybrid DNS if applicable 5. **Update Art.30 ROPA** — remove Route 53 as processor 6. **Update privacy notice** if it references DNS infrastructure providers --- ## A Note on Cloudflare DNS Cloudflare's 1.1.1.1 resolver and Cloudflare DNS hosting are sometimes proposed as Route 53 alternatives. The same caveat that applies to Cloudflare CDN applies here: Cloudflare, Inc. is a US entity incorporated in Delaware. Cloudflare DNS processes DNS queries on US-company-managed infrastructure subject to the CLOUD Act. Cloudflare has committed to strong privacy practices and offers DNSSEC, 1.1.1.1 for Families (content filtering), and Zero Trust DNS. But these commitments are contractual and operational — they do not eliminate the CLOUD Act jurisdiction. For organisations that require complete elimination of US-entity DNS processing, a genuine EU-incorporated provider (deSEC, Hetzner, Bunny, Gcore) is the appropriate choice. --- ## Conclusion DNS infrastructure sits at the foundation of every internet-connected service. For exactly that reason, it is often treated as infrastructure that is "outside" the GDPR conversation. Route 53 demonstrates why that reasoning fails. Resolver query logs are browsing histories for VPC resources — potentially for employee workstations. Hosted zone query logs document application usage patterns. Health check configurations document internal architecture. Geolocation routing makes automated decisions about which users see which content. All of this runs on US-entity infrastructure subject to CLOUD Act compelled disclosure. The six failure vectors documented here — Resolver query logs as browsing history, hosted zone query log retention, health check architectural exposure, geolocation routing as Art.22 automated decision-making, DNSSEC key material under US jurisdiction, and Resolver query data in CloudWatch — are structural. They require moving DNS infrastructure to EU-incorporated providers. For most EU applications, deSEC (non-profit, German, free) provides excellent authoritative DNS with strong privacy commitments for straightforward cases. For applications requiring advanced routing, health checks, and traffic policies, Bunny DNS or Gcore DNS provide Route 53 feature parity from EU entities. --- *sota.io is a European PaaS platform for teams that need EU-sovereign infrastructure. Deploy your applications — including DNS-dependent services — on infrastructure with EU-resident data processing and no US-entity processor relationships.*

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Start free — no credit cardView pricing