{"id":7182,"date":"2021-01-21T20:17:09","date_gmt":"2021-01-21T20:17:09","guid":{"rendered":"https:\/\/rax-stg-wp-aws.com\/blogs\/how-to-create-a-dynamic-dns-with-the-aws-api-and-route-53\/"},"modified":"2026-11-03T19:28:10","modified_gmt":"2026-11-03T19:28:10","slug":"how-to-create-a-dynamic-dns-with-the-aws-api-and-route-53","status":"publish","type":"blogs","link":"https:\/\/www.rackspace.com\/de\/blogs\/how-to-create-a-dynamic-dns-with-the-aws-api-and-route-53\/","title":{"rendered":"How to create a dynamic DNS with the AWS API and Route 53"},"content":{"rendered":"

Originally published in February 2017, at the Onica blog here<\/a>.<\/em><\/strong><\/p>\n

A few of our cloud engineers were chatting about making a Dynamic DNS on Amazon Web Services; (AWS) for some personal projects. As we got to talking, I realized that although Lambda was the go-to technology, it was not needed. <\/p>\n

Creating an AWS Route 53 Dynamic DNS (with API Gateway in place of Lambda)<\/strong><\/p>\n

You certainly wouldn\u2019t want to give the world access to your AWS account, so we’re making sure to keep the system locked down. However, as this walkthrough shows, you do not need Lambda to create a simple Dynamic DNS in Route 53.<\/p>\n

Our example assumes you already have a domain hosted in Route 53 and use acme.local<\/strong> as the domain name.<\/p>\n

Step 1: Create your API Gateway and resource<\/strong><\/p>\n

Create your API Gateway and give it a description. I called mine, DynamicDNS<\/strong>.
\nCreate the resource: {zone_id}<\/em>. For this exercise, I\u2019m using a little bit of security through obscurity<\/em> by requiring the Route 53 Zone ID in the URL path. I use the `https:\/\/api_gw_url\/route53_zone_id<\/a>` as the URL for updating.<\/p>\n

Step 2: Create the method<\/strong><\/p>\n

I want the simplest HTTP request possible because I want to be able to use this anywhere. So, I create a `GET`
\nrequest and map the request to the AWS Service, Route 53. This is where all of the magic happens.<\/p>\n

Perform the following steps:<\/p>\n

    \n
  1. Create a GET request for the \/{zone_id}<\/em> resource.<\/li>\n
  2. Set it to AWS Service<\/em>.<\/li>\n
  3. Set the Region<\/strong> to whatever you want. I used us-west-2<\/em>, but it doesn\u2019t matter with Route53.<\/li>\n
  4. Set the service<\/strong> to Route 53<\/em>.<\/li>\n
  5. Leave the AWS Subdomain<\/strong> blank.<\/li>\n
  6. Set the HTTP Method<\/strong> to POST<\/em>. This is the method that the AWS service API expects. You can read more about it here: Change Resource Record Rates<\/a>.<\/li>\n
  7. You need to use a custom path to use the {zone_id}<\/em> variable, so set Action Type<\/strong> to Use path override.<\/em><\/li>\n
  8. Reading the API docs linked in step 6, you can see you need to ultimately use the path \/2013-04-01\/hostedzone\/<Id>\/rrset\/<\/em>, so set the Path Override to: \/2013-04-01\/hostedzone\/{hosted_zone_id}\/rrset\/<\/em>. I explain why I used {hosted_zone_id}<\/em> instead of {zone_id}<\/em> a bit further down in this post.<\/li>\n
  9. Give it an IAM role. The IAM role needs the following trust relationship and role:<\/li>\n<\/ol>\n

    Trust relationship<\/strong><\/p>\n

      {
    \n     “Version”: “2012-10-17”,
    \n     “Statement”: [
    \n        {
    \n         “Sid”: “”,
    \n         “Effect”: “Allow”,
    \n         “Principal”: {
    \n            “Service”: “apigateway.amazonaws.com”
    \n         },
    \n         “Action”: “sts:AssumeRole”
    \n        }
    \n     ]
    \n    }<\/p>\n

    Role<\/strong><\/p>\n

      <\/strong> {
    \n     “Version”: “2012-10-17”,
    \n     “Statement”: [
    \n        {
    \n         “Sid”: “Stmt1487876360000”,
    \n         “Effect”: “Allow”,
    \n         “Action”: [
    \n            “route53:ChangeResourceRecordSets”
    \n         ],
    \n         “Resource”: [
    \n            “arn:aws:route53:::hostedzone\/Z1BZA5RDXLSXJ1”
    \n         ]
    \n        }
    \n     ]
    \n    }<\/p>\n

    Role<\/strong><\/p>\n

       {
    \n     “Version”: “2012-10-17”,
    \n     “Statement”: [
    \n        {
    \n         “Sid”: “Stmt1487876360000”,
    \n         “Effect”: “Allow”,
    \n         “Action”: [
    \n            “route53:ChangeResourceRecordSets”
    \n         ],
    \n         “Resource”: [
    \n            “arn:aws:route53:::hostedzone\/Z1BZA5RDXLSXJ1”
    \n         ]
    \n        }
    \n     ]
    \n    }<\/p>\n

    Note<\/strong>: Make sure to change the actual Zone ID above, replacing `Z1BZA5RDXLSXJ1` with your Zone ID.<\/p>\n

    Step 3: Configure body mapping templates<\/strong><\/p>\n

    You still have more work to do with the method because it does not send the Route 53 API any actual data.<\/p>\n

      \n
    1. Click on the GET<\/em> Method on the left panel under Resources<\/strong>.<\/li>\n
    2. Click on the Integration Request<\/strong> header.<\/li>\n
    3. Scroll down to Body Mapping Templates<\/strong> and expand it.<\/li>\n
    4. Change the Request body passthrough<\/strong> to Never. This prevents any data from passing into the AWS API. This is the single most important thing you can do to secure your AWS account for this exercise, as I discuss later.<\/li>\n
    5. Create a template for application\/json<\/strong>. I created this because application\/json<\/strong> is the default Content Type <\/strong>for API Gateway. If you do not specify this, a standard cURL request does not have a content type and fails.<\/li>\n
    6. In the text box near the bottom, insert your XML payload for the Route 53 API `POST` call:<\/li>\n<\/ol>\n

              <ChangeResourceRecordSetsRequest xmlns=”https:\/\/route53.amazonaws.com\/doc\/2013-04-01\/”>
      \n            <ChangeBatch>
      \n                <Changes>
      \n                    <Change>
      \n                        <Action>UPSERT<\/Action>
      \n                        <ResourceRecordSet>
      \n                            <Name>myddns.acme.local<\/Name>
      \n                            <Type>A<\/Type>
      \n                            <TTL>60<\/TTL>
      \n                            <ResourceRecords>
      \n                                <ResourceRecord>
      \n                                    <Value>$context.identity.sourceIp<\/Value>
      \n                                <\/ResourceRecord>
      \n                            <\/ResourceRecords>
      \n                        <\/ResourceRecordSet>
      \n                    <\/Change>
      \n                <\/Changes>
      \n            <\/ChangeBatch>
      \n        <\/ChangeResourceRecordSetsRequest><\/em>
      \n <\/p>\n

      Note<\/strong>: You need to change the name of the record you want to update. As stated previously, I used acme.local<\/strong> for this article. I selected myddns <\/strong>as the record to create or update.<\/p>\n

      The magic of the dynamic DNS system happens on the \\<Value\\> line, where $context.identity.sourceIp<\/em> is mapped to the client\u2019s IP address, updating the DNS record with whatever client or external IP address API Gateway sees.<\/p>\n

      Setting the Request body passthrough<\/strong> and security to Never<\/em> is the best thing you can do for securing your AWS Service proxy. It\u2019s not as big of a requirement with a GET<\/em> method as we\u2019ve created because the GET<\/em> operation does not allow for payloads. But suppose you create a POST<\/em> or PUT<\/em> method (both allow body data to be passed in) and select the top option When no template matches the request Content-Type header<\/strong>. If someone were to `POST` to your API Gateway URL with a
      \nContent-Type <\/em>you did not specify, such as application\/scriptkiddie<\/strong>, their entire payload would be passed on to the AWS Service so that the XML can override yours. Setting it to Never<\/strong> forces the payload to be the only one delivered to the AWS API.<\/p>\n

      Step 4: Use the right content type for the API call<\/strong><\/p>\n

      When you request API Gateway, the content type you specify gets passed through to the Integration (in this case, our Integration is the Route 53 API). If you do not specify a content type, API Gateway sets your Content-Type <\/strong>header to application\/json<\/em>. This is a problem because we need to post to Route 53 API as application\/xml<\/em>. So, hardcode that in the HTTP Headers in the following steps:<\/p>\n

        \n
      1. Expand the HTTP Headers<\/strong> section above Body Mapping Templates<\/strong>.<\/li>\n
      2. Create a new HTTP Header.<\/li>\n
      3. Set Name<\/strong> to: Content-Type<\/em>.<\/li>\n
      4. Set Mapped from<\/strong> to: application\/xml<\/em>.<\/li>\n<\/ol>\n

        Note: <\/strong>Single apostrophes are required<\/p>\n

        HTTP Header created with the apostrophes<\/em><\/p>\n

        Step 5: Configure {zone_id}<\/strong><\/p>\n

        Remember how you created the \/{zone_id}<\/em> resource in step 1? Well, now you can configure it. Because I don\u2019t like to use the same variable name for two different services, I converted {zone_id<\/em>} to {hosted_zone_id<\/em>}:<\/p>\n

          \n
        1. Expand the URL Path Parameters<\/strong> section.<\/li>\n
        2. Create a new path with the Name<\/strong> of hosted_zone_id<\/em>.<\/li>\n
        3. Set Mapped from<\/strong> to: method.request.path.zone_id.<\/em> This is where we use zone_id<\/em> from the original resource path and map it to {hosted_zone_id}<\/em> in the Path override<\/strong> setting.<\/li>\n<\/ol>\n

          Step 6: Deploy<\/strong><\/p>\n

          At this point, you can deploy your newly configured API Gateway. I used a stage called ddns<\/strong>, but you can call it whatever you like.<\/p>\n

          You might think, \u201cHey, shouldn\u2019t we test this first?\u201d While API Gateway has a great test feature, the test is not great for us because it sets our caller IP address to a string. That string won’t work with DNS because we\u2019re setting a record. So, we have to rely on cURL to tell us if it works or not. Remember, you need your Zone ID from Route 53 to update DNS. The URL format is similar to the following example:<\/p>\n

              https:\/\/your_api_gw_url\/stage_name\/zone_id<\/strong><\/p>\n

          For my system, it ended up being:  https:\/\/c3y150djkh.execute-api.us-west-2.amazonaws.com\/ddns\/ZICXXN1DR8UXO<\/strong>*<\/p>\n

          On a successful `GET` request, you get a `200` response code with the ChangeInfo response. At this point, your system is working. You can verify it by waiting up to 60 seconds and then checking your Route 53 console.
          \n <\/p>\n

          (Optional) Step 7: Secure output<\/strong><\/p>\n

          If you do not want to see the output of your Route 53 API call, you can adjust
          \nthe data to just be empty:<\/p>\n

            \n
          1. Go to the GET Method<\/strong> > Integration Response<\/strong>.<\/li>\n
          2. Expand the 200 Method Response status<\/strong> line.<\/li>\n
          3. Expand Body Mapping Templates<\/strong><\/li>\n
          4. Click on application\/json<\/strong>.<\/li>\n
          5. Select Empty<\/strong> from the Generate template<\/strong> drop-down menu.<\/li>\n
          6. Click Save<\/strong><\/li>\n
          7. Redeploy your API.<\/li>\n<\/ol>\n

            (Optional) Step 8: Additional security<\/strong><\/p>\n

            I won\u2019t go into detail, but you can optionally add additional security by adding an API Key to your method. There\u2019s plenty<\/a> of documentation<\/a> on how to do this<\/a>. Just remember that you need to add the x-api-key header<\/em>. Thus, you might end up with a cURL request like the following example:<\/p>\n

                curl \\
            \n    -H “x-api-key: hzYAVO9Sg98nsNh81M84O2kyXVy6K1xwHD8” \\
            \n    ‘https:\/\/c3y150djkh.execute-api.us-west-2.amazonaws.com\/ddns\/ZICXXN1DR8UXO’<\/em><\/p>\n

            We leave this step as an exercise for you. In as few as six steps, you\u2019re finished creating an AWS Route 53 Dynamic DNS.<\/p>\n","protected":false},"excerpt":{"rendered":"

            How to create a dynamic DNS with the AWS API and Route 53<\/p>\n","protected":false},"author":2,"featured_media":7184,"menu_order":0,"comment_status":"open","ping_status":"open","template":"","format":"standard","meta":{"content-type":"","nid":"26295","content_type":"blog","created_by":"10130","authored_on":"2023-11-25T20:17:09+00:00","field_article_industries":"","tag_category":"Technical","field_blog_author_text":"by Rackspace Technology Staff","seo_description":"Learn how to create a dynamic DNS on AWS using the Route 53 service, bypassing the need for Lambda technology and optimizing your cloud infrastructure.\r\n","field_featured_image":"","insights_image":"\/wp-content\/uploads\/2026\/blog_technical_images\/26295-insights_image-aws-technical-blog-1-insights.png","field_partners":"","rxt_platforms":"Amazon Web Services (AWS)","product":"","publisheddate":"2021-01-21T20:17:09","rxt_solutions":"Public Cloud","opengraph_tag":"","x_tag":"","teaser_flag":"Technical Blog","seo_titile":"Dynamic DNS on AWS Route 53 | Rackspace Technology","field_topics":"","field_slug":"how-to-create-a-dynamic-dns-with-the-aws-api-and-route-53","footnotes":""},"categories":[178],"tags":[204],"class_list":["post-7182","blogs","type-blogs","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-technical"],"_links":{"self":[{"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/blogs\/7182","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/blogs"}],"about":[{"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/types\/blogs"}],"author":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/comments?post=7182"}],"version-history":[{"count":1,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/blogs\/7182\/revisions"}],"predecessor-version":[{"id":7183,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/blogs\/7182\/revisions\/7183"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/media\/7184"}],"wp:attachment":[{"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/media?parent=7182"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/categories?post=7182"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/tags?post=7182"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}