Skip to content

How to self-host authoritative DNS on Quake AI

How-to · Updated Jul 2026

Coming from another cloud?

▸AWS·Route53

This Quake AI feature maps to AWS’s Route53.

▸DigitalOcean·DNS Records

This Quake AI feature maps to DigitalOcean’s DNS Records.

▸Google Cloud·Cloud DNS

This Quake AI feature maps to Google Cloud’s Cloud DNS.

▸Hetzner·DNS

This Quake AI feature maps to Hetzner’s DNS.

How to self-host authoritative DNS on Quake AI

Run an authoritative DNS server you operate on a Quake AI instance. Quake AI does not host managed DNS for your domains. You launch a VM, install PowerDNS, publish zones, and delegate the domain from your registrar to the nameserver hostnames you control.

Prerequisites

Windows: CLI examples use bash. Set up a Linux CLI environment on Windows before proceeding.

  • An SSH key pair uploaded to your account
  • A domain you control at a registrar where you can edit nameserver delegation and glue records
  • A private network with a router attached to PublicStatic (create a VM on a private network builds my-private-net if you need one)

Choose authoritative software#

SoftwareBest forNotes
PowerDNS AuthoritativeGeneral authoritative DNS with a REST API and optional SQL backendsLead path in this guide
CoreDNSIn-cluster service discovery on KubernetesRun inside a Magnum cluster or as a sidecar; use PowerDNS when the zone must be authoritative on the public internet

This guide installs PowerDNS with the BIND zone-file backend on Ubuntu 22.04. The REST API listens on localhost; you reach it through SSH port forwarding.

Create a security group for DNS#

Allow DNS from the internet and SSH from your administrator address. Restrict the API to localhost on the instance; do not expose TCP 8081 on the floating IP.

Replace YOUR_ADMIN_CIDR with your workstation's public address, for example 203.0.113.10/32.

Launch the DNS instance and assign a floating IP#

SSH to the instance using the floating IP:

bash
ssh -i ~/.ssh/MY_KEYPAIR ubuntu@FLOATING_IP_ADDRESS

Install PowerDNS#

On the instance:

bash
sudo apt update
sudo apt install -y pdns-server pdns-backend-bind

Generate an API key:

bash
API_KEY=$(openssl rand -hex 16)
echo "API_KEY=$API_KEY"

Edit /etc/powerdns/pdns.conf and set:

ini
launch=bind
local-address=0.0.0.0,::
bind-config=/etc/powerdns/named.conf
api=yes
api-key=API_KEY
webserver=yes
webserver-address=127.0.0.1
webserver-port=8081
webserver-allow-from=127.0.0.1

Create /etc/powerdns/named.conf:

zone "example.com" {
  type master;
  file "/etc/powerdns/zones/example.com.zone";
};

Create the zone directory and file:

bash
sudo mkdir -p /etc/powerdns/zones
sudo tee /etc/powerdns/zones/example.com.zone <<'EOF'
$ORIGIN example.com.
$TTL 300
@   IN  SOA ns1.example.com. hostmaster.example.com. (
        2026070801 ; serial
        3600       ; refresh
        600        ; retry
        86400      ; expire
        300 )      ; minimum
    IN  NS  ns1.example.com.
ns1 IN  A   203.0.113.50
www IN  A   203.0.113.50
EOF

Replace example.com and the A records with your domain and floating IP. Bump the SOA serial when you edit the zone.

Validate and restart:

bash
sudo pdnsutil check-zone example.com
sudo systemctl restart pdns
sudo systemctl enable pdns

Verify PowerDNS listens on port 53:

bash
sudo ss -lunp | grep ':53'
dig @127.0.0.1 www.example.com +short

The dig command should print the A record you defined.

Test the REST API over SSH#

From your workstation, forward local port 8081 to the instance:

bash
ssh -i ~/.ssh/MY_KEYPAIR -L 8081:127.0.0.1:8081 ubuntu@FLOATING_IP_ADDRESS

In another terminal:

bash
curl -s -H "X-API-Key: API_KEY" http://127.0.0.1:8081/api/v1/servers/localhost/zones

The response lists the example.com zone. Use the API for dynamic record changes; zone files remain the bootstrap path in this guide.

Delegate the zone at your registrar#

At your registrar, point the domain's authoritative nameservers at the hostnames PowerDNS publishes (for example ns1.example.com). Add glue records (nameserver hostname to IPv4 address) when the registrar requires them.

Registrar taskTypical fieldValue
Nameserver 1Hostnamens1.example.com
Glue / child nameserverIPv4Your Quake AI floating IP
Optional nameserver 2HostnameA second instance if you run HA later

Provider UIs differ. Use their nameserver or custom DNS documentation:

ProviderDelegation documentation
CloudflareChange nameservers
NamecheapCustom DNS
GoDaddyEdit nameservers
GandiExternal nameservers

Delegation can take up to 48 hours to propagate globally. TTL on the previous NS set controls how long resolvers cache the old delegation.

Verify public resolution#

Query from your workstation against a public resolver:

bash
dig +trace www.example.com A

The trace should end at your floating IP for the www A record.

Query the authoritative server directly:

bash
dig @FLOATING_IP_ADDRESS www.example.com A +short

Send HTTP to a host you published once records resolve:

bash
curl -I http://www.example.com

If resolution fails, confirm the floating IP is associated, dns-sg allows UDP/TCP 53, and the registrar glue records match the floating IP.

CoreDNS for Kubernetes service discovery#

When the goal is internal name resolution inside a cluster rather than public authoritative DNS, run CoreDNS on Kubernetes. Magnum clusters ship CoreDNS as the in-cluster resolver. For a custom Corefile on Quake AI compute outside Magnum, install the binary on an instance and point upstream to your PowerDNS host or to a public resolver.

Example stub zone forwarding to your PowerDNS instance:

example.com:53 {
    forward . FLOATING_IP_ADDRESS
}
log

Deploy CoreDNS with the DaemonSet or systemd unit pattern your orchestrator uses. Public delegation still flows through PowerDNS (or another authoritative server), not through cluster DNS.

See also#

Usage Guidelines

The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.

For the full policy, see Usage Guidelines.

Last validated: 10.07.2026

Was this page helpful?