How to self-host authoritative DNS on Quake AI
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
- ConsoleLogged in to the Quake AI console
- CLIOpenStack CLI installed and authenticated (
clouds.yamloropenrcsourced)
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 buildsmy-private-netif you need one)
Choose authoritative software#
| Software | Best for | Notes |
|---|---|---|
| PowerDNS Authoritative | General authoritative DNS with a REST API and optional SQL backends | Lead path in this guide |
| CoreDNS | In-cluster service discovery on Kubernetes | Run 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:
ssh -i ~/.ssh/MY_KEYPAIR ubuntu@FLOATING_IP_ADDRESSInstall PowerDNS#
On the instance:
sudo apt update
sudo apt install -y pdns-server pdns-backend-bindGenerate an API key:
API_KEY=$(openssl rand -hex 16)
echo "API_KEY=$API_KEY"Edit /etc/powerdns/pdns.conf and set:
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.1Create /etc/powerdns/named.conf:
zone "example.com" {
type master;
file "/etc/powerdns/zones/example.com.zone";
};Create the zone directory and file:
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
EOFReplace example.com and the A records with your domain and floating IP. Bump the SOA serial when you edit the zone.
Validate and restart:
sudo pdnsutil check-zone example.com
sudo systemctl restart pdns
sudo systemctl enable pdnsVerify PowerDNS listens on port 53:
sudo ss -lunp | grep ':53'
dig @127.0.0.1 www.example.com +shortThe 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:
ssh -i ~/.ssh/MY_KEYPAIR -L 8081:127.0.0.1:8081 ubuntu@FLOATING_IP_ADDRESSIn another terminal:
curl -s -H "X-API-Key: API_KEY" http://127.0.0.1:8081/api/v1/servers/localhost/zonesThe 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 task | Typical field | Value |
|---|---|---|
| Nameserver 1 | Hostname | ns1.example.com |
| Glue / child nameserver | IPv4 | Your Quake AI floating IP |
| Optional nameserver 2 | Hostname | A second instance if you run HA later |
Provider UIs differ. Use their nameserver or custom DNS documentation:
| Provider | Delegation documentation |
|---|---|
| Cloudflare | Change nameservers |
| Namecheap | Custom DNS |
| GoDaddy | Edit nameservers |
| Gandi | External 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:
dig +trace www.example.com AThe trace should end at your floating IP for the www A record.
Query the authoritative server directly:
dig @FLOATING_IP_ADDRESS www.example.com A +shortSend HTTP to a host you published once records resolve:
curl -I http://www.example.comIf 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
}
logDeploy 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#
- How to point a domain at a Quake AI resource: registrar
A/CNAMErecords toward a Quake AI address - How to allocate floating IP addresses
- How to put a CDN in front of a Quake AI workload
- How to issue and auto-renew a TLS certificate with Let's Encrypt
- Self-hosted vibecode stack: perimeter comparison including managed DNS alternatives
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