在 Amazon Route53 中设置基于 DNS 的 URL 转发 [英] Set up DNS based URL forwarding in Amazon Route53

查看:40
本文介绍了在 Amazon Route53 中设置基于 DNS 的 URL 转发的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试在 Amazon Route53 中设置转发.我的最后一个 DNS 服务 (Nettica) 允许我将请求路由到aws.example.com"到https://myaccount.signin.aws.amazon.com/console/".

Route53 是否支持此功能?

Nettica 是如何做到这一点的?它是否插入了特殊的 A、CNAME、PTR 或 TXT 记录?

解决方案

我遇到了与 Saurav 描述的完全相同的问题,但我确实需要找到一个解决方案,除了 Route 53 和 S3 之外不需要任何其他东西.我为我的博客创建了一个操作指南,详细说明了我做了什么.

这是我想出来的.

<小时>

目标

仅使用 Amazon S3 和 Amazon Route 53 中可用的工具,创建自动转发 .额外的技术(此处未介绍)是转发到目标主机上的特定页面,例如 http://redirect-destination.com/console/special-page.html.如果您需要此功能,请阅读 元素.

<小时>

第 4 步:记下重定向存储桶的端点"

记下亚马逊为此存储桶自动创建的静态网站托管端点".稍后您将需要它,因此请突出显示整个 URL,然后将其复制并粘贴到记事本中.

注意!此时您实际上可以单击此链接来检查您的重定向规则是否输入正确,但要小心!这就是为什么...

假设您在重定向规则的 标签中输入了错误的值.也许您不小心输入了 myaccount.amazon.com,而不是 myaccount.signin.aws.amazon.com.如果您单击链接来测试端点 URL,AWS 会很乐意将您的浏览器重定向到错误的地址!

注意到您的错误后,您可能会在重定向规则中编辑 以修复错误.不幸的是,当您再次尝试单击该链接时,您很可能最终会被重定向回错误的地址!即使您修复了 条目,您的浏览器也会缓存前一个(不正确!)条目.发生这种情况是因为我们使用的是 HTTP 301(永久)重定向,Chrome 和 Firefox 等浏览器默认会缓存.

如果您将端点 URL 复制并粘贴到其他浏览器(或清除当前浏览器中的缓存),您将再次有机会查看更新后的 条目是否为终于正确了.

为安全起见,如果您想测试您的端点 URL 和重定向规则,您应该打开一个隐私浏览会话,例如 Chrome 中的隐身模式".在隐身模式下复制、粘贴和测试端点 URL,一旦您关闭会话,缓存的任何内容都会消失.

<小时>

步骤 5:打开 Route53 管理控制台并转到您的托管区域(域名)的记录集

  1. 选择您在创建存储桶时使用的托管区域(域名).由于我将存储桶命名为url-redirect-example.vivekmchawla.com",因此我将选择 vivekmchawla.com 托管区域.
  2. 点击转到记录集"按钮.

<小时>

步骤 6:单击创建记录集"按钮

单击创建记录集"将打开 Route53 管理控制台右侧的创建记录集"窗口.

<小时>

步骤 7:创建 CNAME 记录集

  1. 在名称字段中,输入您在命名 S3 存储桶时使用的 URL 的主机名部分.URL 的主机名部分"是托管区域名称左侧的所有内容.我将我的 S3 存储桶命名为url-redirect-example.vivekmchawla.com",而我的托管区域是vivekmchawla.com",因此我需要输入的主机名部分是url-redirect-example".

  2. 为此记录集的类型选择CNAME - 规范名称".

  3. 对于值,粘贴我们在第 3 步中创建的 S3 存储桶的端点 URL.

  4. 单击创建记录集"按钮.假设没有错误,您现在可以在托管区域的记录集列表中看到新的 CNAME 记录.

<小时>

第 8 步:测试您的新 URL 重定向

