Cloudflare Command Center: Domains, DNS, Zero Trust, and Tunnels from Beginner to Expert Part 19: Cloudflare Infrastructure Blueprint for Small Businesses

Part 18 walked through advanced Zero Trust policy construction: identity providers, device posture rules, and the logic that decides who gets through and who doesn't. That was the policy layer. This article is the architecture layer. It takes every concept this series has covered and arranges them into a single deployable blueprint that a real business can actually use.

Not a theoretical overview. Not a "here are your options" survey. A concrete, opinionated reference document for a small business that wants to run a serious infrastructure posture on a minimal budget.

If you've been following along since Part 1, this is where the pieces lock together. If you're arriving here directly because you're standing in front of a small business network that needs a real security architecture, that works too. Everything you need is in this article.

From Concepts to a Complete Architecture

Who This Blueprint Is For

This blueprint is written for three kinds of people. The first is a small business owner who has been handed the IT responsibility by default and is trying to build something defensible before something goes wrong. The second is a solo IT admin managing a company with somewhere between five and fifty employees, probably wearing several other hats, and working with a budget that doesn't stretch to enterprise tooling. The third is a technical founder who built the product and now also manages the domain, the email, the internal tools, and the access controls.

All three of those people share the same constraint: limited time, limited budget, and a real need for infrastructure that doesn't embarrass them in front of a client, an auditor, or an attacker.

The scope here is deliberate. One primary domain. A small team. A single primary office or a distributed remote team. The goal is maximum security posture at minimum recurring cost, using Cloudflare's free and low-cost tiers wherever possible.

What You Will Have When You Are Done

By the end of this article, you'll have a reference architecture covering six layers: domain registration and ownership hygiene, DNS structure and naming conventions, email DNS configuration, website protection via Cloudflare proxy, tunnel deployment for internal services, and Zero Trust access controls. Each section maps directly to configuration steps, not just explanations. You can bookmark this article, share it with a contractor, or use it as the foundation for an internal runbook.

This is a living document format. As your infrastructure grows, the same framework scales with it.

Layer 1. Domain Registration and Ownership Hygiene

Registering or Transferring Your Domain to Cloudflare

Your domain is the root of your entire infrastructure. Everything else, your email, your website, your internal tools, your Zero Trust policies, depends on it. If your domain is registered at a provider you barely remember signing up with in 2014, that's a risk surface you're carrying unnecessarily.

Consolidating domain registration inside Cloudflare eliminates the split between your registrar and your DNS provider. Fewer accounts, fewer credentials to protect, fewer places for an attacker to find a seam.

The transfer process is straightforward. Unlock the domain at your current registrar, disable WHOIS privacy temporarily to retrieve the transfer authorization code, initiate the transfer inside Cloudflare, and confirm the email. Post-transfer, run through a short verification checklist: confirm nameservers are set to Cloudflare, confirm DNS records migrated correctly, and confirm the domain shows as active in your Cloudflare account.

WHOIS Privacy, DNSSEC, and Lock Settings

Enable three things immediately after your domain is inside Cloudflare.

First, WHOIS privacy. Even for a legitimate business, exposing the registrant's personal name and email in public WHOIS records is unnecessary. It creates a social engineering target and invites spam. Use a role-based email address as the registrant contact. Something like [email protected] or [email protected]. Not a personal address that belongs to one employee who might leave.

Second, DNSSEC. This cryptographically signs your DNS records and protects against DNS spoofing attacks, where an attacker poisons a resolver's cache and redirects your traffic to a malicious destination. Cloudflare enables DNSSEC with a single toggle and handles the key management automatically.

Third, Registrar Lock. This prevents unauthorized domain transfers. Without it, an attacker who compromises your registrar account can initiate a transfer before you notice. The lock adds a required confirmation step that stops that class of attack cold.

These three settings take less than five minutes to configure and protect the single most critical asset in your infrastructure.

Layer 2. DNS Architecture and Recommended Naming Scheme

Designing a Clean DNS Namespace

Most small business DNS zones look like they were built incrementally over several years by people who weren't talking to each other. Records added for a contractor, records pointing to servers that no longer exist, subdomains with names that made sense at the time and mean nothing now. That accumulation creates confusion and risk.

