Skip to main content

TechnitiumDNS on Google Cloud Run

TechnitiumDNS on Google Cloud Run

⚠️ Scoping disclosure: this module deploys Technitium's web admin console + REST API only (port 5380/HTTP). Technitium's core DNS resolver function (port 53/udp+tcp) cannot be exposed through Cloud Run's HTTP(S)-only ingress. No client anywhere can query this deployment as a DNS resolver. See §1 and §7 below for the full explanation.

Technitium DNS Server is a self-hosted, open-source, cross-platform authoritative and recursive DNS server (.NET) with a full-featured web admin console and REST API for managing zones, records, DNS-based ad/tracker blocking, conditional forwarding, and DNS-over-HTTPS/TLS. This module deploys the official technitium/dns-server image on Cloud Run v2, unmodified, on top of the App_CloudRun foundation, which provisions and manages the shared Google Cloud infrastructure.

This guide focuses on the cloud services TechnitiumDNS uses and how to explore and operate them from the Google Cloud Console and the command line. For the mechanics common to every Cloud Run application — service identity, ingress and load balancing, scaling and concurrency, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, backups, and the deployment lifecycle — refer to the App_CloudRun foundation guide rather than repeating them here.


1. Overview

TechnitiumDNS runs as a single prebuilt container on Cloud Run v2. The deployment wires together a deliberately small set of Google Cloud services — TechnitiumDNS has no database or cache dependency of its own:

CapabilityGoogle Cloud serviceNotes
ComputeCloud Run v2Single prebuilt container, 500m vCPU / 512 MiB by default; request-based billing, scales to zero
DatabaseNonedatabase_type = "NONE"; zones/settings/logs are local flat files, no Cloud SQL provisioned
PersistenceCloud Storage (GCS FUSE)Config bucket mounted at /etc/dns; survives restarts and redeploys
Object storageCloud StorageOne auto-created "config" bucket (also the persistence layer above)
Cache / queueNoneNo Redis; TechnitiumDNS needs no external cache
SecretsSecret ManagerOne auto-generated secret: DNS_SERVER_ADMIN_PASSWORD
IngressCloud Run URL / Cloud Load BalancingDefault run.app URL for the web console only — port 53 is never exposed

Sensible defaults worth knowing up front:

  • No database is provisioned. database_type = "NONE" — TechnitiumDNS keeps zones, settings, and logs as local flat files under /etc/dns. The database-related variables exist for completeness but are inert.
  • Persistent by default. A GCS FUSE volume is mounted at /etc/dns automatically — config, zones, and logs survive restarts and redeploys with no extra configuration.
  • Prebuilt image, no custom Dockerfile. container_image_source = "prebuilt" deploys technitium/dns-server as-is — verified locally to boot cleanly and honour DNS_SERVER_ADMIN_PASSWORD / DNS_SERVER_DOMAIN on first start.
  • Scales to zero by default (min_instance_count = 0, cpu_always_allocated = false) — the admin console is a plain request/response app with no background scheduler or WebSocket stream.
  • The health endpoint is /, the console's unauthenticated root page, which returns HTTP 200 with the full console HTML as soon as the server binds its port.
  • One auto-generated secret. DNS_SERVER_ADMIN_PASSWORD bootstraps the initial admin account on the very first boot only; later restarts ignore it (the persisted auth.config wins).
  • No DNS resolver. See §7 below — this is the single most important thing to understand before deploying this module.

2. Google Cloud Services & How to Explore Them

All commands assume PROJECT and REGION are set. Service and resource names are reported in the deployment Outputs.

A. Cloud Run — the TechnitiumDNS console service

TechnitiumDNS runs as a Cloud Run v2 service. Each deployment creates an immutable revision; traffic can be split across revisions for safe rollouts.

  • Console: Cloud Run → select the service for revisions, traffic, logs, and metrics.
  • CLI:
    gcloud run services list --project "$PROJECT" --region "$REGION"
    gcloud run services describe <service-name> --project "$PROJECT" --region "$REGION"
    gcloud run revisions list --service <service-name> --project "$PROJECT" --region "$REGION"

See App_CloudRun for scaling, concurrency, execution environment, and traffic splitting.

B. Persistence — the config Cloud Storage bucket

TechnitiumDNS has no Cloud SQL instance. All zones, settings, the auth database, and logs live under /etc/dns, backed by a GCS FUSE-mounted Cloud Storage bucket created for this deployment.

  • Console: Cloud Storage → Buckets → find the bucket named gcs-<service-name>-config.
  • CLI:
    gcloud storage buckets list --project "$PROJECT" --filter="name~-config"
    gcloud storage ls "gs://<bucket-name>/"

See App_CloudRun for the GCS FUSE volume mount model.

