DNS Configuration
Understanding DNS configuration is essential for routing traffic through Atomic Edge. This guide covers DNS setup, verification, and best practices.
Prerequisites
Before changing DNS:
- Add your site in the Atomic Edge dashboard
- Note the edge endpoint IPs provided (both IPv4 and IPv6)
- Confirm you have access to edit DNS for your domain
- Keep your origin server IP documented for validation and rollback
DNS Record Types
A Records (IPv4)
For root domains (apex), use an A record pointing to the IPv4 address provided by Atomic Edge.
Type: A
Name: @ (or your domain)
Value: [IPv4 address from Atomic Edge]
TTL: 300 (during setup)AAAA Records (IPv6)
If your endpoint supports IPv6, add an AAAA record for dual-stack connectivity.
Type: AAAA
Name: @ (or your domain)
Value: [IPv6 address from Atomic Edge]
TTL: 300 (during setup)CNAME Records (Subdomains)
For subdomains, you can use a CNAME pointing to the endpoint hostname.
Type: CNAME
Name: www
Value: [endpoint hostname from Atomic Edge]
TTL: 300 (during setup)Important: CNAME records cannot be used on root domains (apex). Use A records for apex domains.
WWW Configuration
If your site serves both example.com and www.example.com:
- Add an A record for the root domain (
@) - Add an A record for
wwwpointing to the same edge IP - Optionally, add AAAA records for both if using IPv6
Multiple Edge Endpoints
For redundancy, you can add multiple A records for the same hostname:
example.com A 203.0.113.100
example.com A 203.0.113.101DNS clients typically round-robin between multiple records.
TTL Best Practices
| Phase | Recommended TTL | Reason |
|---|---|---|
| Setup/Testing | 300 seconds (5 min) | Fast propagation and rollback |
| Stable Production | 3600-86400 seconds | Reduced DNS query volume |
Tip: Lower your TTL 24-48 hours before making changes to ensure the old value expires from caches.
Verifying DNS Configuration
Using dig Command
# Check A record
dig example.com A +short
# Check AAAA record
dig example.com AAAA +short
# Check against specific resolver
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +shortVerifying Traffic Routing
After DNS propagation:
# Check HTTP headers
curl -I https://example.com
# Verify response comes from your origin content
curl https://example.comTesting Before DNS Change
You can test the edge routing without changing public DNS by editing your local hosts file:
Linux/Mac: /etc/hosts
Windows: C:\Windows\System32\drivers\etc\hosts
203.0.113.100 example.com
203.0.113.100 www.example.comRemove these entries after testing.
Rollback Procedure
To bypass the edge quickly:
- Change DNS records back to your origin IP
- Wait for propagation (faster with low TTL)
- Some clients may cache longer than TTL—plan accordingly
Best practice: Keep your original DNS values documented before any changes.
Host Header Configuration
Atomic Edge forwards the original Host header to your origin. Ensure your web server is configured to serve:
- Your apex domain (e.g.,
example.com) - The www variant if applicable (e.g.,
www.example.com)
Origin Firewall Protection
Once DNS is stable and verified:
- Restrict inbound HTTP/HTTPS on your origin
- Only allow traffic from Atomic Edge edge endpoint IPs
- This prevents attackers from bypassing the WAF
Troubleshooting
DNS Not Resolving to Edge IP
- Wait for propagation (can take up to 60 minutes)
- Verify record at your DNS provider
- Check using multiple public resolvers
- Flush local DNS cache
SSL Certificate Errors
- Certificate provisioning starts after DNS points to edge
- Ensure port 80 is reachable for HTTP validation
- Check for CAA records that might block issuance
Partial Protection (Some Subdomains)
- Each hostname needs its own DNS record
- Verify each subdomain record is updated
- Ensure hostname is configured in dashboard
Migration Checklist
- ☐ Add site to Atomic Edge dashboard
- ☐ Note edge endpoint IPs (IPv4 and IPv6)
- ☐ Whitelist edge IPs in origin firewall
- ☐ Lower DNS TTL 24-48 hours before cutover
- ☐ Update DNS records during low-traffic window
- ☐ Verify propagation with external resolvers
- ☐ Test WAF blocking with safe test strings
- ☐ Monitor logs for false positives (24-48 hours)
- ☐ Lock down origin firewall to edge IPs only
- ☐ Increase TTL once stable
Frequently Asked Questions
What do I need before I change DNS?
Prerequisites for a clean cutoverBefore you update DNS, add your site in our dashboard, note the edge endpoint IPs we provide, confirm you can edit DNS for the domain, and keep your origin server IP handy for validation and rollback.
What DNS record should I use for my root domain?
Use an A record for apex domainsFor a root domain (the @ record), point an A record to the edge IP we provide and use a low TTL (300 seconds) during setup. A CNAME cannot be used on the root domain.
How do I protect the www version of my site?
Add a matching A record for wwwIf you serve www, create an A record for www pointing to the same edge IP we provide. Use TTL 300 during setup so changes propagate quickly.
When should I use a CNAME record?
Subdomain routing without an A recordFor subdomains, you can use a CNAME that points to the endpoint hostname we provide. This is typically used for non-apex hostnames.
Why can't I use a CNAME on the root domain?
DNS standards limitation for apex recordsCNAME records cannot be used for root domains (@). For apex protection, use an A record that points to the edge IP we provide.
Can I configure multiple edge endpoints in DNS?
Redundancy with multiple A recordsYes. You can add multiple A records for the same hostname, each pointing to a different edge IP we provide. DNS clients typically round-robin between them.
Do you support IPv6?
Add AAAA records when your origin supports IPv6If you use IPv6, add AAAA records pointing to the IPv6 address we provide. Keep TTL low during setup.
Can I protect some subdomains but leave others direct to origin?
Mixed routing by hostnameYes. You can route specific hostnames through our edge while keeping other hostnames pointed directly at your origin by managing DNS records per hostname.
How do I verify DNS is pointing to the edge?
Confirm resolution and propagationAfter updating DNS, use dig to confirm your domain resolves to the edge endpoint IP, not your origin IP. Check more than one public resolver (for example 8.8.8.8 and 1.1.1.1) to validate propagation beyond local caching.
How do I verify traffic is actually routing through the edge?
HTTP checks and origin-content validationRequest your site over HTTPS (for example, curl -I https://yourdomain). Your origin content should load normally through the edge. Depending on configuration, you may also see edge/WAF-related headers.
How can I test that WAF protection is active after DNS changes?
Use a safe test string that should be blockedAfter DNS is live, test a common malicious pattern (for example a simple path traversal string). You should receive a 403 response or whatever block response you configured.
What TTL should I use during setup?
Low TTL for fast iteration and rollbackUse a low TTL (300 seconds) during initial setup and testing. This speeds propagation and makes rollback practical if you need to revert.
When should I increase TTL after setup?
Reduce DNS query load once stableAfter you’ve verified everything is stable, increase TTL to reduce DNS query volume. Common values are 3600 seconds (1 hour) or 86400 seconds (24 hours) for mature production setups.
How do I roll back quickly if something breaks?
Repoint DNS to origin and leverage low TTLTo bypass the edge quickly, change your DNS records back to your origin IP. Low TTL helps, but some clients may cache longer than the TTL, so plan rollback accordingly.
How do I prevent attackers from bypassing the WAF and hitting my origin directly?
Origin firewall allowlist for edge IPsOnce DNS is stable, restrict inbound HTTP/HTTPS on your origin to only allow our edge endpoint IPs. This prevents direct-to-origin bypass attempts.
Should edge-to-origin traffic use HTTP or HTTPS?
Choose based on your trust boundary and requirementsYou can configure whether our edge connects to your origin over HTTP or HTTPS. Use HTTPS when your origin is on the public internet or when compliance requires encryption in transit.
Will my origin receive the correct Host header?
We forward the original Host headerWe forward the original Host header to your origin. Make sure your web server is configured to serve the public domain name (and www if applicable).
DNS is not resolving to the edge IP—what should I check?
Propagation, caching, and resolver validationDNS updates can take time to propagate. Verify the record at your DNS provider, check using public resolvers, and flush local DNS caches. If you still see the old value, you may be hitting caching or a higher TTL than expected.
I'm seeing SSL certificate errors after switching DNS—what do I do?
Certificate issuance prerequisitesAfter DNS points to our edge, certificate provisioning starts automatically and typically completes quickly. If errors persist, confirm DNS is correctly pointed, ensure port 80 is reachable for HTTP validation, and verify any CAA records are not blocking issuance.
My site isn't loading after the DNS change—what's the fast checklist?
Origin health, backend settings, firewall, and vhost configIf you see errors after cutover, confirm the origin is healthy, verify the backend IP and port in site settings, ensure your origin firewall allows our edge IPs, and confirm your web server is configured to serve your domain. You can also test the origin directly while setting the Host header to isolate vhost issues.
Some subdomains are protected and others aren't—why?
Each hostname needs its own record and configurationEach hostname needs its own DNS record pointing to our edge. Confirm each subdomain record is updated and propagated, and ensure the hostname is configured appropriately in the dashboard (or covered by any wildcard approach you’re using).
What's the safest migration strategy for production?
Staged migration with monitoring and rollback readinessStart with staging, test thoroughly, lower production TTL, perform the DNS cutover during a low-traffic window, and monitor closely for the first hour and then for 24–48 hours. Keep the original DNS values documented for fast rollback.
Can I test routing through the edge before changing public DNS?
Use a local hosts file entryYes. You can temporarily map your domain to the edge IP in your local hosts file to test the end-to-end request flow without changing public DNS. Remove the entry after testing.
What are the key DNS best practices you recommend?
Operational habits that reduce riskUse low TTL during setup, verify propagation with external resolvers, test that WAF blocking works after cutover, monitor logs for false positives, and restrict origin access to our edge IPs once stable. Schedule DNS changes during low-traffic periods and keep rollback steps documented.