A clean DNS namespace starts with a deliberate naming scheme and a short list of standard subdomains. Define them once, document them, and don't deviate without updating the document.

Recommended DNS Record Naming Conventions

For a small business, the following subdomain structure covers most use cases cleanly.

Keep a copy of this table in your internal documentation. Update it every time you add or remove a record. Treat it as a living document, not a one-time exercise.

Proxied vs. DNS-Only: When to Use Each

The orange cloud in Cloudflare means the record is proxied. Traffic routes through Cloudflare's network, which means DDoS protection, WAF rules, and caching apply. The gray cloud means DNS-only: Cloudflare resolves the hostname but traffic goes directly to your origin.

Use the proxy for anything public-facing: your website, any web application, any Tunnel-backed hostname.

Never proxy MX records. Email delivery depends on direct DNS resolution, and proxying MX records breaks mail routing entirely. Never proxy records pointing to internal tunnel endpoints that aren't using Cloudflare's HTTP proxy layer. Never proxy VPN endpoints or any non-HTTP service.

The rule is simple: if it's a web property and you want Cloudflare's protection layer in front of it, orange cloud. If it's anything else, gray cloud, and be deliberate about why.

Layer 3. Email DNS Configuration

SPF, DKIM, and DMARC Records Explained

Email DNS is the layer most small businesses get wrong, and the consequences are concrete: your legitimate emails land in spam, or an attacker sends email that appears to come from your domain and your recipients have no technical reason to distrust it.

Three records protect against both problems.

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses and services are authorized to send email on behalf of your domain. For a business using Google Workspace, the record looks like this:

v=spf1 include:_spf.google.com ~all

For Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages. Your email provider generates a public/private key pair. You publish the public key as a TXT record in your DNS zone, and receiving servers use it to verify that messages weren't tampered with in transit. Retrieve the DKIM public key from your email provider's admin console and add it exactly as specified.

DMARC ties SPF and DKIM together and tells receiving servers what to do when a message fails both checks. Start with a monitoring policy before enforcing anything:

v=DMARC1; p=none; rua=mailto:[email protected]

The p=none policy means no action is taken on failures, but reports are sent to the address you specify. Run this for 30 days, review the reports, and then move to p=quarantine once you've confirmed your legitimate sending sources are all covered.

Cloudflare Email Routing as a Low-Cost Solution

Cloudflare Email Routing is a free feature that lets you create alias addresses that forward to a real inbox. For a small team, this means [email protected], [email protected], and [email protected] can all route to a single Gmail or Outlook inbox without paying for multiple mailboxes. It's configured entirely in the Cloudflare dashboard and the required MX and TXT records are added automatically.

Testing and Validating Email DNS Health

After configuring SPF, DKIM, and DMARC, validate everything before assuming it works.

"An email DNS configuration that hasn't been tested hasn't been configured. It's been guessed."

Use MXToolbox to check your MX, SPF, and DMARC records independently. Use mail-tester.com to send a test message and receive a scored report on your full email DNS health. Both tools are free and take under five minutes to run. Run them after any DNS change that touches email records.

Layer 4. Website Protection with Cloudflare Proxy

SSL/TLS Mode Selection and Why Full Strict Matters

The Cloudflare proxy gives you a meaningful security layer in front of any public-facing web property. But the value of that layer depends entirely on how you configure it. The first decision is SSL/TLS mode, and it's the one where most people make a choice that feels safe but isn't.

Flexible mode encrypts traffic between the visitor and Cloudflare but sends it unencrypted between Cloudflare and your origin server. That means your data travels in plaintext on the backend half of every request. For anything handling form submissions, login credentials, or customer data, Flexible mode is not acceptable.

Full (Strict) mode requires a valid SSL certificate on your origin server and encrypts the entire path. This is the correct setting. Cloudflare offers free origin certificates through its dashboard that are trusted by Cloudflare's edge and valid for 15 years. There's no cost reason to use anything weaker.