C. Secret Manager

TechnitiumDNS generates exactly one secret at deploy time: the initial admin password.

  • Console: Security → Secret Manager.
  • CLI:
    gcloud secrets list --project "$PROJECT" --filter="name~admin-password"
    gcloud secrets versions access latest --secret=<secret-name> --project "$PROJECT"

See App_CloudRun for injection and rotation details.

D. Networking & ingress

The service is reachable at its run.app URL by default — this is the web console URL, not a DNS endpoint. An external HTTPS load balancer with a custom domain, Cloud CDN, and Cloud Armor can be layered on for the console; none of this exposes DNS resolution (port 53).

  • Console: Cloud Run (service URL); Network services → Load balancing.
  • CLI:
    gcloud run services describe <service-name> --region "$REGION" --format='value(status.url)'
    gcloud compute addresses list --project "$PROJECT"

See App_CloudRun.

E. Cloud Logging & Monitoring

Container logs flow to Cloud Logging; Cloud Run metrics flow to Cloud Monitoring, with optional uptime checks and alert policies.

  • Console: Logging → Logs Explorer; Monitoring → Dashboards / Alerting.
  • CLI:
    gcloud run services logs read <service-name> --project "$PROJECT" --region "$REGION" --limit 50

3. TechnitiumDNS Application Behaviour

  • No first-deploy database setup. TechnitiumDNS has no external database and no migration step. It reads/writes local flat files under /etc/dns from the moment it boots.
  • First-boot admin bootstrap. DNS_SERVER_ADMIN_PASSWORD is applied only when /etc/dns/auth.config does not yet exist (a genuinely fresh deployment). On every later restart or redeploy, the persisted auth.config on the GCS-mounted volume wins and the injected password is ignored.
  • Health path. Startup and liveness probes target /, which returns HTTP 200 with the full console HTML as soon as the server binds port 5380. Verify:
    SERVICE_URL=$(gcloud run services describe <service-name> \
    --project "$PROJECT" --region "$REGION" --format='value(status.url)')
    curl -s -o /dev/null -w '%{http_code} %{size_download}\n' "$SERVICE_URL/" # expect 200 and a large body
  • Log in. Open $SERVICE_URL in a browser, sign in as admin with the Secret-Manager-stored password, and change it immediately from the console's own user-management page (Technitium does not re-read DNS_SERVER_ADMIN_PASSWORD after first boot, so changing it there is the only way to rotate it going forward).
  • REST API. All console actions are also available over the REST API ($SERVICE_URL/api/...) using a session token obtained via /api/user/login. See Technitium's API docs.
  • No DNS resolution from this deployment. See §7 below.

4. Configuration Variables

Variables are grouped exactly as they appear on the deployment platform. Only settings specific to or notable for TechnitiumDNS are listed; every other input is inherited from App_CloudRun with its standard behaviour.

Group 1 — Project & Identity

VariableDefaultDescription
project_id(required)Target Google Cloud project.
regionus-central1Region for the service and regional resources.

Group 2 / 3 — Deployment Environment & Application Identity

VariableDefaultDescription
tenant_deployment_iddemoShort suffix that makes resource names unique per environment.
application_nametechnitiumdnsBase name for the service, registry repo, and secrets. Do not change after first deploy.
application_display_nameTechnitiumDNSHuman-readable name shown in the Console.
application_versionlatestTechnitiumDNS image version tag (e.g. latest, 13.5.1).

Group 4 — Runtime & Scaling

VariableDefaultDescription
deploy_applicationtrueSet false to provision supporting infrastructure only.
container_image_sourceprebuiltDeploys the official image as-is; custom accepted for forward-compatibility but no Dockerfile ships.
cpu_limit500mCPU per instance.
memory_limit512MiMemory per instance (gen2 floor is 512Mi).
min_instance_count0Scales to zero when idle.
max_instance_count1Maximum instances.
container_port5380The web console's default port.
cpu_always_allocatedfalseRequest-based billing — no background work to keep warm for.
enable_cloudsql_volumefalseOff — TechnitiumDNS has no database.
enable_image_mirroringtrueMirror the TechnitiumDNS image into Artifact Registry.

Group 5 — Access & Networking

VariableDefaultDescription
ingress_settingsallPublic console access by default.
enable_iapfalseRequire Google sign-in. Strongly recommended — the console otherwise relies solely on its own admin password.

Group 6 — Environment Variables & Secrets

VariableDefaultDescription
environment_variables{}Extra DNS_SERVER_* settings (e.g. DNS_SERVER_FORWARDERS, DNS_SERVER_DOMAIN).
secret_environment_variables{}Map of env var → Secret Manager secret name (additional secrets; DNS_SERVER_ADMIN_PASSWORD is already wired).

