<p>It seems a reasonable idea to me.<br />
There migt be a few things you might want to check tho :</p>
<p><a href="https://aws.amazon.com/premiumsupport/knowledge-center/route-53-fix-dns-resolution-issues/?nc1=h_ls" rel="nofollow noreferrer">This article</a> or <a href="https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html" rel="nofollow noreferrer">this one</a>. For example :</p>
<ul>
<li>the fact the that a private hosted zone is associated with a VPC</li>
<li>there is some <em>DNS hostnames</em> and <em>DNS resolution</em> parameters on the VPC settings</li>
</ul>
<blockquote>
<p><strong>enableDnsHostnames</strong> : Indicates whether instances with public IP addresses get corresponding public DNS hostnames<br />
<strong>enableDnsSupport</strong> : Indicates whether the DNS resolution is supported.</p>
</blockquote>
<ul>
<li>Only VPC resolver will resolve the private records (subnet range +2 for the ip of the VPC resolver, search for <em>reserved</em> ip <a href="https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html" rel="nofollow noreferrer">here</a>)
<ul>
<li>take care you didn't configure custom resolver and so wont be able to access your private records</li>
<li>think about the fact that you won't be able to resolve those records from outside the VPC (office for example) unless you manage to plug to the VPC resolver somehow</li>
</ul>
</li>
</ul>
<p>You could also give a look at <a href="https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html" rel="nofollow noreferrer">Alias record</a> ?
Could give advantages like :</p>
<ul>
<li>create record that has the same name as the hosted zone</li>
<li>not being charged for the queries (in opposite to CNAMEs)</li>
</ul>
<p>These are few things I can think off right now. Hope this helps.</p>
<p>Cheers.</p>

CC BY-SA 4.0
2020-11-28T14:05:34.937Z
2020-11-28T14:05:34.937Z
Pierre Benefice
<p>I have a Kubernetes cluster in AWS, with apps that talk to AWS services like RDS, Elasticache, Elasticsearch, DynamoDB, etc.</p>
<p>For the services where it's available (Elasticache and RDS, and more recently Elasticsearch with a custom ACM certificate), I've considered making a private zone in Route53 and making CNAMEs for all the things. So instead of <code>app-production.789yuiahsdf.redis.elastitcache.aws.com</code> or whatever the Elasticache endpoint is, my app talks to <code>sidekiq.redis.app</code>. I'd use a pattern, maybe <code>&lt;purpose&gt;.&lt;service&gt;.&lt;app&gt;</code>, so I'd have <code>sidekiq.redis.app</code>, <code>cache.redis.app</code>, <code>primary.postgres.app</code>, <code>replica.postgres.app</code>, etc, etc.</p>
<p>The next step is having the app is configured by default to use these hosts. In development, staging, and production, they don't NEED any configuration (maybe it's still available), but the defaults should &quot;just work&quot; if the environment is set up properly.</p>
<p><strong>What are the downsides here? What am I missing?</strong> To me, this seems sort of like simple service discovery and a reasonable idea. But reasonable ideas can sometimes bite you later on.</p>

<amazon-web-services><kubernetes><dns>
What reasons should I NOT use a private DNS zone and CNAME services in my AWS/K8s environment?
Daniel Huckstep
# What reasons should I NOT use a private DNS zone and CNAME services in my AWS/K8s environment?

(Asked by: username_0 on 2020-11-28)

I have a Kubernetes cluster in AWS, with apps that talk to AWS services like RDS, Elasticache, Elasticsearch, DynamoDB, etc.

For the services where it's available (Elasticache and RDS, and more recently Elasticsearch with a custom ACM certificate), I've considered making a private zone in Route53 and making CNAMEs for all the things. So instead of `app-production.789yuiahsdf.redis.elastitcache.aws.com` or whatever the Elasticache endpoint is, my app talks to `sidekiq.redis.app`. I'd use a pattern, maybe `..`, so I'd have `sidekiq.redis.app`, `cache.redis.app`, `primary.postgres.app`, `replica.postgres.app`, etc, etc.

The next step is having the app is configured by default to use these hosts. In development, staging, and production, they don't NEED any configuration (maybe it's still available), but the defaults should "just work" if the environment is set up properly.

**What are the downsides here? What am I missing?** To me, this seems sort of like simple service discovery and a reasonable idea. But reasonable ideas can sometimes bite you later on.

**Tags:** amazon-web-services, kubernetes, dns


---

## 1 answers

### Answer by username_1 on 2020-11-28. Score: 1

It seems a reasonable idea to me.  
There migt be a few things you might want to check tho :

[This article](https://aws.amazon.com/premiumsupport/knowledge-center/route-53-fix-dns-resolution-issues/?nc1=h_ls) or [this one](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html). For example :

* the fact the that a private hosted zone is associated with a VPC
* there is some *DNS hostnames* and *DNS resolution* parameters on the VPC settings

> **enableDnsHostnames** : Indicates whether instances with public IP addresses get corresponding public DNS hostnames  
> **enableDnsSupport** : Indicates whether the DNS resolution is supported.

* Only VPC resolver will resolve the private records (subnet range +2 for the ip of the VPC resolver, search for *reserved* ip [here](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html))
  + take care you didn't configure custom resolver and so wont be able to access your private records
  + think about the fact that you won't be able to resolve those records from outside the VPC (office for example) unless you manage to plug to the VPC resolver somehow

You could also give a look at [Alias record](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) ?
Could give advantages like :

* create record that has the same name as the hosted zone
* not being charged for the queries (in opposite to CNAMEs)

These are few things I can think off right now. Hope this helps.

Cheers.


---

