DNS Management for Multi-Site Portfolios: Setup Guide

By Yanni Papoutsis | 8 min read | 2026-07-30

TL;DR: Managing DNS across a portfolio of sites gets messy fast if every domain lives in a different place with a different login. The fix is centralising DNS at one provider, typically Cloudflare, even when the domains stay registered elsewhere, so every A, CNAME, TXT, and MX record for every property is visible in one dashboard. Use low TTLs before a migration and higher TTLs once a setup is stable, keep a plain text or spreadsheet record of what every record is for, and never delete a record you don't recognise without checking what depends on it first. Each site in the portfolio should point its apex or subdomain at the host it actually runs on, whether that's Vercel, Netlify, or Cloudflare Pages, and the records for that should be documented alongside the deployment guide for that specific site.

What Does DNS Management Look Like Across a Multi-Site Portfolio?

A single site's DNS is a handful of records: an A or CNAME for the apex, a CNAME for www, maybe an MX record for email. A portfolio of ten or twenty sites multiplies that by every domain, and multiplies the risk by however many different registrars and dashboards those domains are scattered across.

The practical problem isn't DNS itself, which hasn't changed in decades; it's the operational overhead of remembering which of six logins controls which domain, and the very real risk of editing a record on the wrong site because two dashboards look similar at 11pm.

The fix is structural: put every domain's DNS in one place, document what every record does, and treat DNS changes with the same caution as a production deploy, because a bad DNS edit takes a site down just as effectively as a bad code push, and it can take far longer to notice.

Why Do Portfolio Sites Need a Shared DNS Strategy?

Three reasons show up repeatedly once a portfolio grows past two or three sites.

Consistency reduces mistakes. If every site's DNS follows the same pattern (apex redirects to www, www is a CNAME to the host, TXT records are grouped and labelled), you can audit any site in the portfolio without relearning its layout each time.

Centralising makes automation possible. A single DNS provider with an API means you can script checks, like verifying every site's records still point where they should, rather than clicking through multiple dashboards by hand. This pairs naturally with a scheduled Claude task; see schedule-recurring-claude-tasks for how to set one up.

Outages get diagnosed faster. When something is down, "which DNS provider is this domain even on" should never be a question you have to answer under pressure. One provider, one dashboard, one place to look.

How Do You Choose Between Registrar DNS and a Dedicated DNS Provider?

Most registrars offer DNS hosting as a default, and it's fine for a single hobby site. For a portfolio, move the DNS (not necessarily the registration) to a dedicated provider like Cloudflare, which is free for this use case and gives you:

• A consistent dashboard across every domain, regardless of which registrar each one is bought through.
• An API for programmatic record management.
• Built-in analytics on DNS query volume, which flags unexpected traffic patterns.
• Proxying (the orange cloud) for sites that want Cloudflare's CDN and DDoS protection in front of them, and a plain grey-cloud DNS-only mode for sites that don't.

Moving DNS to Cloudflare doesn't require moving the domain registration itself. You point the domain's nameservers at Cloudflare from wherever it's registered, and Cloudflare becomes the source of truth for every record from then on.

How Do You Structure Records for Multiple Domains Pointing at Different Hosts?

Keep a simple table, even a spreadsheet, that maps every domain to its host and record type before touching anything. For a portfolio spanning Vercel, Netlify, and Cloudflare Pages, a typical layout looks like this:

Each host publishes its own exact target values, and those change occasionally, so check the current values in the platform's dashboard rather than reusing values from an old project. The setup steps for each host are covered in connect-vercel-claude, connect-netlify-claude, and deploy-static-site-cloudflare-pages.

How Do You Set TTLs for Safer Cutovers?

TTL (time to live) controls how long resolvers cache a record before checking again. It's the one setting that determines how fast a mistake, or a fix, propagates.

Before a migration: drop the TTL to 300 seconds (five minutes) at least 24 hours ahead of the change. This means that if the new target is wrong, you can fix it and have the correction propagate in minutes instead of hours.

