DNS Configuration Guide

Proper DNS configuration is essential for routing traffic through AtomicEdge protection. This guide covers DNS setup, verification, and common issues.

Prerequisites

Before configuring DNS:

  • Add your site in the AtomicEdge management interface
  • Note the provided edge endpoint IP addresses
  • Have access to your domain’s DNS management interface
  • Know your origin server’s IP address

Basic DNS Setup

A Record Configuration

For standard domain protection, create an A record:

Type: A
Name: @ (or subdomain)
Value: [provided-edge-ip]
TTL: 300 (5 minutes recommended during setup)

If your site uses www subdomain:

Type: A
Name: www
Value: [provided-edge-ip]
TTL: 300

CNAME Configuration

For subdomain protection, CNAME records can be used:

Type: CNAME
Name: [subdomain]
Value: [provided-endpoint-hostname]
TTL: 300

Note: CNAME records cannot be used for root domains (@). Use A records for root domain protection.

Advanced Configuration

Multiple Endpoints

For redundancy, you can configure multiple A records pointing to different edge endpoints:

Type: A
Name: @
Value: [edge-ip-1]
TTL: 300

Type: A
Name: @
Value: [edge-ip-2]
TTL: 300

DNS clients will typically round-robin between the provided addresses.

IPv6 Support

If your origin supports IPv6, add AAAA records:

Type: AAAA
Name: @
Value: [provided-ipv6-address]
TTL: 300

Subdomain Protection

Protect specific subdomains while leaving others direct:

# Protected subdomain
Type: A
Name: api
Value: [edge-ip]
TTL: 300

# Direct subdomain (not protected)
Type: A
Name: internal
Value: [origin-ip]
TTL: 300

Verification

DNS Propagation Check

After configuring DNS, verify propagation:

dig example.com A +short

Expected output should show the edge endpoint IP, not your origin IP.

Check from multiple locations:

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short

HTTP Response Verification

Test that traffic routes through AtomicEdge:

curl -I https://example.com

Response headers may include WAF-related information. Verify your origin content is served correctly.

WAF Protection Test

Test that WAF protection is active:

curl -I "https://example.com/?test=../../etc/passwd"

Expected result: 403 Forbidden or configured block response.

TTL Considerations

During Setup

Use low TTL values (300 seconds) during initial setup to allow quick rollback if issues occur.

After Verification

Once protection is verified working correctly, increase TTL to reduce DNS query load:

TTL: 3600 (1 hour) for active sites
TTL: 86400 (24 hours) for stable production sites

Emergency Rollback

If you need to bypass AtomicEdge protection quickly:

  1. Change DNS records back to origin IP
  2. Low TTL ensures faster propagation
  3. Some clients may cache longer than TTL
  4. Consider maximum client cache time in planning

Origin Server Configuration

IP Whitelisting

Configure your origin firewall to only accept traffic from edge endpoint IPs. This prevents attackers from bypassing protection by directly accessing your origin IP.

Example iptables rule:

# Allow edge endpoint
iptables -A INPUT -p tcp -s [edge-ip] --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -s [edge-ip] --dport 443 -j ACCEPT

# Drop other HTTP/HTTPS traffic
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP

For nginx, use allow/deny directives:

allow [edge-ip];
deny all;

Backend Protocol

Configure whether edge endpoints connect to your origin via HTTP or HTTPS in site settings:

  • HTTP: Simpler, lower overhead, suitable when edge and origin are on trusted network
  • HTTPS: Required if origin is on public internet or compliance mandates encryption

Host Header Handling

Edge endpoints forward the original Host header to your origin. Ensure your web server is configured to accept requests with your public domain name, not just localhost or internal hostnames.

Apache example:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    # ... other directives
</VirtualHost>

Nginx example:

server {
    listen 80;
    server_name example.com www.example.com;
    # ... other directives
}

Troubleshooting

DNS Not Resolving to Edge IP

Check propagation time – DNS changes can take up to 48 hours to fully propagate globally, though typically complete within minutes to hours.

Clear local DNS cache:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache

# Linux
sudo systemd-resolve --flush-caches

SSL Certificate Errors

After DNS configuration, SSL certificate provisioning begins automatically. Initial certificate issuance may take 1-5 minutes.

If certificate errors persist:

  1. Verify DNS is correctly pointed to edge endpoint
  2. Ensure port 80 is accessible for HTTP validation
  3. Check for CAA records that might block certificate issuance

Site Not Loading

If your site returns errors after DNS configuration:

  1. Verify origin server is running and accessible
  2. Check backend IP is correctly configured in site settings
  3. Ensure origin firewall allows edge endpoint IPs
  4. Verify origin web server is configured to accept your domain name

Test direct origin connectivity:

curl -H "Host: example.com" http://[origin-ip]/

Partial Protection

If some subdomains are protected but others are not:

  1. Verify each subdomain has its own DNS record
  2. Check that all subdomains are added as sites or use wildcard configuration
  3. Confirm DNS propagation for each subdomain individually

Migration Strategy

Staged Migration

For production sites, use a staged approach:

  1. Set up protection for staging environment first
  2. Test thoroughly with staging DNS
  3. Verify all functionality works correctly
  4. Lower production TTL values
  5. Update production DNS during low-traffic period
  6. Monitor closely for the first hour
  7. Keep origin IP documented for emergency rollback

Testing Before Production

Create a hosts file entry to test before changing public DNS:

# /etc/hosts or C:\Windows\System32\drivers\etc\hosts
[edge-ip] example.com

This allows you to test the full request flow through edge protection without affecting public DNS.

Rollback Plan

Always have a rollback plan:

  1. Document original DNS configuration
  2. Keep origin IP accessible and running
  3. Have credentials ready to change DNS quickly
  4. Consider keeping low TTL for first 24-48 hours
  5. Monitor error rates and performance metrics

Best Practices

  1. Use low TTL during setup and testing
  2. Implement origin IP whitelisting after DNS is stable
  3. Test WAF protection after DNS changes
  4. Monitor logs for false positives in the first hours
  5. Document your DNS configuration for team reference
  6. Set up monitoring alerts for DNS resolution failures
  7. Plan DNS changes during low-traffic periods
  8. Keep your origin IP private to prevent bypass attempts