HSTS (HTTP Strict Transport Security) tells browsers to never connect to your domain over plain HTTP. Enable it after confirming Full (Strict) is working. Be cautious about preloading: once a domain is on the HSTS preload list, removing it is a multi-month process.

WAF Rules for Small Business Use Cases

The Web Application Firewall sits between the internet and your origin. Cloudflare's managed rulesets handle the most common attack categories automatically. Start with the OWASP Core Ruleset, which covers SQL injection, cross-site scripting, and other well-documented attack patterns. Enable it in detection mode first, review the logs for false positives, and then move to block mode.

Custom rules are worth adding for specific endpoints. A login page at /wp-login.php or /admin should have a rate limiting rule that restricts repeated authentication attempts from a single IP.

Rate Limiting and Bot Management Basics

Rate limiting lets you define thresholds: if a single IP sends more than 10 POST requests to /login in 60 seconds, block it for an hour. Cloudflare's rate limiting rules are configured in the Security section of the dashboard and use the same rule syntax as WAF custom rules.

Bot Fight Mode is a free feature that identifies and challenges known bot traffic. Enable it for any site that doesn't depend on third-party crawlers for revenue. It adds friction for automated scanners without affecting legitimate users.

Layer 5. Cloudflare Tunnel for Internal Service Exposure

Why Tunnels Replace Port Forwarding and VPNs

The traditional approach to exposing an internal service to the internet involves opening a port on your firewall and forwarding traffic to an internal server. That approach works, but it means your server's IP address is publicly reachable, your firewall rules need to be exactly right, and every service you expose creates a new attack surface.

Cloudflare Tunnel inverts that model. Nothing is open inbound. The cloudflared daemon running on your internal server creates an outbound connection to Cloudflare's edge, and traffic flows through that encrypted tunnel. An attacker scanning your IP finds no open ports. Your origin IP stays private. The entire exposure surface shrinks to whatever access policies you've defined in Zero Trust.

Deploying cloudflared for a Small Business

The deployment model for a small business is straightforward. One server or VM on your local network runs cloudflared. That process authenticates to your

Layer 6. Zero Trust Access Policies and the Access Policy Matrix

Part 18 covered tunnel architecture and how cloudflared connects your internal services to Cloudflare's network without opening firewall ports. Now the question changes. The tunnel gets traffic to the edge. Access decides who's allowed through.

Defining Your Identity Providers

Cloudflare Access sits in front of every tunneled or proxied resource and enforces authentication before a request reaches your origin. It doesn't replace your application's login system. It wraps around it. A user hits your internal tool's hostname, Access intercepts the request, verifies identity, and only then passes traffic through.

For small businesses, Google Workspace is the most common identity provider. The configuration is straightforward: add a Google OAuth application, paste the client ID and secret into the Cloudflare Access identity provider settings, and restrict the allowed domain to your business Google Workspace domain. That's your baseline. Every Access policy you write can now reference Google groups, email addresses, or domain membership as conditions.

Building the Access Policy Matrix

An Access Policy Matrix is a table. One row per protected application. Columns for the resource name, its hostname, and the identity conditions required to reach it. Building this table before you write a single policy forces clarity. You'll catch gaps, overlaps, and resources you forgot were exposed.

Every Access policy has three components. Include defines who is considered for access at all. Require adds a mandatory condition that must also be true. Exclude removes specific identities even if they'd otherwise pass. A policy that includes everyone on your Google domain, requires membership in the employees group, and excludes a terminated contractor's email address is a complete, auditable rule.

AcmeCo Access Policy Matrix. Sample

Policy Enforcement: Applications, SSH, and Admin Panels

Application policies are the most familiar. SSH is where Access earns its keep in a different way. Cloudflare Access supports a browser-based SSH terminal that proxies shell sessions through the Access layer. No exposed port 22. No SSH key distribution problem. The user authenticates through Access, and a terminal opens in their browser. The session is logged. The key never leaves Cloudflare's infrastructure.

Short-lived certificate authentication is the cleaner alternative to SSH keys for teams that want auditable access. When a user authenticates through Access, Cloudflare issues a certificate valid for a short window, typically under an hour. That certificate is used to authenticate the SSH session. No standing credentials. No keys to rotate. Access handles the trust chain.

