0

Heroku in their docs talk about why you should avoid naked domains if you are dependent on IaaS or PaaS.

There is also an existing question on ServerFault, but it doesn't tackle my query.

I have understood their explanation. The part I am confused about is the caching of the ip. Heroku claims they can change the ip of their endpoint in their DNS settings and all will be good. However, don't most browsers/proxies/clients cache that ip? TTL values are not always respected. Also how quickly does that ip get propagated? Wouldn't the requests still go to the old ip?

Community
  • 1
Amith George
  • 135
  • 1
  • 6
  • DNS resolvers and clients ignore TTLs *at their own risk*. If they're still hitting the old IP address after the TTL should have expired, it's their own fault. – Ladadadada Apr 23 '13 at 11:03

2 Answers2

3

You can use a CNAME for, say, www.example.com, so that it points to magic-squirrel.herokuapp.com (or whatever). magic-squirrel.herokuapp.com will resolve to whatever IP Heroku has assigned to that end point, for example, 1.1.1.1. That IP can change if Heroku needs to do some network reconfiguration, but magic-squirrel.herokuapp.com will be updated to point to, say, 2.2.2.2. www.example.com will follow naturally, after TTL expiration. In this case, you won't have a service disruption because of something Heroku did to manage their network.

You cannot use a CNAME for example.com, the naked domain. You instead will need to use an A record. As above, your app is running on magic-squirrel.herokuapp.com, which has an A record of 1.1.1.1. Because you can't CNAME to that name, you will have to create an A record for example.com to point to 1.1.1.1. Sometime later, Heroku does their network configuration, and magic-squirrel.herokuapp.com now points to 2.2.2.2. Your example.com is now mysteriously broken. You will need to notice that magic-squirrel.herokuapp.com no longer is on 1.1.1.1 and update your DNS accordingly.

cjc
  • 24,533
  • 2
  • 49
  • 69
  • I understand the rationale behind doing this. My question is, for a certain duration of time, ie while the old ip 1.1.1.1 is cached by the resolvers, the users still endup going to the old ip. Certain proxies/browsers might not respect the TTL and still resolve to the old ip. I am trying to understand if Heroku is able to bypass this somehow, or this is considered acceptable. – Amith George Apr 22 '13 at 22:33
  • I'm pretty sure Heroku doesn't do anything with the traffic misdirected to the old IP; I believe it's just assumed to be acceptable (it's the Cloud!! and http://cdn.memegenerator.net/instances/400x/21646781.jpg) – cjc Apr 22 '13 at 22:40
1

Even though the CNAME might have a high TTL, the cached value is the alias, not the IP behind the alias(or at least should be the alias).

So while having a higher TTL on the CNAME to make use of caches, the target of the CNAME can have a very low TTL to allow changing it more often and especially allow to change it automatically without touching your own DNS records.

Izzy
  • 786
  • 2
  • 8
  • 29