Registrar-specific operator guide. This is one of several per-registrar walkthroughs for the spec's §5.1.1 SVCB MUST. The spec is normative; this guide is descriptive. If your registrar isn't Squarespace, the wire-format target (_webgcp.<host>. SVCB 1 <host>.) is the same — just the UI clicks differ.

Adding the SVCB record at Squarespace Domains¶

Audience: registrar holder of any domain registered through Squarespace Domains who needs to satisfy the webGCP v0.1 §5.1.1 DNS-layer discovery MUST.

Time: 5–10 min if Squarespace's UI supports SVCB directly. 30–60 min if you need to migrate DNS to a provider that does.

What you're adding, in one line:

_webgcp.<your-domain>.   3600   IN   SVCB   1   <your-domain>.

For webgcp.org specifically, that becomes:

_webgcp.webgcp.org.      3600   IN   SVCB   1   webgcp.org.

That's the entire record. Priority 1 (ServiceMode), TargetName = the domain itself, no SvcParams. Spec §5.1.1 explains what each field means and why.

Step 1 — Open Squarespace Domains DNS¶

For webgcp.org:

Sign in to Squarespace
Open https://account.squarespace.com/domains/managed/webgcp.org/dns/dns-settings
Scroll to Custom Records (Squarespace's section name; sometimes labeled "Manage Custom Records")

For other domains, replace webgcp.org in that URL.

Step 2 — Add the record¶

Click Add Record. Squarespace will show a row with these fields:

Field	Value
Host	`_webgcp` (no domain suffix; Squarespace appends it automatically)
Type	`SVCB` — pick from the dropdown
Data	`1 webgcp.org.` — note the trailing dot
Priority	(this field appears for some types; leave blank or `1` if forced)
TTL	`3600` (or whatever default Squarespace uses, e.g., 14400)

Save.

If the Type dropdown doesn't contain SVCB (TYPE 64), see "Fallbacks" below.

Worked example — `webgcp.org` (verified 2026-05-16)¶

Squarespace field	Value entered
Host	`_webgcp`
Type	(whatever the Squarespace dropdown surfaced — see fallbacks if SVCB isn't there)
Priority	left blank / `N/A` (Squarespace may show a Priority field, but it's not used for SVCB at v0.1 — the priority is embedded in the Data field's first token)
Data	`1 webgcp.org.`
TTL	4 hours (= 14400 s)

Squarespace stored this as an RFC 3597 generic-format record rather than a typed SVCB record. That's wire-equivalent and correct. DoH resolvers render it back as:

\# 14 00 01 06 77 65 62 67 63 70 03 6f 72 67 00

Decoding those 14 bytes:

Bytes	Hex	Meaning
0–1	`00 01`	SvcPriority = 1 (ServiceMode ✓ — not AliasMode)
2	`06`	label length 6
3–8	`77 65 62 67 63 70`	`"webgcp"`
9	`03`	label length 3
10–12	`6f 72 67`	`"org"`
13	`00`	name terminator

All 9 WGCP-L0-003 fixture assertions pass against this record (verified via Cloudflare DoH 2026-05-16).

Why Squarespace stores it as generic rather than typed: Squarespace's DNS UI doesn't have first-class SVCB rendering as of 2026-05; it accepts the BIND-format string you type and converts it to RFC 3597 wire bytes for storage. Any compliant resolver — Cloudflare, Google, your own — parses generic records back to SVCB identically. There's no functional difference.

Step 3 — Verify (any time after ~5 min for propagation)¶

DNS-over-HTTPS works from any machine without local dig / nslookup tooling. Pick one of these:

# Cloudflare DoH (recommended — they're consistently fast on SVCB)
curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=_webgcp.webgcp.org&type=64' | jq

# Google DoH (cross-check)
curl -s 'https://dns.google/resolve?name=_webgcp.webgcp.org&type=64' | jq

Expected response shape — two equivalent forms, either is correct:

Typed SVCB representation (some DoH endpoints render this):

{
  "Status": 0,
  "Answer": [
    {"name": "_webgcp.webgcp.org.", "type": 64, "TTL": 3600, "data": "1 webgcp.org."}
  ]
}

RFC 3597 generic-record representation (what Cloudflare's DoH JSON typically returns, and what Squarespace's UI stores under the hood):

{
  "Status": 0,
  "Answer": [
    {"name": "_webgcp.webgcp.org.", "type": 64, "TTL": 14400, "data": "\\# 14 00 01 06 77 65 62 67 63 70 03 6f 72 67 00"}
  ]
}

Both are wire-equivalent. Any compliant resolver parses them identically. Do not treat the \\# rendering as an error — RFC 3597 specifies it as "this is rdata for a record type the renderer doesn't have specific support for; here are the raw bytes."

Common signals:

Status: 0 means NOERROR — the record exists.
type: 64 confirms it's SVCB (TYPE 64; HTTPS RRs would be TYPE 65, which is wrong for this use).
data either starts with 1 (BIND form, priority 1) OR with \\# 14 00 01 (generic form, length 14 bytes, priority 0x0001 = 1). Anything else is a misconfiguration.

If Answer is missing or empty: the record hasn't propagated yet, or Squarespace didn't save it. Wait 10 more minutes, then re-check. Google DoH may sometimes return an empty Answer for SVCB even when Cloudflare returns the record correctly — use Cloudflare as the primary verifier.

After verification, run the L0-003 fixture (live test):

curl -s https://webgcp.org/conformance/v0.1/WGCP-L0-003.json | jq '.assertions[].id'
# Lists the 7 positive assertions you should be able to verify against your host

Fallbacks if Squarespace's DNS UI doesn't support SVCB¶

Squarespace Domains' DNS UI has historically been conservative — A, AAAA, CNAME, MX, TXT, SRV, CAA, NS, ALIAS. SVCB / HTTPS (RFC 9460 record types from 2023) may or may not be in the dropdown depending on when you check; Squarespace adds record types over time but lags behind Cloudflare / Google Cloud DNS.

Option A — Try a generic / numeric type entry first.

Squarespace sometimes exposes "TYPE64" or "Custom" as a Type option even when "SVCB" isn't named. The Data field would then need RFC 3597 generic record syntax instead of BIND format. Compute the raw rdata:

For _webgcp.webgcp.org. SVCB 1 webgcp.org.:

\# 14 000106776562676370036F726700

Breakdown of those 14 bytes: - 0001 — Priority = 1 (uint16, big-endian) - 06 — label length 6 - 776562676370 — "webgcp" in ASCII - 03 — label length 3 - 6F7267 — "org" in ASCII - 00 — name terminator

If Squarespace accepts the raw form, paste that string verbatim into the Data field. Some UIs strip the \# prefix; try with and without.

Option B (recommended if A fails) — migrate DNS to Cloudflare.

Cloudflare supports SVCB natively + you keep the domain registered at Squarespace. Roughly 30 min:

Create a free Cloudflare account → Add a Site → enter webgcp.org
Cloudflare scans existing DNS records (A, TXT, etc.) and offers to import them. Accept.
Cloudflare displays its two nameservers — copy them, they look like dana.ns.cloudflare.com / walt.ns.cloudflare.com (the names vary per account).
Back at https://account.squarespace.com/domains/managed/webgcp.org → Nameservers → switch from "Squarespace Managed Nameservers" to "Custom Nameservers" → paste the two Cloudflare nameservers.
Save. Nameserver propagation takes 1–24 h (usually <1 h).
Once Cloudflare shows the zone as Active, add the SVCB record: - DNS → Records → Add record → Type: SVCB → Name: _webgcp → Priority: 1 → Target: webgcp.org → Save.
Verify with the DoH commands in Step 3.

This is the path most protocol-spec sites end up on (it's why so many .well-known/* sites list Cloudflare in their stack).

Option C — drop the spec MUST to SHOULD for v0.1.

This requires no DNS work; it's a spec-side fix. If the SVCB hard gate is blocking, you can ask me to edit §5.1.1 from MUST to SHOULD with an explicit note that v0.2 will tighten back to MUST once the registrar/DNS ecosystem catches up. Trade-off: weaker L0 conformance until v0.2.

Troubleshooting¶

The record saved but doesn't show in DoH after 30 min. - Check whether Squarespace's UI requires the Host field to include the parent domain (some UIs want _webgcp.webgcp.org and others want just _webgcp). If you used the short form and DoH returns NXDOMAIN, try editing the record to use the FQDN. - Try Google DoH and Cloudflare DoH side-by-side. Different resolvers may have different propagation lag. - Squarespace's DNS edits sometimes take 1–4 hours despite the TTL field saying otherwise.

DoH returns data: "1 webgcp.org." correctly, but the WGCP-L0-003 fixture still fails. - The fixture's step 2 fetches /.well-known/webgcp on the TargetName. Confirm that's reachable: curl -sI https://webgcp.org/.well-known/webgcp | grep -i content-type — expects application/json. - If the descriptor returns the wrong shape (no spec_version field, etc.), the failure is at the descriptor layer, not the DNS layer.

Squarespace forces a Priority field separate from Data. - Squarespace's SVCB form may split SvcPriority and TargetName into separate columns. Use: - Priority: 1 - Target: webgcp.org. (or webgcp.org if Squarespace strips the trailing dot) - Leave any "SvcParams" / "Params" field empty.

Multiple SVCB records returned by DoH. - Per RFC 9460 §2.4, multiple SVCB records at the same name are valid and represent ordered preference (lower SvcPriority first). For webGCP v0.1, one record is enough. If you see multiple, check whether you accidentally saved twice; delete duplicates.

SVCB record exists but TYPE shows as 65 (HTTPS), not 64 (SVCB). - HTTPS RRs (TYPE 65) and SVCB RRs (TYPE 64) are distinct. The HTTPS RR is for the https:// scheme specifically; SVCB is the generic form. Spec §5.1.1 requires SVCB (TYPE 64). If your registrar accidentally created an HTTPS RR, delete it and create the correct SVCB type.

Cloudflare DoH returns \# 14 00 01 06 ... instead of 1 webgcp.org.. - That's RFC 3597 generic-record syntax — wire-equivalent to BIND-style representation. Cloudflare's DoH JSON renders SVCB this way when the upstream authoritative zone stores it as a generic record (common with Squarespace's UI, since Squarespace doesn't ship first-class SVCB rendering in its DNS edit UI). The bytes after \# 14 decode to priority(2) + target_name(12) for 1 webgcp.org.. No action needed; this is correct behavior. WGCP-L0-003 fixture's assertions treat both representations as valid.

Google DoH returns empty Answer for the SVCB query when Cloudflare returns the record. - Google's DoH JSON occasionally drops uncommon record types from responses (intermittent; appears related to caching state at Google's edge). Use Cloudflare DoH as the primary verifier: https://cloudflare-dns.com/dns-query?name=_webgcp.<host>&type=64. The L0-003 fixture is resolver-agnostic — as long as any compliant resolver returns the record, the assertion passes.

Squarespace's "Priority" field — what to enter. - If Squarespace's SVCB form shows a separate Priority field, you have two valid options: 1. Set it to 1 (matches ServiceMode in v0.1). 2. Leave it blank / N/A. Squarespace defaults to encoding priority from the first token of the Data field. Both worked in practice (verified at webgcp.org). - Do NOT set Priority to 0. Priority 0 is AliasMode, reserved for v0.2; the L0-003 fixture's N01 negative assertion explicitly trips on this.

Why this is in L0, not L1+¶

From the spec at https://webgcp.org/spec/v0.1/#section-5-1-1:

Per §2.2's "minimal stable core" + "rough consensus and running code" principles: the cheapest moment to add a new MUST is when the conformance suite is small. The SVCB profile is a 3-line DNS-layer signal; making it an L0 requirement today costs each implementer a single registrar action and gains the entire ecosystem a frictionless discovery path. Adding it after the spec has hundreds of implementations would require a v2.0 break.

Hence: while the L0 fixture set is two-fixtures-deep, every new implementer pays a one-time DNS edit. After v1.0 ships with hundreds of implementations, this is impossible to add without breakage.

Cross-references¶

Spec §5.1.1 — the normative source
WGCP-L0-003 fixture — the test
RFC 9460 — SVCB / HTTPS records
RFC 3597 — generic record-type syntax for the fallback
webgcporg/site/DNS-ATTACHMENT.md — sister doc covering A/TXT records for first-time domain attachment
webgcporg/CLAUDE.md — locked decisions (canonical .org, Firebase Hosting, etc.)

Permanent URL: https://webgcp.org/dns-setup/svcb-at-squarespace/.
Source: rendered from SVCB-AT-SQUARESPACE.md in the maintaining catalog.
Last rendered: 2026-05-17.