Home > Technical & Creative Skills > Programming, Servers & Scripts

---

Using Route 53 As Your DNS - Boosting Performance Where Few Affiliates Bother (34)

---

Though hosting and page load speed is a big topic when it comes to mobile marketing, still very few affiliates bother to optimize the request times of their DNS servers. This is a quick solution that can be used for any hosting but is especially well integrated with Amazon's popular CDN, CloudFront.

What is Route 53?

Amazon Route 53 (Route 53) is part of Amazon.com's cloud computing platform, Amazon Web Services (AWS). Route 53 provides a scalable and highly available Domain Name System (DNS).

In translation, it’s a service from Amazon that is much better than your average DNS.

Why use Route 53?

If you are running anything that requires speed, you want to optimize each step. Your domains should not stay on the default slow DNS of the registrar or hosting provider.

This especially applies for mobile pops but it’s useful everywhere. Here’s the difference it can make.

You can run this test at http://dyn.com/free-dns-test/

KEEP IN MIND: All your domains are affected by this so you should put your tracking domains on this too, where possible (depends on the tracking solution you use).

How Do You Actually Use It?

1. Go to the AWS dashboard and select Route 53:
2. Go to Hosted Zones and click Create Hosted Zone.
3. Input your domain name that you are going to use and click Create.
4.If you are combining it with CloudFront (see this tutorial):
5. Replace your DNS entries at your registrar’s to use the Route 53 NS records. On Namecheap it would look like this:

After you’ve made these changes, give it 15 minutes or so for changes to propagate. Sometimes it’s quicker, sometimes slower unfortunately. Give the test another try and see the difference. Please note, first time you do this, use a domain that is not live and receiving campaign traffic. You want to get it right and then switch your live domains to it.

Something to pay attention to:
I haven't experienced this myself but you should keep it in mind if it happens after doing all the steps correctly

---

Great post!

And this approach works particularly well with Amazon S3 hosting, as per our currently recommended approach for static landing pages: https://stmforum.com/forum/showthrea...-Cost-Way-Ever!

---

Thanks for the great guide Manu.

Would it be the case to move the to Route 53 from NS1? Would this improve click loss?

---

What do you mean by NS1? Route53 should reduce clickloss, yes, because you don't time out requests as often.

---

I'm using NS1 for DNS queries not registrar's DNS. I wanted to know if there is any performance comparison between the two at least on our usage level (including trials).

---

Run the test I linked above and see if it gets the same or better results: http://dyn.com/free-dns-test/ Then you have your answer

---

Thanks for the tip. Most people don't even think of DNS lookups as latency but it is noticeable as you say.

Question: Could you also get the same effect using raw IP addresses instead of domain names, and skipping the DNS lookups altogether?

For URLs that users see, you wouldn't wanna use raw IPs, since obviously it looks sketchy.

But what about for hosting other assets on the page? Maybe it makes things more likely to be tagged as dangerous by third parties like GeoEdge or Chrome but that's the only downside I can see.

Thoughts?

---

Flagging is certainly an issue. If you request an asset from an IP, then any page that requests anything from the same IP will get flagged very quickly I think... The only thing is that perhaps if the IP doesn't get flagged, it stays OK.

I think there might be something interesting there, but it doesn't sound like it can scale nicely, unless you know how to build a tool to manage this. If you rely mostly on people to make these landing page setups, it seems to not be worth it.

Maybe someone with more tech knowledge can chime in here

---

I don't have any solid knowledge on this, but from theory only I can't see why using bare IPs would get them flagged much faster than using domains.

All the Usual Suspects can perfectly easily look up the IP from the DNS anyway. Were I them, I'd probably keep a database of "suspicious" IPs connected to flagged content, and if the IP shows up a few times, flag anything on there.

There is a chance that the mere presence of IP-based addresses will trigger a threat warning, but I don't see that as too likely either unless there's a very solid reason phishing or other genuine threat pages would tend to use bare IP over domain.

Just some speculation!

---

Thanks for this amazing guide! Very simple and clear to understand (especially for people like me!)

Quick question: In caurmen's incredible guide, I followed exactly on how to set up CDN on Amazon S3, and

And following the guide, on Namecheap's How To Set Up CNAME Record >>> https://www.namecheap.com/support/kn...-for-my-domain
I set up my CNAME as per below's settings


When I am setting up Custom DNS as per your guide - I don't need to remove the settings in my Advanced DNS (the image above) right? Would just like to confirm this fact @.@

---

Yes, you would remove that and "replace" it by step 4c, where you add that address in Route 53's settings.

LE: I think once you add the Custom DNS, the Advanced DNS settings already get negated, since everything will be done by Route 53. I have never tried that myself, I only did what I needed, but thought I'd mention it...

---

One more question:

I would just like to confirm that Alias Target is this domain here right?


Because in the list it only showed up >>>


