DNS and certificates

Frazer DNS serves your domains and the names inside your networks through one API. Public zones are answered by Frazer’s own name servers on three networks and by two anycast providers, all serving the same signed zone, and they keep answering when the Frazer API is down. Every change is atomic and shown as a plan first, records can follow a Frazer resource instead of a typed address, and DNSSEC is one switch. Gateways get their certificates over DNS-01, whether your domain is on Frazer DNS or not.

Product overview: DNS and certificates.

How it works

A zone belongs to a project and is global. When you write a change, Frazer stores it with a new serial in one transaction, a hidden signer signs the zone, and every name server pulls the signed copy. Name servers serve copies and never call the control plane, so an API outage only delays changes. No DNSSEC key is ever on a public name server.

Name servers have names under frazerdns.net and frazerdns.dev, never under frazer.ai, and every set of name servers mixes both domains. Frazer assigns a zone its set; you do not choose it. A new zone never gets the set that a parent already delegates to for the same name unless the domain is verified, which stops anyone from claiming a domain they do not own.

• Managed zone: a public or private zone in a project, such as apps.acme.example..
• Record set: the records for one name and type. Its ID is {relative_name}~{TYPE}: www~A, or @~MX at the apex.
• Change: additions and deletions applied together or not at all. One change is one serial and one revision.
• Revision: the full content of a zone at one serial. Any revision can be restored.
• Verified domain: your organization’s proof that it owns a domain, with an optional hold.
• Resource-bound record: a record set whose target is a Frazer address, load balancer, gateway, endpoint or database endpoint. It answers with the resource’s current addresses.
• Health check: a probe that routing policies use to answer only with healthy addresses.

Zone state	Meaning	Answers queries
PENDING_DELEGATION	Created with its name servers; the parent does not point at them yet	Yes, on its own name servers
PENDING_VERIFICATION	The parent already delegates to Frazer, but nobody has proved ownership of the domain	No, until verified
ACTIVE	The parent’s NS records match the zone’s name servers	Yes
MOVED	The parent stopped delegating to Frazer; the owners are warned	Yes
Deleted	Kept for 30 days and can be undeleted	No

A change moves from PENDING (stored with its serial) to APPLIED (signed and validated) to SERVING: every public name-server address answers the new serial, checked from at least three places. If the signer’s validation refuses a serial, the change is FAILED with the reason, and the zone keeps its previous content.

Create a zone

First verify your domain, once for the organization. It needs roles/dns.domainOwner:

frazer dns verified-domains create acme.example --organization acme --hold domain-and-subdomains

Prove ownership with a TXT record at _frazer-verify.acme.example, or with an existing delegation to one of your organization’s zones. The hold stops other organizations from creating zones for the domain and everything below it; domain covers the name only. Share the verified domain with every project of the organization or with chosen projects. The same verification also serves the sign-in domain check for single sign-on.

CLI

1. Create the zone and read its plan:

   frazer dns managed-zones create apps --dns-name apps.acme.example. --dnssec \
       --project acme-production --dry-run

   The plan shows the name servers assigned to the zone, its SOA and the DS record to publish. Run the command again without --dry-run to create the zone.

2. Add records:

   # A record with plain values
   frazer dns record-sets create www~A --zone apps --rrdatas 203.0.113.10 --ttl 300
   
   # A record that follows the addresses of a resource
   frazer dns record-sets create @~A --zone apps \
       --target projects/acme-production/locations/us-virginia1/addresses/web

   The second record answers A and AAAA from the address’s current values, at the apex too. If the address is deleted, the record answers empty and a finding is raised, so no record is left pointing at an address someone else may get.

3. Check what the parent publishes today:

   frazer dns managed-zones check-delegation apps

   Add NS records for apps.acme.example in the parent zone, using the names the zone was assigned. The zone turns ACTIVE when the parent’s NS records match; until then, zone owners get a reminder email.

4. Wait until a change is served everywhere:

   frazer dns changes get 42 --zone apps --wait

   --wait returns when the change is SERVING. Resolvers that cached the old answer keep it until its TTL ends.

Terraform

1. Describe the zone and its records:

   dns.tf

   resource "frazer_dns_managed_zone" "apps" {
     project  = "acme-production"
     name     = "apps"
     dns_name = "apps.acme.example."
     dnssec { state = "ON" }
   }
   
   resource "frazer_dns_record_set" "www" {
     managed_zone = frazer_dns_managed_zone.apps.id
     name         = "www"
     type         = "A"
     ttl_seconds  = 300
     rrdatas      = ["203.0.113.10"]
   }

2. Run terraform plan or tofu plan. The plan shows the record diff, lint findings and quota impact.