The policy matrix isn't a formality. It's the document you reference when someone asks why a contractor can't reach Grafana, or when an auditor wants to know who had access to production SSH last quarter. Build it before you need it.

Layer 7. Admin Access Controls and User Roles

The infrastructure is only as secure as the accounts that manage it. That's not a warning. It's an architectural constraint, and it deserves the same design attention as DNS records and tunnel configuration.

Cloudflare Dashboard Roles and Least Privilege

Cloudflare's account member system has distinct roles. Super Administrator has unrestricted access to everything, including billing, domain transfers, and account deletion. Administrator manages zones and settings but can't touch billing. DNS role is scoped to record management only. Firewall role handles WAF and security rules. Billing role manages payment methods and invoices.

The principle of least privilege applies directly here. No one except the business owner should hold Super Administrator rights. A developer who needs to update DNS records gets the DNS role. A security contractor who needs to tune WAF rules gets the Firewall role. Zone-level permissions let you scope access even further, granting a team member Administrator access on one domain without touching others.

Separating Billing, DNS, and Security Responsibilities

The billing contact and the technical admin contact should never be the same account. When they're the same, a compromised technical account can change payment methods, cancel services, or initiate a domain transfer. Separate them. Assign billing access to an account that has no DNS or firewall permissions.

"Access should be granted to the minimum scope required for the task at hand, and revoked the moment the task is complete."

Audit your current account members now. Go to the Cloudflare dashboard, open Account Members, and look at every entry. If you see shared credentials, accounts for people who no longer work there, or Super Administrator roles assigned to contractors, fix those before anything else in this blueprint.

Enforcing MFA for All Admin Accounts

FIDO2 and WebAuthn hardware keys are the correct MFA method for admin accounts. TOTP apps are acceptable. SMS is not. Require hardware MFA for every account with Administrator access or above, without exception. Cloudflare supports this enforcement at the account level. Turn it on. A quarterly access review, checking roles, removing stale accounts, and confirming MFA enrollment, is the minimum operational hygiene standard for any account managing production infrastructure.

Layer 8. Backup Access Plan

Everything built in Layers 1 through 7 assumes your identity provider is reachable. That assumption will fail. Plan for it now, not at 11pm when the failure happens.

What Happens When Your Identity Provider Goes Down

If Google Workspace experiences an outage and every one of your Access policies requires Google authentication, every Access-protected resource becomes unreachable. Your internal wiki, your monitoring dashboard, your SSH access. All of it. This isn't a theoretical edge case. It's a dependency you've built into your architecture, and dependencies fail.

Cloudflare Access has two mechanisms that address this directly. The first is one-time PIN fallback, which lets users authenticate via an email code instead of an IdP. The second is a secondary identity provider, a separate authentication source configured alongside Google. GitHub OAuth works well for small technical teams. A time-based OTP provider works for everyone else.

Emergency Admin Access Without Lockout

The break-glass account is a Cloudflare local account, created directly in the Cloudflare dashboard, not federated through any identity provider. It holds Super Administrator rights. It exists for one purpose: getting into the dashboard when everything else is broken.

Store the break-glass credentials in an encrypted password manager vault. Print a copy. Put that printed copy in a physical safe or a locked filing cabinet. The digital copy handles day-to-day emergency access. The physical copy handles the scenario where your password manager is also unreachable.

Test the break-glass procedure quarterly. Log in with the account. Confirm access. Log out. Document the test. A procedure that's never been tested is a procedure that won't work when you need it.

Documenting the Break-Glass Procedure

The break-glass document should include the account email, the location of the credentials, the steps to log in, and the steps to take once access is restored, including reviewing the audit log for what happened. Store this document somewhere accessible when your primary systems are down. A printed binder works. A shared drive that requires the systems you just lost to access does not.

Putting It All Together. The Small Business Architecture Diagram

Every layer covered in this series exists as an independent configuration decision. But they don't operate independently. They stack. A request doesn't just hit DNS. It moves through a sequence of controls, each one depending on the layer before it.

Reading the Full Architecture

