Multi-Tenant DNS Setup: A and CNAME Best Practices for SaaS

Multi-tenant DNS setup is one of the most important parts of SaaS onboarding. If DNS is unclear, customers get stuck before they even use your product. If DNS is clear and validated, onboarding feels fast and reliable.

In this guide, you will learn how to design a practical multi-tenant DNS setup using A and CNAME records, when to use each record type, and how to validate routes before going live.

Why Multi-Tenant DNS Setup Fails in Production

Most DNS incidents happen because teams ship a happy-path onboarding flow and skip edge cases. Common issues include:

• Wrong record type (A instead of CNAME, or CNAME at the apex).
• Pointing to an app URL instead of a host or IP.
• Forgetting ports or HTTPS behavior in reverse proxy routing.
• No verification after record creation.
• No request-level visibility when traffic starts.

A production-grade multi-tenant DNS setup needs three layers: record mapping, route verification, and log monitoring.

A Record vs CNAME Record for SaaS Tenants

Use an A record when:

• You route directly to a stable IPv4 address.
• You control the target server IP lifecycle.
• You can update DNS quickly when infrastructure changes.

Use a CNAME record when:

• You route to a managed hostname (load balancer, gateway, reverse proxy).
• You want infrastructure flexibility behind one hostname.
• You expect target changes without forcing customer-side DNS edits.

For most SaaS teams, CNAME is the safer default for tenant subdomains. A records are still useful for controlled environments where IP ownership is stable.

Step-by-Step Multi-Tenant DNS Setup

1. Reserve and validate tenant slug

Normalize slug format before DNS creation. Keep only lowercase letters, numbers, and dashes. Reject reserved slugs and duplicates early.

2. Build fully qualified domain name

Combine the slug with your root domain, for example acme.adres100.com. This should be deterministic and immutable for that tenant.

3. Parse target input correctly

If a user pastes inputs like http://103.83.87.87:8081/ or https://router.example.com/, parse and map them safely:

• Extract host or IP only for DNS record value.
• Store scheme and port as route metadata for verification checks.
• Do not save full URL as DNS record value.

4. Create DNS record and queue worker action

After tenant target creation, publish create/update/delete events to your worker queue. Use correlation IDs so UI and worker state can be matched.

5. Trigger verification automatically

Do not wait for manual action. After worker event success, trigger DNS verification automatically and update status from pending to active only when checks pass.

6. Persist operational logs

Store request logs by tenant and expose server-side filtering in admin. This is critical for debugging route mismatches and traffic anomalies.

Validation Checklist Before Marking Tenant as Active

• DNS record exists with expected type and target value.
• Resolved target matches expected host or IP.
• HTTP/HTTPS route check returns valid upstream status.
• Nginx or gateway upstream is reachable.
• No critical worker errors in latest event payload.
• Access logs show successful requests for tenant host.

Common Mistakes and How to Avoid Them

Mistake 1: Treating URL as DNS value

DNS records should contain hostnames or IPs, not full URLs with protocol and path.

Mistake 2: Ignoring soft-deleted lifecycle

Soft-deleted tenants should not appear in user list, but should remain discoverable for controlled reclaim workflows.

Mistake 3: No audit visibility

All create/update/delete operations should write audit logs with actor, entity, timestamp, and payload summary.

Mistake 4: No admin request-log tooling

Admins need paginated, filterable request logs (tenant, status, method, path, IP, date range) to triage incidents quickly.

Operational Metrics You Should Track

• Time from tenant creation to verified status.
• Verification failure rate by record type.
• Worker action success/failure rate.
• 4xx/5xx ratio per tenant host.
• Median and p95 upstream latency.

FAQ

Can I use only A records for all tenants?

You can, but it reduces flexibility. CNAME usually gives safer long-term operations for SaaS routing.

Should verification be manual or automatic?

Automatic after successful worker events is recommended. Manual-only verification creates stale pending states.

How often should DNS verification run?

For active onboarding, frequent checks help. For stable tenants, move to scheduled intervals and event-driven rechecks.

Final Recommendation

A robust multi-tenant DNS setup is not only record creation. It is a complete operational loop: normalize input, map target correctly, publish worker actions, verify automatically, and monitor request logs.

If you want to build a stable tenant onboarding system, start with deterministic mapping and observable verification. Everything else becomes easier.

Next steps: Read the setup docs, check domain availability, or contact the team.