3. Apply it, then delegate the zone: run frazer dns managed-zones check-delegation apps and add the assigned NS records in the parent zone.

Console

1. Open the project, then Network › DNS › Zones, and create a zone: its DNS name, type, DNSSEC and query logging. The plan shows the assigned name servers and SOA, with the equivalent CLI, API and YAML.

2. On the zone’s Records tab, add record sets: values or a target resource, with the change previewed before it applies.

3. On the Name servers tab, compare the NS records at the parent with the assigned set, add them at the parent, and use Check now.

4. On the Activity tab, follow each change until every name server serves it.

Change records

Group related edits into one change. A dry run prints the plan: the record diff, lint findings, quota impact, conflicts with records that a controller owns, and whether an approval is needed.

frazer dns changes create --zone apps --from-file change.yaml --dry-run

• Preconditions. A change carries the zone’s etag, and each record set its own. If someone changed the zone since you read it, the change is refused; read it again and plan again. A deletion must match the stored data exactly.
• Retries. A request ID makes a retried write return the first result instead of applying twice.
• Records owned by controllers. Gateways, routes, the cluster’s DNS controller and its certificate manager mark the records they write. A person’s edit to one is refused unless forced, and the controller restores its records.
• Lint. Every plan flags a CNAME at the apex or next to other data, a DS without a matching DNSKEY in the child, a TTL over 3 days in a signed zone, an MX that points at a CNAME, an SPF record over 10 lookups, and a CNAME to an outside name that nobody has claimed.
• Undo. frazer dns managed-zones restore apps --revision 41 --dry-run returns the zone to revision 41 as a new change. A deleted zone comes back with undelete within 30 days.

Record types. A, AAAA, CNAME, MX, TXT, SRV, CAA, PTR, NS (for delegations), HTTPS, SVCB, DS, TLSA, SSHFP and NAPTR. Wildcards work for every type except NS. A CNAME is never at the apex or next to other data; to point the apex at an outside name, use flattening, which answers with the addresses at the end of the chain. Frazer manages the SOA and the apex NS records; you can change the SOA timers. Internationalized names are stored as A-labels and shown as U-labels.

Failover and routing policies

A record set holds values, a target, or a routing policy with a health check.

Policy	What it answers
Failover	The primary addresses, or the backup when the primary’s check fails
Multi-value	Only the addresses whose checks pass
Weighted	Each address in proportion to its weight
Geolocation	The nearest match to the client, with an optional geofence
Latency	The address with the lowest latency for the client

Weighted, geolocation and latency answers come from Frazer’s own name servers only, not from the anycast providers.

A health check probes over TCP, HTTP or HTTPS, with a port, a path and an optional content match, from at least three locations. By default it probes every 5 seconds from 3 locations, marks a target unhealthy after 3 failures seen from at least 2 locations, and healthy again after 30 seconds of passing. If more than 30 % of all checks fail at once, Frazer freezes failover instead of moving traffic, because that pattern means the probes are failing, not your targets. A failing check emails the owners of the record sets that use it.

Turn on DNSSEC

Pass --dnssec when you create a zone, or turn on the switch on an existing zone. The zone goes from off to signing, then to DS published, then to secure.

Setting	Default
Cost	No extra charge, on every zone. The plan shows the DS record to publish.
Keys	Algorithm 13 (ECDSA P-256) only, with a key-signing key and a zone-signing key. Keys live on a hidden signer, never on a public name server.
Denial of existence	NSEC3 with no extra iterations and no salt, with real NXDOMAIN answers. Plain NSEC on request.
Key rolls	The zone-signing key rolls every 30 days. The key-signing key rolls by itself where the parent reads CDS; elsewhere a guided roll waits until the new DS is seen.
DS at the parent	CDS and CDNSKEY on every zone, the same on every server. Kept in sync when the parent zone is on Frazer too.
Signatures	Valid 14 days, refreshed 7 days ahead. A name server cut off from updates stops answering after 6 days, before any signature it holds expires.
Validation	Every zone is checked on every name-server address, and the console shows the result per server.

Publishing the DS. Where the parent reads CDS records, or the parent zone is on Frazer, the DS is published for you. For a new signed zone whose parent supports RFC 9615 bootstrapping, Frazer publishes the signals the parent needs. Otherwise the console shows the exact DS record to paste at your registrar, and zone owners get an email if it does not appear. A key-signing key roll that needs a registrar step emails them as well. To start a roll yourself:

frazer dns managed-zones rotate-key-signing-key apps

Caution

Turning DNSSEC off is guarded. The DS record comes off the parent first, Frazer waits for its TTL, and only then is the zone unsigned. It needs a plan and an approval, because a DS left at the parent makes validating resolvers fail.

Move a zone to Frazer