During the migration: make the change, verify it resolves correctly from multiple locations, and watch traffic and error rates for the affected site.

After the migration settles: raise the TTL back to something like 3600 or higher. A stable record doesn't need to be re-checked every five minutes, and a longer TTL reduces load on the DNS provider and speeds up resolution slightly for visitors.

# Query the current TTL for a record from the command line
dig example.com A +noall +answer

This is also a useful command to keep in a runbook: run it before and after a change to confirm propagation actually happened, rather than assuming it did.

How Do You Automate DNS Checks Across the Portfolio?

Once every domain's DNS lives on one provider with an API, checking that every site's records still match what they should be is a script, not a manual audit. A small Python service using the provider's API, or an MCP server built with FastMCP as covered in mcp-server-python-fastmcp, can pull every zone's records and diff them against the documented expected state.

import requests

CF_API_TOKEN = "your-api-key-here"
ZONE_ID = "your-zone-id-here"

def get_dns_records(zone_id):
    url = f"https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records"
    headers = {"Authorization": f"Bearer {CF_API_TOKEN}"}
    resp = requests.get(url, headers=headers)
    resp.raise_for_status()
    return resp.json()["result"]

for record in get_dns_records(ZONE_ID):
    print(record["type"], record["name"], record["content"])

Wire this into a scheduled task and you get a daily or weekly confirmation that nothing has drifted, which matters more than it sounds like it should; DNS records get changed by accident more often than anyone would like to admit, usually by someone editing the wrong zone in a hurry. If the API calls start failing unexpectedly, the general connection debugging steps in mcp-troubleshooting-guide apply here too, since the same auth and connectivity issues that affect other MCP servers affect a DNS-checking one.

How Do You Avoid Downtime During a Nameserver Migration?

Changing a domain's nameservers (as opposed to individual records within an existing provider) is the highest-risk DNS operation in a portfolio, because it swaps the entire source of truth for that domain at once.

The safe sequence:

1. Recreate every existing record at the new provider first. Copy every A, CNAME, MX, and TXT record exactly before changing anything at the registrar.
2. Verify the new zone resolves correctly using a tool that lets you query a specific nameserver directly, bypassing your local cache.
3. Lower the TTL on the old provider at least a day ahead, if the old provider still controls the records at that point.
4. Change the nameservers at the registrar.
5. Wait out the propagation window, which can take anywhere from minutes to 48 hours depending on the registrar and the previous TTL, and avoid making further changes during this window since you can't be certain which provider is being consulted by any given resolver.
6. Confirm email deliverability separately from the website, since a missed MX or SPF/DKIM record during a migration breaks mail silently while the website looks fine.

Frequently Asked Questions

Do I need to move domain registration to change DNS providers?

No. Registration (who owns the domain) and DNS hosting (who answers queries for its records) are separate. You can register a domain at one company and point its nameservers at a different DNS provider, such as Cloudflare, without transferring ownership. Most portfolios do exactly this: registrars stay wherever it's convenient or cheapest, and DNS consolidates at one provider.

What's the safest TTL to use day to day?

For records that rarely change, 3600 seconds (one hour) to 86400 seconds (24 hours) is reasonable and reduces unnecessary query load. Drop it to 300 seconds only in the window around a planned change, then raise it again once the new configuration is confirmed stable. Leaving every record permanently at a very low TTL doesn't add safety day to day; it only adds query volume.

How do I know if a domain in my portfolio is misconfigured?

Query it directly with dig or an equivalent tool and compare the answer against your documented expected state, rather than trusting what loads in a browser, since browsers and local resolvers cache aggressively and can mask a real misconfiguration. Automating this check on a schedule, as described above, catches drift before a visitor does.

Can one Cloudflare account manage DNS for domains registered at different companies?

Yes. This is the normal setup for a multi-site portfolio: one Cloudflare account holds the DNS zone for every domain, regardless of which registrar each domain is purchased through. Add each domain to the account, update its nameservers at the original registrar to point at Cloudflare, and manage every record from the single Cloudflare dashboard from then on.