Group 11 — Storage & Filesystem

VariableDefaultDescription
gcs_volumes[]Additional GCS buckets to mount; the config bucket at /etc/dns is auto-added.
storage_buckets[]Additional buckets beyond the auto-created config bucket.
enable_nfsfalseNot needed by default — the GCS volume at /etc/dns already persists state.

Group 12 — Database Backend

VariableDefaultDescription
database_typeNONETechnitiumDNS has no external database; leave NONE.
application_database_name / application_database_usertechnitiumdnsInert — no database is provisioned.

Group 13 — Jobs & Scheduled Tasks

VariableDefaultDescription
initialization_jobs[]TechnitiumDNS needs no init job; leave empty.
cron_jobs[]Optional scheduled Cloud Run jobs.

Group 14 — Observability & Health

VariableDefaultDescription
startup_probeHTTP / 20s delayStartup probe targeting the console's public root page.
liveness_probeHTTP / 30s delayLiveness probe.
uptime_check_config{ enabled=false, path="/" }Optional Cloud Monitoring uptime check.

Group 16 — Redis Cache

VariableDefaultDescription
enable_redisfalseNot required — TechnitiumDNS has no Redis dependency.

All other inputs follow standard App_CloudRun behaviour.


5. Outputs

Returned on a successful deployment — the quickest way to locate and explore the running resources.

OutputDescription
service_nameCloud Run service name.
service_urlDefault run.app URL of the web console (not a DNS endpoint).
service_locationRegion the service runs in.
stage_servicesStage-specific service URLs (Cloud Deploy).
load_balancer_ip / load_balancer_urlExternal HTTPS load balancer IP / URL (when enabled).
database_instance_name / database_name / database_userDatabase identifiers — empty for the default NONE engine.
database_password_secret / database_host / database_portDatabase endpoint fields — unused for NONE.
storage_bucketsCreated Cloud Storage buckets (the config bucket).
network_name / network_exists / regionsVPC network, presence, regions.
container_image / container_registryDeployed image and Artifact Registry repo.
monitoring_enabled / monitoring_notification_channels / uptime_check_namesMonitoring status, channels, uptime checks.
initialization_jobsNames of any setup jobs (none by default).
deployment_id / tenant_id / resource_prefixNaming identifiers.
project_id / project_numberProject identifiers.
cicd_enabled / github_repository_url / github_repository_owner / github_repository_name / cicd_configurationCI/CD status and details.
artifact_registry_repository / cloudbuild_trigger_name / cloudbuild_trigger_idRegistry and build trigger.
vpc_sc_enabled / vpc_sc_perimeter_name / vpc_sc_dry_run_modeVPC-SC status.
audit_logging_enabled / artifact_registry_cmek_enabledAudit logging and CMEK status.

6. Configuration Pitfalls & Sensible Defaults

Risk: Critical (data loss / outage / security) — High (service degraded) — Medium (cost or partial degradation) — Low (minor).

Inherited plan-time validation. This module passes its configuration through the App_CloudRun foundation engine, which validates values and combinations at plan time. Invalid configuration fails the plan with a clear, named error before any resource is created.

SettingSensible valueRiskConsequence if wrong
Expecting this to be a DNS resolverDo not point client DNS settings at this deploymentCriticalPort 53/udp+tcp is never exposed by Cloud Run's HTTP(S)-only ingress — DNS queries against this deployment simply fail; only the web console/API is reachable.
enable_iaptrue for anything beyond a quick testCriticalWithout IAP, the console is protected only by its own admin password over the public internet — a single leaked/weak credential grants full DNS-management access.
DNS_SERVER_ADMIN_PASSWORD rotationChange the password from the console after first loginHighTechnitium never re-reads the env var after first boot — rotating the Secret Manager value alone does NOT change the effective console password.
GCS volume at /etc/dnsLeave enable_gcs_storage_volume enabled (default)CriticalWithout a mounted persistent volume, Cloud Run's read-only root filesystem would prevent any config/zone change from surviving a restart or redeploy.
ingress_settingsall for console access, internal behind IAP/VPN only if that's the intentMediuminternal blocks all external access to the console, including the operator, unless a VPN/bastion path exists.
min_instance_count0 (default) is fine for occasional admin useLowCold starts add a few seconds of latency on the first request after idling; bump to 1 only if that matters.
application_versionPin an explicit version in productionLowlatest tracks upstream releases; pin explicitly to control upgrade timing.

For the foundation behaviour referenced throughout — service identity, scaling and concurrency, ingress and load balancing, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC-SC, backups, and image mirroring — see App_CloudRun. TechnitiumDNS-specific application configuration shared with the GKE variant is described in TechnitiumDNS_Common.