Skip to main content

Domain and DNS

The domain nutritionistpro.com is registered at GoDaddy and its DNS is served by Cloudflare. Those are two different accounts with two different jobs, and the split is the most common source of confusion: records are edited in Cloudflare, while renewals, locks, and the nameserver delegation itself live at GoDaddy. For the Cloudflare zone settings (SSL mode, bot controls, caching, the /docs Worker), see Cloudflare.

Registrar​

  • Registrar: GoDaddy.com, LLC. The GoDaddy account that holds the domain: TODO (step 1).
  • Registered 2002-06-11. Expiry: 2027-06-11. Auto-renew: TODO (step 1).
  • Registrar locks: clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited, and clientRenewProhibited are all set, so the domain cannot be transferred or changed without unlocking it at GoDaddy first.
  • Two-factor authentication on the GoDaddy account: TODO (step 1).

Nothing else is at GoDaddy. GoDaddy's own DNS is not in use, so a record added in the GoDaddy DNS screen has no effect.

Nameservers​

The domain is delegated to Cloudflare (a full setup, not a partial or CNAME setup):

anton.ns.cloudflare.com
harmony.ns.cloudflare.com

The delegation was changed from GoDaddy's ns51/ns52.domaincontrol.com to Cloudflare on 2026-06-27 (the registry's last-updated date). Before that, the zone was served by GoDaddy and the apex pointed straight at the Lightsail instance with no proxy in front of it.

The Cloudflare zone is on the free plan, in the same Cloudflare account as axxya.com. See Cloudflare.

DNS records​

Record of truth

The full record set is the export from Cloudflare (DNS > Records > Export, a BIND zone file). Paste the export into this section when it is available, replacing the lists below, which were assembled from public DNS lookups on 2026-10-16 and from the pages that mention each record. TODO (step 1).

Website records​

These point at the Lightsail instance and are proxied through Cloudflare (orange cloud), so public DNS answers with Cloudflare addresses, not the origin IP.

  • nutritionistpro.com A 35.174.58.107, proxied. The origin, the static IP of the instance nutritionistpro-web in the nexgen_v3 tenant. Changed from 54.162.107.22 (the old instance in the old tenant) at about 19:05 UTC on 2026-10-21; that was the whole DNS side of the migration. Rolling back is the reverse edit while the old instance still exists.
  • No AAAA record exists on the apex (confirmed in the dashboard on 2026-10-21). Cloudflare serves the site over IPv6 at its own edge. Do not add one; it would only expose the origin.
  • www proxied; Cloudflare or WordPress answers it with a 301 to the apex.
  • blog and docs: proxied A records, each with two values, 3.33.251.168 and 15.197.225.128. These are not the WordPress origin; they are GoDaddy's domain-forwarding service, which answers a 301 to https://nutritionistpro.com/nutrition (checked 2026-10-21). A change to the origin IP does not touch them. The forwarding only works over plain HTTP: https://blog.nutritionistpro.com/ and https://docs.nutritionistpro.com/ return a Cloudflare 525 because the forwarder has no certificate for those names and the zone is Full (strict). docs is not used for the documentation (that is the /docs path on the apex). The clean fix is to delete both records and, if the blog name still receives traffic, add a Cloudflare redirect rule for it instead; whether anything links to either name: TODO (step 1).
  • ftp: proxied A record to 166.62.109.21, a GoDaddy address from before the move to Cloudflare. Nothing on the site uses it; whether it can be deleted: TODO (step 1).

When the site moves to a new instance, the apex A record is the only one of these that changes, as it did on 2026-10-21. See Moving the site to the new AWS tenant.

Nexgen V3 records​

These belong to the nexgen_v3 tenant and must not be touched when working on the website:

  • app (nexgen), trial (nexgen-free), api, and dev (the customer API). Proxied through Cloudflare.
  • mcp CNAME mcp-v3.prod.nutritionistpro.net (the MCP server).

They are listed on Nexgen V3 deployment. The dev record was added by hand in Cloudflare.

Mail records​

Mailboxes for @nutritionistpro.com are on Microsoft 365, tenant NETORGFT1080937.onmicrosoft.com:

  • MX 0 nutritionistpro-com.mail.protection.outlook.com
  • TXT v=spf1 include:spf.protection.outlook.com -all
  • TXT NETORGFT1080937.onmicrosoft.com (the Microsoft 365 domain verification)
  • DKIM selector CNAMEs (selector1._domainkey, selector2._domainkey): TODO (step 1), confirm from the export whether they exist. The axxya.com zone got its selectors on 2026-09-15; see Nexgen V3 outgoing email.

There is no _dmarc record on nutritionistpro.com. That is an open item: add v=DMARC1; p=none; rua=mailto:<reporting address> first, then tighten the policy after a few weeks of clean reports, as described for axxya.com on the email page.

Mail is the thing a DNS mistake breaks first

Every mailbox on the domain depends on the MX and SPF records above. Before changing nameservers, importing a zone, or deleting records that look unused, confirm the MX, SPF, and any DKIM records are present in the new place. This was the main caution when the zone moved to Cloudflare.

Verification records​

TXT records that prove ownership of the domain to a service. They do nothing else, and deleting one breaks that service's verification:

  • google-site-verification=...: Google Search Console and other Google services.
  • facebook-domain-verification=...: Meta Business, for the Facebook pixel and ads.
  • Eleven globalsign-domain-verification=... records: historic certificate validation at GlobalSign. Which, if any, are still needed: TODO (step 1). They are harmless to keep.
  • Two opaque TXT values (DSXPalXaCg3cmHiS3rp93R6ZGcYXXL and 1iAFa0BmXpOuysnNtquZtrQz2nO5pD): unknown origin, probably older verifications. TODO (step 1).

Who changes what​

  • DNS records: Cloudflare, DNS > Records on the nutritionistpro.com zone. Proxy status (orange cloud) matters: a record for the website must be proxied, or the origin is exposed and Cloudflare's rules do not apply.
  • Zone settings (SSL mode, WAF, bots, Workers routes): Cloudflare. See Cloudflare.
  • Nameservers, renewal, locks, contacts, transfer: GoDaddy. Changing the nameservers away from Cloudflare would take down the /docs Worker, the proxy, and every record Cloudflare serves, so it is never a casual change.
  • The Nexgen V3 records: the nexgen_v3 deployment work owns them. Changes there are documented on Nexgen V3 deployment.

Checks​

From any machine:

dig +short NS nutritionistpro.com
dig +short MX nutritionistpro.com
dig +short TXT nutritionistpro.com | grep spf
dig +short TXT _dmarc.nutritionistpro.com
whois nutritionistpro.com | grep -iE "Registrar:|Expiry|Name Server"

The nameservers must be the Cloudflare pair, the MX must be the Outlook host, and the registrar must be GoDaddy. The DMARC lookup is empty until the open item above is done.