1. At your current provider, lower the zone’s TTLs one TTL period before the move.

2. Import the zone file as one change and read the plan. The parse report lists unsupported record types and the SOA and apex NS records that Frazer replaces.

   frazer dns managed-zones import-records apps --bind-file apps.zone --dry-run

3. Run the import without --dry-run. A file larger than one change still lands as one serial.

4. Run frazer dns managed-zones check-delegation apps, then change the name servers at your registrar to the ones the zone was assigned.

5. Watch the zone go from PENDING_DELEGATION to ACTIVE.

A signed zone can move in without an insecure window, through the TRANSFER DNSSEC state, when your current provider supports multi-signer DNSSEC. Export any zone at any time:

frazer dns managed-zones export-records apps --format yaml > apps.yaml

Resource-bound records and routing policies export to YAML only, because BIND cannot represent them.

Issue certificates for your domains

Gateways get a wildcard certificate per listener from the cluster’s certificate manager over DNS-01. Pick how your domain’s records are kept; every way includes certificates.

Way	Records	Certificates
Delegate a subdomain to Frazer	Frazer keeps the records for your gateways and routes, bound to the resources they name.	DNS-01 inside the zone, through the certificate manager’s DNS webhook. Its role can write only _acme-challenge TXT records.
Keep your DNS provider	The cluster’s DNS controller writes them at your provider with your token, kept in your project’s secrets and limited to one zone.	DNS-01 at your provider.
Manage records yourself	The console shows the exact A, AAAA or CNAME records to add wherever your zone lives.	One _acme-challenge CNAME into Frazer’s challenge zone, once. No provider token.

In a Frazer zone, the DNS controller and the certificate manager’s webhook use the cluster’s workload identity, so no token is stored. The DNS controller gets roles/dns.recordEditor on one zone and marks the records it writes; the certificate solver gets roles/dns.acmeSolver, so a leaked token can only answer challenges.

• Every gateway also gets a default hostname under frazer.run, a domain kept apart from frazer.ai, with a wildcard certificate.
• A public ACME certificate authority is the default issuer. If it is down, issuance falls back to a second ACME authority.
• A failed renewal or a certificate close to expiry emails the project’s admins.

Gateways and listeners: Load balancers.

Private names and zones

Each network has a resolver at every subnet’s .2 address, at each site. It answers automatic names, A and AAAA, for VMs ({vm}.{subnet}.{network}.{project}.internal), databases ({db}.db.{project}.internal), endpoints and load balancers, and resolves internet names with DNSSEC validation. It keeps its last good copy on disk, so a control-plane outage changes nothing it answers.

Queries are answered in this order: response policies, then private, forwarding and peering zones (the longest suffix wins), then automatic .internal names, then public DNS. A server policy with alternative name servers replaces the order.

# A private zone that networks see
frazer dns managed-zones create corp --private --dns-name corp.acme.example. --networks main

# Let your on-premises resolvers query the network's resolver
frazer dns server-policies create main --networks main --inbound-forwarding

• Forwarding zones send a suffix to your own resolvers, over the network’s VPN or VLAN attachment.
• Peering zones answer from another network’s view.
• Response policies answer a name with local data, or with NXDOMAIN, NODATA or PASSTHROUGH.
• Laptops on Frazer Access resolve .internal names through the network’s VPC attachment: Frazer Access and VPN.

Binding a private zone or a policy to a network needs network.networks.use on that network.

Access and audit

Role	What it allows
roles/dns.viewer	Read every zone, record set, change and key, analytics included. Agents get this role and may run dry runs.
roles/dns.recordEditor	Edit record sets and changes in the zones it is granted on. No zone create or delete, no DNSSEC changes.
roles/dns.admin	Everything in DNS except verified domains.
roles/dns.acmeSolver	Only _acme-challenge TXT records, for the certificate solver.
roles/dns.domainOwner	Verified domains, at the organization.

A grant on record sets can carry a condition on the record’s name and type, so a team edits only its own names.

• Approvals. An agent can prepare a plan but never apply it alone: its writes go through an approval. Production projects follow the four-eyes rule.
• Audit. Every write, zone changes included, is recorded in the audit log with its plan diff and who made it. Every change is a revision with its author, its time and the time every name server served it.
• Email alerts. Zone owners hear about a delegation that is still pending, a missing DS record, records that drifted and a key-signing key roll that needs a registrar step. The owners of record sets hear when a health check they use fails.
• Findings. Lame delegations, DS mismatches, CDS that differs between servers, a key-signing key roll that is due, records left pointing at a deleted resource, and CNAMEs to outside names nobody has claimed.
• Queries. Query analytics (by name, type, response code and site) are in the console. Query logs are opt-in: public zones sample 1 % by default and 100 % on request; private zones log every query.

