This article provides step-by-step guidance for Setting Up DNS on Google Cloud to support Redis clusters. It includes instructions for Choosing a Cluster FQDN, configuring DNS records via Google Cloud DNS, finalizing Cluster Setup, handling Alternative Load Balancer Options, resolving Common DNS Issues, and Additional Resources. The guide ensures high availability and reliable node discovery via FQDN-based resolution.
Prerequisites
- A Google Cloud project with Cloud DNS enabled
- An existing hosted zone (e.g.,
demo.redislabs.com) - External/public IP addresses for all Redis Enterprise nodes
- Permissions to create and modify DNS records in Google Cloud DNS
Step-by-Step: DNS Setup on Google Cloud
- Choose and Set the Cluster FQDN
-
Configure FQDN During Installation
- During Redis setup, enter the selected FQDN in the Cluster Name / FQDN field.
- Redis nodes will act as authoritative DNS servers for the delegated subdomain.
See Configure Cluster DNS for more details.
-
Access Google Cloud DNS
- Open the Google Cloud DNS Console.
- Click on your existing DNS zone (e.g.,
demo.redislabs.com).
-
Create an NS Record for the Redis Cluster
- Record Name:
mycluster(subdomain of your DNS zone) - Record Type: NS
- TTL: 300
- Data:
node1.mycluster.b12.labnode2.mycluster.b12.labnode3.mycluster.b12.lab
- Record Name:
-
Create A Records for Cluster Nodes
-
Add an A record for each Redis node in the same zone (
b12.lab):node1.mycluster.b12.lab A [External IP of node 1] node2.mycluster.b12.lab A [External IP of node 2] node3.mycluster.b12.lab A [External IP of node 3]
-
-
Verify DNS Propagation
-
Use
dig,host, ornslookupto confirm your FQDN resolves from external/internal clients:dig node1.mycluster.b12.labhost redis-12345.mycluster.example.comYou can also use an online DNS Propagation Checker to verify resolution globally.
-
-
Finalize Redis Cluster Setup
-
Once DNS records have been propagated, Redis automatically generates FQDN-based database endpoints such as:
redis-12345.mycluster.b12.lab
- Applications connect using these endpoints. Internal DNS resolution supports automatic failover and high availability.
-
Alternative: Use a Load Balancer (Optional)
- If DNS setup isn't feasible, you may place a load balancer in front of your Redis nodes.
- This method reduces feature parity (e.g., no transparent shard migration or dynamic endpoints) but provides a DNS-less access path.
Troubleshooting Common Issues
| Issue | Cause | Resolution |
|---|---|---|
| DNS not resolving | Missing or misconfigured NS/A records | Recheck both NS and A records for accuracy |
| TTL delays | DNS caching may delay propagation | Wait 24–48 hours or lower TTL temporarily |
| Cannot change FQDN | FQDN is immutable post-installation | Must reinstall the cluster to use a new FQDN |
| DNS breaks on node updates | Records not updated for added/removed nodes | Manually update A/NS records as needed |
| mDNS used in production | mDNS is only for dev/test | Use standard delegated DNS for production |
| CNAME resolution failure | Private DNS limitations on Google Cloud | Avoid CNAMEs pointing outside private zones |
| Multiple DNS servers present | Redis requires a single authoritative DNS | Disable other DNS services on Redis nodes |
0 comments
Please sign in to leave a comment.