打开一个新的浏览器选项卡并输入我们刚刚设置的 URL.对我来说,这是

  • 为网站托管配置存储桶
  • 创建使用 Route 53 的域
  • 创建、更改和删除资源记录莉>

    干杯!

    I'm trying to setup forwarding in Amazon Route53. My last DNS service (Nettica) allowed me to route requests to "aws.example.com" to "https://myaccount.signin.aws.amazon.com/console/".

    Is this functionality supported by Route53?

    How does Nettica achieve this? Does it insert a special A, CNAME, PTR, or TXT record(s)?

    解决方案

    I was running into the exact same problem that Saurav described, but I really needed to find a solution that did not require anything other than Route 53 and S3. I created a how-to guide for my blog detailing what I did.

    Here is what I came up with.


    Objective

    Using only the tools available in Amazon S3 and Amazon Route 53, create a URL Redirect that automatically forwards http://url-redirect-example.vivekmchawla.com to the AWS Console sign-in page aliased to "MyAccount", located at https://myaccount.signin.aws.amazon.com/console/ .

    This guide will teach you set up URL forwarding to any URL, not just ones from Amazon. You will learn how to set up forwarding to specific folders (like "/console" in my example), and how to change the protocol of the redirect from HTTP to HTTPS (or vice versa).


    Step One: Create Your S3 Bucket

    Open the S3 management console and click "Create Bucket".


    Step Two: Name Your S3 Bucket

    1. Choose a Bucket Name. This step is really important! You must name the bucket EXACTLY the same as the URL you want to set up for forwarding. For this guide, I'll use the name "url-redirect-example.vivekmchawla.com".

    2. Select whatever region works best for you. If you don't know, keep the default.

    3. Don't worry about setting up logging. Just click the "Create" button when you're ready.


    Step 3: Enable Static Website Hosting and Specify Routing Rules

    1. In the properties window, open the settings for "Static Website Hosting".
    2. Select the option to "Enable website hosting".
    3. Enter a value for the "Index Document". This object (document) will never be served by S3, and you never have to upload it. Just use any name you want.
    4. Open the settings for "Edit Redirection Rules".
    5. Paste the following XML snippet in it's entirety.

      <RoutingRules>
        <RoutingRule>
          <Redirect>
            <Protocol>https</Protocol>
            <HostName>myaccount.signin.aws.amazon.com</HostName>
            <ReplaceKeyPrefixWith>console/</ReplaceKeyPrefixWith>
            <HttpRedirectCode>301</HttpRedirectCode>
          </Redirect>
        </RoutingRule>
      </RoutingRules>
      

    If you're curious about what the above XML is doing, visit the AWM Documentation for "Syntax for Specifying Routing Rules". A bonus technique (not covered here) is forwarding to specific pages at the destination host, for example http://redirect-destination.com/console/special-page.html. Read about the <ReplaceKeyWith> element if you need this functionality.


    Step 4: Make Note of Your Redirect Bucket's "Endpoint"

    Make note of the Static Website Hosting "endpoint" that Amazon automatically created for this bucket. You'll need this for later, so highlight the entire URL, then copy and paste it to notepad.

    CAUTION! At this point you can actually click this link to check to see if your Redirection Rules were entered correctly, but be careful! Here's why...

    Let's say you entered the wrong value inside the <Hostname> tags in your Redirection Rules. Maybe you accidentally typed myaccount.amazon.com, instead of myaccount.signin.aws.amazon.com. If you click the link to test the Endpoint URL, AWS will happily redirect your browser to the wrong address!

    After noticing your mistake, you will probably edit the <Hostname> in your Redirection Rules to fix the error. Unfortunately, when you try to click the link again, you'll most likely end up being redirected back to the wrong address! Even though you fixed the <Hostname> entry, your browser is caching the previous (incorrect!) entry. This happens because we're using an HTTP 301 (permanent) redirect, which browsers like Chrome and Firefox will cache by default.

    If you copy and paste the Endpoint URL to a different browser (or clear the cache in your current one), you'll get another chance to see if your updated <Hostname> entry is finally the correct one.

    To be safe, if you want to test your Endpoint URL and Redirect Rules, you should open a private browsing session, like "Incognito Mode" in Chrome. Copy, paste, and test the Endpoint URL in Incognito Mode and anything cached will go away once you close the session.


    Step 5: Open the Route53 Management Console and Go To the Record Sets for Your Hosted Zone (Domain Name)

    1. Select the Hosted Zone (domain name) that you used when you created your bucket. Since I named my bucket "url-redirect-example.vivekmchawla.com", I'm going to select the vivekmchawla.com Hosted Zone.
    2. Click on the "Go to Record Sets" button.


    Step 6: Click the "Create Record Set" Button

    Clicking "Create Record Set" will open up the Create Record Set window on the right side of the Route53 Management Console.


    Step 7: Create a CNAME Record Set

    1. In the Name field, enter the hostname portion of the URL that you used when naming your S3 bucket. The "hostname portion" of the URL is everything to the LEFT of your Hosted Zone's name. I named my S3 bucket "url-redirect-example.vivekmchawla.com", and my Hosted Zone is "vivekmchawla.com", so the hostname portion I need to enter is "url-redirect-example".

    2. Select "CNAME - Canonical name" for the Type of this Record Set.

    3. For the Value, paste in the Endpoint URL of the S3 bucket we created back in Step 3.

    4. Click the "Create Record Set" button. Assuming there are no errors, you'll now be able to see a new CNAME record in your Hosted Zone's list of Record Sets.


    Step 8: Test Your New URL Redirect

    Open up a new browser tab and type in the URL that we just set up. For me, that's http://url-redirect-example.vivekmchawla.com. If everything worked right, you should be sent directly to an AWS sign-in page.

    Because we used the myaccount.signin.aws.amazon.com alias as our redirect's destination URL, Amazon knows exactly which account we're trying to access, and takes us directly there. This can be very handy if you want to give a short, clean, branded AWS login link to employees or contractors.


    Conclusions

    I personally love the various AWS services, but if you've decided to migrate DNS management to Amazon Route 53, the lack of easy URL forwarding can be frustrating. I hope this guide helped make setting up URL forwarding for your Hosted Zones a bit easier.

    If you'd like to learn more, please take a look at the following pages from the AWS Documentation site.

    Cheers!

    这篇关于在 Amazon Route53 中设置基于 DNS 的 URL 转发的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

  • 查看全文
    登录 关闭
    扫码关注1秒登录
    发送“验证码”获取 | 15天全站免登陆