So in the end I went to AMAZON CloudFront Distributions to retrieve the Domain Name
I'd just like to check on this, to make sure I'm doing everything right! (I'm not too good at tech stuff hahaha - still learning)


And yes, you're right!

Just for anyone in future who's referring to this thread, Advanced DNS is already negated automatically and you should see this when you access Advanced DNS

---

I usually copy/paste the domain there. And yes, it is the correct one. The reason I do this is just so it's using CloudFront and not the local one for the bucket. If check the picture, the one you are hovering over is an S3 endpoint. You need the CloudFront domain from the first picture!

It should work just by simply copy/pasting

---

Update: I followed all the steps as you described exactly, and have not touched it since 24 hours ago
Today when I tried loading my LPs, this error came out


Is there any settings I can check on my end to show you?

---

It worked before and doesn't work now?

Try to visit your LP by using the CloudFront domain directly first and see if that works. That can tell us where the broken link is.

---

Previously I did not try the url after I changed the settings

This is when I type my URL into the URL bar (this just happened now - which is now, strangely, a different screen from the above SS)



When I type my cloudfront URL,

---

Hmm - have you perhaps uploaded an index file into your S3 bucket and forgotten to set it public? That'd be the usual time you'd see this error.

What happens if you copy the address from the "Origin" field in Cloudfront and paste it into your URL bar on your browser?

---

Thank you caurmen for your reply

I've set my index.html to public - still same error

And here's my "Origin" field in my URL bar


I have never set my index.html to "Public" before, because previously I was just directing it straight to my LP
And here's the screen of my LP URL - still same error



@.@

---

Hmmm, did you add this permission to the bucket?

---

I have not done this step before -
Could you guide me how to do it?

I'm currently at this screen
(Replaced and blurred OWNER NAME & BUCKET NAME respectively)

---

OK, click on Edit Bucket Policy and add that text, replacing MYBUCKET with your bucket name. That is what allows your bucket to be accessible, so it's likely that's the cause of the error. Fingers crossed!

---

Unfortunately, when I opened Edit Bucket Policy, it was already in that state


However, I tried copying and pasting the code you gave and tried Saving


This was what I got - not able to Save - when I compared the differences, it's because of the extra "]"

@.@

There is 1 thing I noticed though:

When i enter into URL bar:
www.DOMAIN.com, the below appeared


VS

When I enter
DOMAIN.com (no www)


Does that help or shed any clues?
I was so hoping for this to work out for me!

(Hope it can be resolved soon - even though I can't access my page physically, but when I check my Pingdom's timings, they are finally looking much better after I changed to Route53 DNS)

---

Hmmm, something strange I noticed is the permissions for my pages now are not the same as in the documentation (where I took that from).

It's now this: http://pastebin.com/ZXzywa18 (the link expires in 1 week).

You can try with that.

If that doesn't work, can you show us your CloudFront settings please?

---

We use Cloudflare. Get the same speeds and don't have to deal with SSL's.

This works on the free account.

Just as another option

---

Cloudflare's definitely worth testing. Remember to set a Page Rule for "Cache All" though.

---

I've tried with that - still no difference

Thanks for the tip!

---

It's strange, CloudFront seems fine. It seems just something with the bucket policy/setting to be honest. Because the bucket is not letting any file go public, denies all requests. Can you also check that please?

And given the fact that the documentation from Amazon where I copied from has different JSON for the policy than what our working buckets have, I am thinking that Amazon has been changing some stuff we don't understand.

---

@aloeveraa1491 the problem seems to be the Default Root Object which is not specified.
You are trying to route traffic from www.yourdomain.com to a CloudFront link that doesn't know where to go to satisfy your request. Try adding in the end of the link the html file path you are trying to access and see if it resolves your problem.

---

Here's a list of all the Screenshots of settings, bucket policies I've took

The only differences I noticed are:

> The position of my Custom DNS (in NameCheap) which I copy and paste changed (either that, or the 4x Route53 NS values changed their order of positioning) Does that affect anything?

> In Route53 the Alias targets and NS values always seem to keep generating the "." behind it

> Bucket Policy I used as per your settings (Sid Addperm)

> In Namecheap, my Advanced DNS has no other settings, due to it being cancelled off by choosing Custom DNS

> (Some findings) When I loaded my cloudfront URL (xxxxx.cloudfront.net) it works perfectly fine as normal - even all my LPs are can be accessed! (xxxxx.cloudfront.net/landingpage.html)

Maybe if we're stuck here - are you able to help me ask Amazon on this? Because mine's the free S3 plan so I can't have a chance to reach their support team @.@

Also - I'd just like to express my thanks to you for helping me so consistently on this issue! Without you and the rest, I'll probably be doomed at this stage hahah


Thank you for your tips! I've changed the Default Root Object to index.html - but it's still not working

---

You're welcome! Good luck with the traffic now!

---

Hey manu_adefy, thanks for the great guide. A quick question though

For step (4)
Set Type as A, Alias Target as your CloudFront domain name

What's the difference if I set my Alias target as S3 Website Endpoint instead?

I am trying to create a homepage www.mydomain.com (set to my index.html page on S3 Static Website Hosting）
If I set to Cloudfront Domain Name (Alias Target), then I won't be able to access my homepage www.mydomain.com

---

Oh, that's a small omission on my side, sorry.

You can set your S3 end point too. I have a small website doing that, but for affiliate campaigns, you basically need CloudFront (or another CDN), and I just combined it with caurmen's tutorial that I linked.

That's why I said "If you are using CloudFront".

The only differences are those brought by global performance from CloudFront vs S3.

---

Thanks for the heads up

Is there a way to have a homepage www.mydomain.com and still be able to link Route 53 to Cloudfront?

I get the feeling that if I want to link Route 53 to Cloudfront (for performance purposes), then my only choice is to have my homepage as www.mydomain.com/index.html which looks very unprofessional

update:
I went to explore Route53 and I saw that you can actually link ipv6 to Cloudfront distribution and ipv4 to the S3 endpoint. Is this a viable solution?

---

I don't know about the ipv4 and ipv6 possibilities so don't want to give a wrong answer.

Regarding /index.html, I only used this setup for landing pages where I never used index.html - was always some name for the LP so not sure what the solution is there, unfortunately.

---

Home > Technical & Creative Skills > Programming, Servers & Scripts