The stack for AcmeCo reads left to right. Cloudflare Registrar holds the domain and locks it against unauthorized transfers. DNS resolves hostnames using the naming convention established in Part 17, with DNSSEC enabled. Cloudflare Proxy intercepts traffic to public-facing hostnames, applies WAF rules, and terminates TLS. Cloudflare Tunnel connects internal services to the edge without exposing any origin IP. Cloudflare Access enforces authentication and authorization before any tunneled resource is reachable. Google Workspace acts as the identity provider. The end user authenticates, receives a session token, and traffic flows back through the tunnel to the internal service.

How the Layers Interact in Practice

A remote employee opens wiki.acmeco.com in a browser. Cloudflare DNS resolves the hostname. The proxy intercepts the request and checks whether Access has a policy for this hostname. It does. Access redirects to Google for authentication. The employee logs in, Access validates group membership against the policy matrix, issues a session cookie, and the request passes through the tunnel to the internal wiki server. The employee never touches the origin IP. The origin never sees unauthenticated traffic.

Common Variations for Different Business Types

E-commerce businesses need more aggressive WAF configurations, rate limiting on checkout endpoints, and bot management enabled. Professional services firms with strict compliance requirements need DMARC enforcement and email security records validated and monitored continuously. Remote-first teams that have no on-premises infrastructure at all rely entirely on tunnels and Access, with no public-facing origin servers anywhere in the stack.

The free and Pro tiers cover this entire architecture for most small businesses. The only features that require Business or Enterprise tiers are advanced bot management and custom WAF rules beyond the managed ruleset. Most small businesses don't need those.

Documentation Standards for Your Cloudflare Stack

The person who built your Cloudflare configuration understands every decision that went into it. That knowledge is not in the dashboard. It's in their head. When they leave, or when you forget why you made a specific choice six months ago, undocumented infrastructure becomes a liability that compounds over time.

What to Document and Why It Matters

Five documentation artifacts cover the minimum viable record for a small business Cloudflare stack. A DNS record inventory listing every record, its type, its value, its purpose, and whether it's proxied. A tunnel service map showing which internal services are exposed through which tunnels and what hostnames they use. The Access Policy Matrix built in Layer 6. A user role register listing every account member, their role, and when their access was last reviewed. A backup access procedure covering the break-glass account and secondary IdP.

Recommended Documentation Templates

Markdown files in a private Git repository work well. Every change becomes a commit. The history is automatic. Notion works equally well for teams that prefer a visual interface. The format matters less than the consistency. Pick one and use it for everything.

"Undocumented systems fail silently and recover slowly."

The DNS naming convention document deserves its own file. A table with columns for subdomain, purpose, record type, TTL, and proxy status. Updated every time a record changes. A change log section at the bottom of each document captures the date, the change made, and the reason.

Keeping Documentation Current

Update documentation immediately after every infrastructure change. Not the next day. Not at the end of the week. Immediately, while the context is fresh. Full documentation reviews happen quarterly, aligned with the access review and break-glass test cadence. Three reviews per year catch drift. Quarterly reviews catch it before it becomes a problem.

Your Deployment Checklist. Build the Blueprint Step by Step

Deployment order matters here in a way that can't be overstated. Access policies that reference hostnames that don't exist yet will fail silently. Tunnels configured before DNS is stable will produce confusing errors. DNS before proxy. Proxy before Access. Access before you hand out credentials to anyone.

Pre-Deployment Verification

Before touching any configuration, verify that you have the domain registered or transferred, that your internal services are running and reachable on your local network, that your Google Workspace domain is active and you have admin rights to create OAuth applications, and that you've built your Access Policy Matrix in a document you can reference during deployment.

Deployment Order Matters

Every task on this list has a dependency on the tasks before it. Skipping Task 4 before Task 5 means your email records aren't validated before your proxy is live. Skipping Task 9 before Task 10 means you're writing Access policies against an identity provider that hasn't been tested. Work the list in order. Check each task off only when it's verified, not just configured.

Part 20 moves into performance and reliability, covering Cloudflare's caching rules, Cache Rules configuration, Tiered Cache topology, and how to tune cache behavior for different content types without accidentally serving stale data to the wrong users.