Create aurorion.ai.cloudflare-ns-delegation.json

[tobtraa]

Description

This PR adds a new Domain Connect template for Aurorion, enabling seamless delegation of DNS management to Cloudflare by updating the domain's nameservers. This service is designed for users onboarding domains to Aurorion's platform, which integrates with Cloudflare for enhanced DNS security, performance, and management.

Template Details:

• Provider ID: aurorion.ai
• Provider Name: Aurorion
• Service ID: cloudflare-ns-delegation
• Service Name: Cloudflare Nameserver Delegation
• Version: 1
• Description: Delegates DNS management of the domain to Cloudflare by updating the nameservers.
• Records:
  • NS @ %ns1% (TTL: 3600)
  • NS @ %ns2% (TTL: 3600)
• Variables:
  • ns1: The first Cloudflare nameserver.
  • ns2: The second Cloudflare nameserver.
• Security Features:
  • Supports synchronous flow with digital signatures (syncPubKeyDomain: aurorion.ai).
  • Includes syncRedirectDomain: aurorion.ai for redirect handling.
  • warnPhishing: true to alert users of potential risks.
  • hostRequired: true, as this applies to the domain apex.
• Logo URL: https://cdn.aurorion.ai/logo.png (publicly accessible via HTTPS).

Use Case: This template allows Aurorion users to automatically update their domain's NS records to point to Cloudflare's nameservers during the onboarding process, simplifying setup for websites hosted on Aurorion's AI-powered platform.

Provider Information:

• Website: https://aurorion.ai
• Contact: [email protected]
• Terms of Service: https://aurorion.ai/terms
• Privacy Policy: https://aurorion.ai/privacy
• Synchronous UX Endpoint: https://aurorion.ai/domain-setup (implements the apply flow with signatures).
• Control Panel: Integrated within the Aurorion dashboard for post-setup management.

This template uses narrowly scoped variables (%ns1% and %ns2%) to minimize security risks, avoids hostname variables, and does not include SPF/TXT records that could conflict. No breaking changes or updates to existing templates.

Type of change

• New template

How Has This Been Tested?

• Schema validated using JSON Schema template.schema
• Template functionality checked using Online Editor
• Template is checked using template linter
• Template file name follows the pattern ..json
• resource URL provided with logoUrl is actually served by a webserver

Checklist of common problems of issues

• digital signatures are used and syncPubKeyDomain specified (yes, warnPhishing is an option, but some providers reject such templates by policy, so signing shall be a default)
• syncRedirectDomain is specified when intended to use redirect_uri parameter in the synchronous flow
• no TXT record with SPF content (i.e. "v=spf1 ..." ) instead of using SPFM record type on APEX
• txtConflictMatchingMode is set on TXT records which shall be unique on a label (like DMARC)
• variables are set to the smallest scope needed (i.e. limit possibility to be misused to set any arbitrary record and conflict with other template). Too broad scope example: @ TXT "%verification%". Better usage: @ TXT "foo-verification=%verification%".
• no variables as a host name to apply template on subdomain instead of standard host parameter
• no explicit usage of %host% variable in host attribute
• essential setting is used on records, which the user shall be able to change or remove manually later without dropping the whole template (like DMARC)

Example variable values

{
  "testData": {
    "aurorion-test": {
      "variables": {
        "domain": "example.com",
        "host": "aurorion.ai",
        "ns1": "ns1.example.cloudflare.com",
        "ns2": "ns2.example.cloudflare.com"
      },
      "results": [
        {
          "type": "NS",
          "name": "example.com",
          "ttl": 3600,
          "data": "ns1.example.cloudflare.com"
        },
        {
          "type": "NS",
          "name": "example.com",
          "ttl": 3600,
          "data": "ns2.example.cloudflare.com"
        }
      ]
    }
  }
}

https://domainconnect.paulonet.eu/dc/free/templateedit#tbl_records_and_errors:

[github-actions]

Linter OK:

Linter result for aurorion.ai.cloudflare-ns-delegation.json
{"level":"info","template":"aurorion.ai.cloudflare-ns-delegation.json","code":"DCTL1028","dctl_note":"warnPhishing together with syncPubKeyDomain has no practical relevance","time":1769968873}

[tobtraa]

@arnoldblinn @pawel-kow Could you please review this template addition for aurorion.ai.cloudflare-ns-delegation? It passes schema validation and follows the spec.

[kerolasa]

Could you explain why this template works? I am particularly interested of hearing how changing NS records makes sense on currently authoritative name servers. Perhaps my thinking has some sort of oversight.

[pawel-kow]

@tobtraa just to put things straight - even though it is described in the spec as an extension, I know no provider which would support NS change.

[tobtraa]

@kerolasa Thanks for the question.

The Domain Connect protocol allows a service provider (like Aurorion) to request DNS changes from the domain's current DNS provider via a standardized API. For this template, which updates NS records to delegate to Cloudflare, it works as follows:

1. Discovery: We query the domain's _domainconnect TXT record to find the DNS provider's Domain Connect endpoint (e.g., https://domainconnect.godaddy.com for GoDaddy).
2. Synchronous Flow with Signing: Aurorion generates a signed apply URL (using our private key published at _dcpubkeyv1.aurorion.ai TXT) that includes the variables (ns1 and ns2 for Cloudflare's nameservers). The user is redirected to this URL on the DNS provider's side.
3. Application by Current Provider: The DNS provider verifies the signature (against our public key), checks user consent, and applies the template to its own zone file. Since the DNS provider (e.g., GoDaddy or IONOS) is the one currently listed in the domain's NS records at the registrar level, it's the entity holding and serving the zone file for all DNS queries. As such, it has full control to modify any records in that zone, including updating its own NS records to point to new nameservers (like Cloudflare's). This self-modification initiates the delegation: Once applied, resolvers will gradually switch to querying the new NS as the TTL expires, but the old provider can still serve during the transition. It's like a captain handing over the ship's wheel while still on board.

In practice, this simplifies onboarding: Users don't manually edit DNS; Aurorion handles the request, and the provider applies it atomically.

No oversight in your thinking—it's counterintuitive at first, but the key is that the change happens on the current authoritative servers before delegation. I've tested this flow with supported providers like GoDaddy (from our registrar list).

This is explicitly supported in the Domain Connect spec as a standard record type (NS), see the template record section for details on NS fields like pointsTo and TTL.

[tobtraa]

@tobtraa just to put things straight - even though it is described in the spec as an extension, I know no provider which would support NS change.

@pawel-kow Thanks for clarifying—appreciate the insight. You're right; while the spec includes NS as a valid record type/extension, actual support varies by DNS provider policy (e.g., some may block templates with NS to retain control). In our case, we've limited to registrars we know implement Domain Connect (GoDaddy, IONOS, Namesilo, Name.com, eNom).

[pawel-kow]

@tobtraa you got it wrong. I mean that any of those providers you mentioned is not known to support NS change.

[tobtraa]

@pawel-kow Got it—thanks for setting me straight. With no known support for NS changes among those providers, Domain Connect isn't a viable solution for full delegation in our onboarding flow. I'll close this PR and explore alternatives like direct APIs or AI-guided manuals to make it truly easier for customers. Appreciate the insights!

[tobtraa]

Closed