← All help articles

DNS technical reference

Updated October 25, 2026

This page is for whoever manages DNS for a domain moving to Guardhouse. Owner-friendly guides are under Pointing your domain.

Guardhouse sites are served through Cloudflare for SaaS custom hostnames. The values below are placeholders until the platform setup is complete.

Summary of changes

Record Name Value
CNAME www sites.guardhouse.host
TXT (hostname ownership) _cf-custom-hostname.www.<domain> Provided per hostname by Guardhouse
TXT (certificate validation) _acme-challenge.www.<domain> Provided per hostname by Guardhouse
Root domain @ Forward to https://www.<domain>, or ALIAS/ANAME/flattened CNAME where supported (see below)

Nothing else changes. In particular:

  • Leave MX, SPF, DKIM, and DMARC records as they are. Email is not affected.
  • Do not add A or AAAA records at the root for Guardhouse. We do not support A records at the root yet.

Pre-validation (zero-downtime cutover)

If the CNAME is switched first and certificates are issued afterward, visitors can briefly see certificate errors. To avoid that, Guardhouse validates the hostname and issues the certificate before you change the www CNAME.

Guardhouse creates the custom hostname and sends you two TXT records, both for the www hostname:

  1. Hostname ownership. Name _cf-custom-hostname.www.<domain>, with a value Cloudflare generates. This proves the hostname is yours and lets it become active before cutover. Cloudflare says you can remove this record once the hostname is active.
  2. Certificate validation. Name _acme-challenge.www.<domain>, with a value Cloudflare generates. This lets the TLS certificate be issued before cutover. Cloudflare says validation and issuance then complete automatically.

The two tokens are different. Completing one does not complete the other.

Sequence:

  1. Guardhouse creates the custom hostname and sends the TXT values.
  2. You add both TXT records. Nothing changes for visitors.
  3. Guardhouse confirms that the hostname status and certificate status are both active.
  4. At the agreed time, you change the www CNAME to sites.guardhouse.host.
  5. Guardhouse verifies HTTPS on the hostname.

Cloudflare documents this approach in:

Cloudflare’s other validation methods include HTTP validation (a token served at /.well-known/cf-custom-hostname-challenge/ for ownership) and Delegated DCV. Guardhouse uses TXT by default.

Tokens expire. If cutover is delayed, Guardhouse can issue new ones.

Root domain

The CNAME applies to www. A CNAME cannot normally coexist with other records at the root, and most registrars do not allow one there. Two options:

  1. Forward the root to https://www.<domain> at the registrar, as a permanent (301) redirect. Most registrars offer this. Check that the forward works for https://<domain> too, not just http://. Some forwarding services do not serve HTTPS.
  2. ALIAS, ANAME, or CNAME flattening where your DNS provider supports it. The root name points at sites.guardhouse.host. Cloudflare DNS, for example, flattens CNAMEs at the apex. See CNAME flattening.

Cloudflare for SaaS does not support pointing an A record at the target by default (see Configuring Cloudflare for SaaS), so we do not use A records at the root.

If you use an ALIAS or flattened root, the root hostname also needs its own custom hostname and its own pair of TXT records. Tell Guardhouse which option you chose.

CAA records

If your domain has CAA records, they must permit the certificate authorities Cloudflare uses. If the domain has no CAA records, there is nothing to do.

Cloudflare’s certificate authorities page lists these CAA values (tag issue):

Certificate authority CAA value
Let’s Encrypt letsencrypt.org
Google Trust Services pki.goog; cansignhttpexchanges=yes
SSL.com ssl.com
Sectigo sectigo.com

Example:

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issue "pki.goog; cansignhttpexchanges=yes"
example.com.  CAA  0 issue "ssl.com"
example.com.  CAA  0 issue "sectigo.com"

Which authority issues a given certificate can change. Allow all four unless Guardhouse tells you a narrower list.

Cloudflare checks CAA records before it requests a certificate for a hostname when the CA is left to the default.

Before cutover

  • Lower the TTL a day ahead. Set the TTL of the existing www record (and the root record, if you will change it) to 300 seconds, at least 24 hours before the change. Wait for the old TTL to expire before you cut over.
  • Note the current values of every record you will change (take a screenshot or an export). You will need them to roll back.
  • If you use DNSSEC, check that your provider supports the record types you are adding.

Cutover checklist

  1. TXT records added and confirmed active by Guardhouse.
  2. Change the www CNAME to sites.guardhouse.host.
  3. Set up the root forward or ALIAS.
  4. Leave MX, SPF, DKIM, DMARC, and other TXT records alone.
  5. Verify: dig +short CNAME www.<domain>, then load https://www.<domain> and https://<domain>.
  6. After the hostname is active, the ownership TXT record (_cf-custom-hostname) can be removed. Keep the www CNAME in place for as long as the site is hosted with Guardhouse.

Rollback

If anything looks wrong:

  1. Restore the previous www record exactly as you noted it (the old CNAME, or the old A records).
  2. Remove or restore the root forward or ALIAS to its previous state.
  3. Because the TTL was lowered, resolvers should return to the old values within minutes.
  4. Tell Guardhouse so we can pause go-live. The TXT records can stay in place. They do no harm and let us try again.

Leaving the old site up until the new one is confirmed is what makes this safe. Guardhouse does not ask you to cancel hosting at your old provider until after go-live.

Questions

Email hello@useguardhouse.com.

← Back to all help articles