ASR-0005 Framework for DNS

Andi Lamprecht ·2026-05-11· 2 min read· Accepted

Overview

There is a breakdown in communication caused by a lack of consistency in how we name endpoints for services internally and externally, this ADR seeks to address this issue.

Current Problems

We are currently operating DNS without a design, intention or methodology which leads to

• Inconsistent domain names like this, this and this for internal services and lead to communication silos
• Replication of DNS capabilities in AWS, Cloudflare, JumpCloud, GCP, Godaddy.. you can see the extent of it here

Proposed Solutions

Naming convention for DNS for service endpoints

[service_name].[service_environment].droneup.cloud - Option #1

[service_name].[product_name].[service_environment].droneup.cloud - Option #2 eg inventory.uncrew.staging.droneup.cloud

Single DNS provider managed via IaC

• Since most of our software workloads run in GCP, using their DNS service will simplify our integrations on multiple points
• DNS resources managed in cloudflare, Godday, AWS and other providers will need to be migrated to Google’s Cloud DNS
• CDN, Certificate Management and Web server hosting are related to DNS but are outside the scope of this ADR.

Final Decision

Naming convention for DNS for internal-only service endpoints

[service_name].[product_name].[service_environment].droneup.cloud - Option #2 eg inventory.uncrew.staging.droneup.cloud

Guidelines

• You only need your service_name, product_name and service_environment in the DNS.
• team_name, league_name, service_version, cluster_name, gcp_project_name and other information about this service should be managed elsewhere

Product Sign-off for customer facing service endpoints

• Require product review (via user stories) and sign-off for DNS names for external service endpoints

Single DNS provider managed via IaC

• Since most of our software workloads run in GCP, using their DNS service will simplify our integrations on multiple points