Limits and quotas

Limit	Default
Zones per project	1,000
Record sets per zone	10,000
Records per record set	1,000
One change	1,000 additions, 1,000 deletions, 1 MiB
DNS writes per project	600 a minute
New zones per project	100 a day
Verified domains per organization	100
Health checks per project	100
Private zones per network	1,000
Rules per response policy	10,000
Forwarding targets per zone or policy	50
Resolver queries per network per site	100,000 per 10 seconds
Public queries	No quota
Deleted zones kept	30 days

Quotas are never zero. A request over a quota is refused with QUOTA_EXCEEDED, and a write over a rate with RATE_LIMITED: errors.

Pricing

Each server you pay for includes an allowance of zones and queries. Above it, zones are billed per zone-month and queries per million. DNSSEC, CDS automation, verified domains, query analytics and certificates are always included, queries dropped as an attack are never billed, and opt-in query logs are billed as logs.

DNS and certificates	On your servers	On the Frazer fleet
Price	Included: 25 zones and 25 million queries a month per server, pooled	Above that: $0.10 per zone / month ($0.02 above 10,000) · $0.20 per million queries ($0.10 above a billion a month) · routing policies $0.40 per million

Every line, with the estimator: pricing.

Troubleshooting

Symptom	Cause	Fix
A zone stays PENDING_DELEGATION	The parent does not point at the zone’s name servers	Run check-delegation and set exactly the assigned names at the parent or your registrar.
A zone is PENDING_VERIFICATION and answers nothing	The parent already delegates to Frazer, but your organization has not proved ownership	Verify the domain with the _frazer-verify TXT record.
A signed zone never turns secure	The DS record is missing at the parent, and the parent does not read CDS	Paste the DS record from the zone’s DNSSEC tab at your registrar.
A change is refused with an etag conflict	Someone changed the zone or the record set after you read it	Read the current data, plan again, and apply.
An edit to a record is refused	A controller (a gateway, a route, the DNS controller or the certificate manager) owns the record	Change the source, such as the route in Git, or force the edit; the controller restores its own records.
A record answers empty	The resource it targets was deleted	Point the record at a new resource, or delete it. The zone’s findings list every such record.
A change is FAILED	The signer’s validation refused the new serial	Read the reason on the change, fix the records and send a new change. The zone keeps serving its previous content.
QUOTA_EXCEEDED or RATE_LIMITED	A zone, record or write quota is reached	Delete what you no longer use or request more; for rates, retry after the delay and batch edits into one change.

Reference

CLI

Command	What it does
frazer dns verified-domains create	Prove that your organization owns a domain, optionally with a hold against other organizations.
frazer dns managed-zones create	Create a public or private zone.
frazer dns managed-zones check-delegation	Show the NS and DS records at the parent, lame servers, CDS state and the serial on every name server.
frazer dns managed-zones verify	Run the ownership check for a zone.
frazer dns managed-zones import-records	Import a BIND zone file or YAML as one change.
frazer dns managed-zones export-records	Export a zone as BIND or YAML.
frazer dns managed-zones restore	Return a zone to an earlier revision, as a new change.
frazer dns managed-zones undelete	Bring back a zone deleted in the last 30 days.
frazer dns managed-zones rotate-key-signing-key	Start a roll of the zone's DNSSEC key-signing key.
frazer dns record-sets create	Create a record set, with values or with a Frazer resource as its target.
frazer dns changes create	Apply additions and deletions from a file as one atomic change.
frazer dns changes get	Show a change; with --wait, return when every name server serves it.
frazer dns server-policies create	Set resolver options, such as inbound forwarding, for networks.

All of them: CLI reference.

Terraform and OpenTofu

Resource	What it manages
frazer_dns_managed_zone	A public or private zone, with its DNSSEC settings.
frazer_dns_record_set	A record set in a zone.
frazer_dns_verified_domain	A domain your organization has proved it owns.
frazer_dns_server_policy	Resolver options for networks, such as inbound forwarding.
frazer_dns_response_policy	A response policy bound to networks.
frazer_dns_response_policy_rule	A rule of a response policy.
frazer_dns_tsig_key	A TSIG key for zone transfers; the secret is write-only.
frazer_network_health_check	A health check used by DNS routing policies and load balancers.

All of them: Terraform and OpenTofu reference.

Related

• Load balancers: gateways that write their own records and certificates.
• VPC and firewall: networks, their resolvers and addresses.
• Frazer Access and VPN: private names from a laptop.
• Terraform and OpenTofu: manage zones and records as code.
• Identity and access: the roles, conditions and approvals behind DNS writes.
• DNS and certificates: the product page.