Add Render custom domain templates (render.com)

[anurag]

Description

Three new templates from Render (cloud application platform) for connecting a customer's custom domain to their Render service:

file	purpose	records
render.com.custom-domain-subdomain.json	any subdomain	CNAME @ → %renderService% (applied under host)
render.com.custom-domain-apex.json	root domain, for providers that support a flattened/ALIAS CNAME at the zone apex	group apex: CNAME @; group www: CNAME www
render.com.custom-domain-apex-a.json	root domain, for providers that require an A record at the apex	group apex: A @ → 216.24.57.1; group www: CNAME www

Design notes for reviewers:

• Two apex variants exist deliberately. Render's apex target is a CNAME wherever the provider can flatten it (better for anycast IP changes), and a literal A record everywhere else. Providers onboard whichever variant matches their capability; the variants are never both applied to one zone.
• hostRequired differs between the apex variants and this is intentional. The CNAME variant sets hostRequired: true because the linter (DCTL1012) requires it next to a CNAME on host @ — a literal root CNAME is invalid DNS, so that variant is only onboarded by providers that flatten (e.g. Cloudflare), which per DCTL5006 ignore hostRequired. The A variant sets hostRequired: false and is the general-purpose apex template.
• Record groups: the apex templates carry the www record in a separate group so that configuring a root domain plus its www costs a single consent screen; the apply URL's groupId selects apex or apex,www.
• %renderService% as a full pointsTo value (checklist item below): the CNAME target is exactly the customer's <service>.onrender.com hostname, prescribed by Render's platform — there is no fixed prefix a CNAME target can carry. All apply URLs are signed (syncPubKeyDomain is set), so the value is attested by Render's key, and Render's server-side verification independently checks the resulting DNS before activating the domain.
• syncRedirectDomain is render.com (registrable domain), matching how the spec scopes redirect validation.
• Templates pass dc-template-linter clean (default, -cloudflare, and -logos modes) and validate against template.schema.

Type of change

Please mark options that are relevant.

• New template
• Bug fix (non-breaking change which fixes an issue in the template)
• New feature (non-breaking change which adds functionality to the template)
• Breaking change (fix or feature that would cause existing template behavior to be not backward compatible)

How Has This Been Tested?

Please mark the following checks done

• Template functionality checked using Online Editor
• Template file name follows the pattern <providerId>.<serviceId>.json
• resource URL provided with logoUrl is actually served by a webserver

Checklist of common problems

Mark all the checkboxes after conducting the check. Comment on any point which is not fulfilled.
See Template Quality Guidelines for details and rationale on each rule.

• syncPubKeyDomain is set — this is mandatory; omitting it requires explicit justification in the PR description or the PR will be rejected
• warnPhishing is not set alongside syncPubKeyDomain — the two must not appear together
• syncRedirectDomain is set whenever the template uses redirect_uri in the synchronous flow
• no TXT record contains SPF content ("v=spf1 ...") — use the SPFM record type instead (no TXT records in these templates)
• txtConflictMatchingMode is set on every TXT record that must be unique per label or content prefix (e.g. DMARC) (no TXT records in these templates)
• no variable is used as a bare full record value (e.g. @ TXT "%foo%") unless necessary — prefer @ TXT "service-foo=%foo%"; if bare, justify in the PR description (justified above: CNAME pointsTo is the service hostname itself; requests are signed)
• no bare variable is used as the full host label — the non-variable parts are fixed to limit misuse (e.g. %dkimkey%._domainkey, not %dkimhost%) (hosts are fixed @ and www)
• no variable is used in the host field to create a subdomain — use the host parameter or multiInstance instead
• %host% does not appear explicitly in any host attribute
• essential is set to OnApply on records the end user may need to modify or remove without breaking the template (e.g. DMARC) (all records here are essential: "Always" deliberately: each one IS the service connection, and a manual edit to any of them breaks the domain — there is no record a user should change independently of the template)

Online Editor test results

Editor test link(s):

• Test render.com/custom-domain-subdomain example.com/app
• Test render.com/custom-domain-apex example.com/site
• Test render.com/custom-domain-apex example.com/site
• Test render.com/custom-domain-apex-a example.com/@
• Test render.com/custom-domain-apex-a example.com/@
• Test render.com/custom-domain-apex-a example.com/app

[github-actions]

✅ JSON Filename Check Passed

[github-actions]

✅ JSON Schema Validation Passed

[github-actions]

Linter OK

render.com.custom-domain-apex-a.json

Level	Code	Note

render.com.custom-domain-apex.json

Level	Code	Note

render.com.custom-domain-subdomain.json

Level	Code	Note

[github-actions]

PR Description Check Passed

All required sections are filled in correctly.

Details

  OK  Type of change: 1/4 checkboxes ticked
  OK  How Has This Been Tested?: all 3 checkboxes ticked
  OK  Checklist of common problems: 10/10 checkboxes ticked
  OK  Online Editor test results: 6 link(s) found
  OK  Template coverage: all 3 template(s) covered
Labels to remove: Checklist of common problems not complete, Forged editor links, PR description incomplete, Test links missing

PR description check PASSED