By using AWS re:Post, you agree to the Terms of Use
/Amazon Route 53/

Questions tagged with Amazon Route 53

Sort by most recent
  • 1
  • 90 / page

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Serving My EC2 Hosted Website Via Cloud Front

Hello All, First question in this forum. Hope it finds all well and prospering. *The Set Up:* I have an EC2 instance running Nginx and hosting my site. Got an Elastic IP, opened all the right ports. So far, all working well. I have created a Cloud Front Distribution. It uses the domain name of my site as the source. I add a subdomain, cdn.mydomain.com, as an alternate domain at the Distribution Interface. I have created Sectigo ssl certs on my server and created them for my distribution, using the CloudFront interface. SSL is enabled for mydomain.com, www.mydomain.com, and cdn.mydomain.com. I set cdn.mydomain.com as a CloudFront Alias record in my Route 53 DNS. It points to the URL of the CloudFront distribution. I wait until the changes are deployed before testing. My subdomain, cdn.mydomain.com works. The URL for my distribution, dyzmywebsitejbpe.cloudfront.net works. The distribution is obtaining content from my EC2 instance using mydomain.com as the source. It seems that all is well. *Conflict Ensues:* I want it so that when end users enter mydomain.com into their browser, they get content via my CloudFront distribution vs getting it from my server. To make that happen I have tried all kinds of combos. The way I understand things, the following should have worked. *Heroic Action:* I change the source of my distribution from mydomain.com to cdn.mydomain.com. Then I change two DNS records. First, cdn.mydomain.com goes from pointing to the CloudFront URL to the IP of my EC2 web server. Second, mydomian.com goes from being aimed at the IP to pointing at the CloudFront URL. Using Distribution interface, I remove cdn.mydomain from alternate domains and add mydomain.com. Essentially I have flipped the roles played by mydomain.com and cdn.mydomain.com. I wait for things to propagate and redeploy. *The All Is Lost Moment:* At this point, nothing works. I get an error. Too many redirects. None of the URLs that worked above, work now. *Déjà All Over Again:* I reverse things. All is well. cdn.mydomain and the Distribution URLs seem to serve content via my CloudFront Distribution. And mydomain.com works as expected because it points at the IP of my server. *A Man Has Got To Know His Limitations:* My obviously flawed understanding is that I need to have a subdomain as the source of the Distribution and that said subdomain, cdn.mydomain.com, should point at the ip of my web server. I figure Nginx needs know about that subdomain and have added it to my .conf file. I assume that the DNS for mydomain.com should then point at the Distribution url. I toss in a trusted source set of certificates for all three involved domains on my server and tell Nginx what it needs to know about them. I attach a certificate generated by aws, for all three of my domains via the distribution alternate url tab of the Distribution interface. But I only allow one alternate url, which per understanding, should be mydomain.com. *Confession Is Good For The Solution:* I am stuck in a loop. I can't get out of it. What am I missing? Thanks for any help! John Ullom
2
answers
0
votes
11
views
Redbone
asked 6 days ago

Route 53 - ConflictingDomainExists - subdomains with (White-Labeled) Reusable Delegation set

Trying to set up a sub domain of a domain this is 1) created with a Reusable Delegation set, that also host the [white label](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/white-label-name-servers.html) DNS records. The error I get is: ``` Error: error creating Route53 Hosted Zone: ConflictingDomainExists: Cannot create hosted zone with DelegationSetId DelegationSetId:N07332301DF5CDCEBAHPP as the DNSName <my sub domain>. conflicts with existing ones sharing the delegation set status code: 400, ``` AWS [documentation](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html) on these concepts is very this on the ground. To quote: *Create a public hosted zone: Two hosted zones that have the same name or that have a parent/child relationship (example.com and test.example.com) can't have any common name servers. You tried to create a hosted zone that has the same name as an existing hosted zone or that's the parent or child of an existing hosted zone, and you specified a delegation set that shares one or more name servers with the existing hosted zone. For more information, see [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html).* There is not much on this in google land but did find [this](https://forums.aws.amazon.com/message.jspa?messageID=718365) old forums post to explain the likely issue but don't know best approach to resolve. It would be great is AWS would update documentation to explain how to do this ?
1
answers
0
votes
3
views
AWS-User-3578655
asked 13 days ago

Multi Region strategy for API Gateway

If disaster recovery is not a requirement, what would be the best strategy for setting up API Gateway to server global customers. Here are three options that I can think of, not able to land on one. **Option 1**: Single Edge Optimized API Gateway serving traffic * Pros: save cost and avoid complexity of data replication (backend is opensearch) * Cons: Latency? not sure how much edge optimized API will help with latency, as customer will be hitting the API at nearest edge (ssl handshake, etc) and traffic flowing via backbone network. ( Question 1) **Option 2** Multiple Regional API Gateway with Route53 Latency based routing * Pros: customers hitting closest API. * Cons: Data replication, Cost. Also, since there is no cloud front here, traffic will be flowing via internet to closest region API, lets say we have API deployed in two regions , US and Singapore, would users in Europe see latency , worse than the Option 1, where requests are going to nearest edge location and reaches API via backbone? **Option 3** Multiple Edge Optimized API Gateway with Route53 Latency based routing * Pros: customers hitting closest API. Not sure how latency based routing works on an edge optimized endpoint, would it even help, since both endpoints are edge optimized. Not sure how smart is Route53 (Question 2) * Cons: Data replication, cost and uncertainty of Latency based routing. and Finally , one that I can think of could work, but haven't found too many solutions where people implemented. **Option 4** Multiple Regional API Gateway with single custom Cloudfront on top with cloudfront functions to do the routing. * Pros: customers hitting closest edge optimized location and routed to nearest API, this routing will be based on country of origin header from cloudfront. * Cons: Same Data Replication, Cost and predefined list of countries based routing. I need to spend time and run tests with multiple solutions. But wanted to seek community advise first. To summarize everything, if cost, complexity and disaster recovery are kept out of discussion, what would be best architecture for API Gateway to avoid latency issues.
2
answers
0
votes
18
views
Balu
asked 17 days ago

Boto3 Bug in response when creating a hosted zone in route53 with Python

I had boto3 1.16.7 libraries and went to 1.23.24, to see if this could still be replicated. When I run the following code to create a hosted zone, I get a response that contains a call to the the datetime library as a value for the SubmittedAt key in the json/dictionary: 'SubmittedAt': datetime.datetime(2021, 12, 17, 16, 40, 21, 154000, tzinfo=tzutc()). This had caused some problems when I was trying to extract data, but I have worked around that. When I run this with the aws cli (aws route53 create-hosted-zone --name contoso.com --caller-reference 20211217), I get an expected value: "SubmittedAt": "2021-12-18T01:40:44.781000+00:00" Am I doing something wrong or is this a bug? Code: ``` import boto3 import datetime awsProfile = 'default' awsRegion = 'us-east-1' hostedZoneName = 'dev.contoso.com' timeStamp = datetime.datetime.now().strftime("%Y%m%d%H%M%S") boto3.setup_default_session(profile_name=awsProfile, region_name=awsRegion) client = boto3.client('route53') hostedZoneParams = { 'Name': hostedZoneName, 'CallerReference': timeStamp, } response = client.create_hosted_zone(**hostedZoneParams) print(response) ``` Output: ``` {'ResponseMetadata': {'RequestId': 'redacted', 'HTTPStatusCode': 201, 'HTTPHeaders': {'x-amzn-requestid': 'redacted', 'location': 'https://route53.amazonaws.com/2013-04-01/hostedzone/redacted', 'content-type': 'text/xml', 'content-length': '762', 'date': 'Fri, 17 Dec 2021 16:40:20 GMT'}, 'RetryAttempts': 0}, 'Location': 'https://route53.amazonaws.com/2013-04-01/hostedzone/redacted', 'HostedZone': {'Id': '/hostedzone/redacted', 'Name': 'dev.contoso.com.', 'CallerReference': '20211217114020', 'Config': {'PrivateZone': False}, 'ResourceRecordSetCount': 2}, 'ChangeInfo': {'Id': '/change/redacted', 'Status': 'PENDING', 'SubmittedAt': datetime.datetime(2021, 12, 17, 16, 40, 21, 154000, tzinfo=tzutc())}, 'DelegationSet': {'NameServers': ['ns-144.awsdns-18.com', 'ns-1956.awsdns-52.co.uk', 'ns-550.awsdns-04.net', 'ns-1307.awsdns-35.org']}} ```
1
answers
0
votes
6
views
devsecops
asked a month ago

How can I serve CloudFront assets to a naked domain I manage with a non-AWS DNS provider?

Hi all! Summary: Our DNS provider, GoDaddy, does not support apex ("A") DNS records pointing to non-static IPs. We want to serve our AWS CloudFront assets to our domain's naked domain, but CloudFront gives us a url, not a static IP. Here's the current state of our setup: * We own a domain, let's call it domain.com, through GoDaddy * We manage the DNS for this domain through GoDaddy * We store our website assets in AWS S3 * We use AWS CloudFront to serve the website assets from that S3 bucket * CloudFront gives us a url, like xyz123.cloudfront.net, that the assets are served from * CloudFront does not give us a static IP address * We use AWS Certificate Manager to apply an SSL certificate to both our naked domain "domain.com" and www subdomain "www.domain.com" * The SSL certificate is applied to the CloudFront configuration * We have a CNAME DNS record pointing the www subdomain to the CloudFront url * ie. navigating to www.domain.com properly gets served the CloudFront assets, and since we have the SSL certificate applied to this domain and the CloudFront configuration we don't encounter any SSL issues. * We use a feature on GoDaddy called Forwarding to redirect any http://domain.com naked domain requests to http://www.domain.com * Our CloudFront has a “Viewer protocol policy” of “Redirect HTTP to HTTPS”, so http://www.domain.com thereafter gets converted to https://www.domain.com Current issues that we would like to solve: * We want https://domain.com to serve the CloudFront assets. * This may involve serving CloudFront assets directly from that url or redirecting it to https://www.domain.com * We can't serve the assets directly with our current setup because GoDaddy's DNS management does not support apex records pointing to urls - it must point to an IP, and we don't get a static IP from CloudFront * In past iterations, we’ve used GoDaddy’s Forwarding feature to attempt to redirect https://domain.com to https://www.domain.com, or even http://www.domain.com, but GoDaddy’s Forwarding feature does not support HTTPS requests. * The Forwarding feature changes the A record to point to GoDaddy’s proxy server, and that proxy server does not have our SSL certificate installed, so we were getting SSL warnings. * We own another domain, let's call it other-domain.com, and we would like to redirect all requests to both the naked domain and the www subdomain (http and https) to https://www.domain.com. * We ran into a similar issue here: we can’t use GoDaddy Forwarding here to reroute https requests - it spawns an SSL warning. We imagine the solutions may be: 1. Get a static IP from CloudFront. Is this possible? And are there time, energy, and money costs associated with this? 2. Use our own redirect server. We could potentially manage a simple, say, AWS EC2 instance that uses an nginx or Apache server that redirects requests to https://www.domain.com. We could point the naked domain to the IP of the EC2 instance, and have our own SSL certificate installed there. We're not crazy about this because it adds another node of complexity that we manage. We would be more interested in this option if there was some AWS service that gave us SSL-enabled redirect capabilities out of the box - does that exist? 3. Change our DNS provider from GoDaddy to AWS Route53. As far as we can tell Route53 allows apex DNS records to point to urls instead of requiring them to point to IP addresses, which means we can just point an A record for domain.com to the CloudFront url. We're also not crazy about this because migrating DNS providers is a lift, and we have many other domains managed through GoDaddy as well. Any and all feedback / suggestions is welcome. Thank you!
1
answers
0
votes
9
views
samgqroberts
asked a month ago
2
answers
0
votes
6
views
chubbsondubs
asked a month ago
2
answers
0
votes
16
views
FinneyCanHelp
asked a month ago

Point Route 53 Domain to Lightsail Instance

Hi, I have a Lightsail Instance, 1 Domain, and a new EC2 Instance. Everything works fine. I'm following a book that needs me to change the Hostnames and the Name Servers. I found a page on AWS explaining how to point my Route 53 Domain to my Lightsali Instance. https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-using-route-53-to-point-a-domain-to-an-instance It's not the same as the book but I think it's what I need. Here's the instructions from the book... "Log into your GoDaddy (or similar) account after purchasing a domain Select your domain, click manage, and select Advanced DNS Next, set up Hostnames in the DNS Management to point to your Server ns1 (and put the IP of your VPS server) ns2 (and put the IP of your VPS server) Edit Nameservers to Custom Add ns1.loca1host.com Add ns2.loca1host.com" So, where is DNS Management in AWS? I've tried to figure it out on my own. (Including the first link.) Here's what I have... *My AWS Domain has all the default settings. (I didn't erase any.) I added: Hostnames "A – IPv4 address" with my Lightsail Static IP and it's private IP. "CNAME" with "www" in front of "mydomain.com" I used the first link to point to my Lightsail (Static) IP. I'm not sure if that works. I don't know how to change my "Hostname." Where do I find that? My Lightsail Terminal says "ip-my-ip-address. Is that my hostname? Secondly, I don't know if I set up the Nameservers right. I know I should have ns1 and ns2. Should I use loca1host.com like in the book? Or my VPS IP? Or what? So, how do I change my hostname and nameservers? To point to my Lightsail Instance? Should I delete old nameservers? I can find those. The AWS link doesn't show any "ns1" and "ns2". So where's my DNS management and hostnames? This is probably an easy question. Please reply. Thanks
2
answers
0
votes
2
views
nethunter
asked 2 years ago

Seamlessly switch between CloudFront distributions using Route 53?

My customer wants ultimately to migrate multiple CloudFront Distributions from one AWS Account to another but realize [it’s not quite possible](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-migrate-account/). Right now their CloudFront Distribution is configured this way: - CNAME of the CloudFront Distribution is the same as a production customer-facing FQDN (e.g.: download-office.customer.com) - in Route53 customer-facing FQDN is pointed to CloudFront Distribution FQDN using CNAME record (e.g.: download-office.customer.com CNAME d11ipsxxxxxxx.cloudfront.net) What they want to do is to introduce an intermediate FQDN and place it in between the customer-facing FQDN and CloudFront Distribution FQDN using Route53 Alias Records. So the configuration would look like: - CNAME of the CloudFront Distribution is the same as a intermediate FQDN (e.g.: balancer-download-office.customer.com) - in Route53 intermediate FQDN is pointed to CloudFront Distribution FQDN using ALIAS record (e.g.: balancer-download-office.customer.com ALIAS d11ipsxxxxxxx.cloudfront.net) - in Route53 customer-facing FQDN is pointed to intermediate FQDN using ALIAS record (e.g.: download-office.customer.com ALIAS balancer-download-office.customer.com) It's working in their QA environment but they would like feedback on any issues. However, they are finding from support engineers that the only way to swap a CloudFront distribution without downtime is specifically [through a support case](https://aws.amazon.com/premiumsupport/knowledge-center/resolve-cnamealreadyexists-error/). The question is: **what is the best way for my customer to seamlessly switch between CloudFront distributions, and ultimately move to a CloudFront distribution in another account without downtime?**
1
answers
0
votes
2
views
Joshua_S
asked 2 years ago

server IP address could not be found DNS_PROBE_FINISHED_NXDOMAIN

I have already scoured this forum and other web resources. I tried what was suggested to fix this issue and I have not had success. Here is my issue / question? I have a domain devonacloud.com registered through Route 53. I created a Hosted Zone for this domain. I did not edit any of the records created in the Hosted Zone. I also created an S3 bucket with the same name. I gave this bucket the property of being a static site, I gave it a public access policy, upload a simple html file, and tested the endpoint. The endpoint works as you can see here <http://devonacloud.com.s3-website-us-east-1.amazonaws.com/>. Finally, I created an alias record for this domain and chose this bucket for that record. I saved the record. Now, when I try to visit this domain I get the dreaded **server IP address could not be found** message in chrome. Various things I tried were to flush my DNS cache. I also tried: ``` wti@robert-dev:~$ wget devonacloud.com --2020-04-19 18:13:27-- http://devonacloud.com/ Resolving devonacloud.com (devonacloud.com)... failed: Name or service not known. wget: unable to resolve host address ‘devonacloud.com’ wti@robert-dev:~$ cat /etc/resolv.conf # Generated by NetworkManager nameserver 192.168.14.30 nameserver 192.168.14.31 wti@robert-dev:~$ dig devonacloud.com ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> devonacloud.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2721 robert.risk@we-laptop93:~$ nslookup devonacloud.com ;; Got SERVFAIL reply from 192.168.14.30, trying next server ;; Got SERVFAIL reply from 192.168.14.31, trying next server ;; connection timed out; no servers could be reached ``` I also visited <https://www.whatsmydns.net/#NS/devonacloud.com> and noticed that the NS records have not fully propagated. I find that strange because I&#39;ve been dealing with this issue for a few days. The only off-color thing I can think of is I previously had this domain point to a static IP I configured on a Lightsail instance. I&#39;ve deleted the static IP and the Lightsail instance, so I&#39;m surprised if this would cause an issue. When I click on my domain in Route 53, the name servers are: ns-1196.awsdns-21.org ns-1701.awsdns-20.co.uk ns-403.awsdns-50.com ns-657.awsdns-18.net And in its Hosted Zone, the values for the NS record set are: ns-348.awsdns-43.com. ns-955.awsdns-55.net. ns-1200.awsdns-22.org. ns-1950.awsdns-51.co.uk. Should these be the same? Can anyone see what might be causing the server IP address could not be found error and how to resolve it?
2
answers
0
votes
0
views
robertDev73
asked 2 years ago
2
answers
0
votes
0
views
JPDDS
asked 2 years ago

how to prevent Route53 from exposing our VPC RFC1918 address space to the Internet

I need to know if it’s possible (and if possible, how) to prevent Route53 from exposing our VPC RFC1918 address space to the Internet. As you can see, these addresses are leaked out onto the Internet where they do no good except to expose the endpoints of various AWS services: From inside Corp: ps@site:tmp$ dig test-do-not-use.cmqvubhjfrhv.us-east-1.rds.amazonaws.com ; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> test-do-not-use.cmqvubhjfrhv.us-east-1.rds.amazonaws.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1636 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;test-do-not-use.cmqvubhjfrhv.us-east-1.rds.amazonaws.com. IN A ;; ANSWER SECTION: test-do-not-use.cmqvubhjfrhv.us-east-1.rds.amazonaws.com. 4 IN A 172.31.58.126 ;; Query time: 380 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Tue Sep 24 07:10:57 CDT 2019 ;; MSG SIZE rcvd: 106 From my home Linux system: ps@plex:~$ dig test-do-not-use.cmqvubhjfrhv.us-east-1.rds.amazonaws.com ; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> test-do-not-use.cmqvubhjfrhv.us-east-1.rds.amazonaws.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9577 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;test-do-not-use.cmqvubhjfrhv.us-east-1.rds.amazonaws.com. IN A ;; ANSWER SECTION: test-do-not-use.cmqvubhjfrhv.us-east-1.rds.amazonaws.com. 3600 IN A 172.31.58.126 ;; Query time: 210 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Sep 24 07:11:04 CDT 2019 ;; MSG SIZE rcvd: 106 Ideally this external query should return NOTHING. I’ve been unsuccessful in my document digging in the AWS doc repository.
1
answers
0
votes
1
views
Dave_G
asked 2 years ago

dig eastcutlabs.com = status: SERVFAIL

I've been using route53-purchased domains with netlify to point to their webapps successfully for several apps. I recently created a second hosted zone (eastcutlabs.com) via terraform that was the same domain name as a previously working domain of the same name. I deleted both of them and tried to recreate just one domain of the same name and reconfigured the A and CNAME records that makes it point to my netlify webapp, but it does not work no matter how many times I delete the hosted zone and try again. I ran a `dig eastcutlabs.com` and it shows status: SERVFAIL. I did a `dig eastcutlabs.com _trace` and it does not return the A record that exists in route53. You can find my route53 config the dig and dig_trace below. I subsequently purchased another domain (eastcutlab.com - note: "lab" instead of "labs") and pointed it to the same webapp as I'm trying with eastcutlabs.com and it worked (config also below). For eastcutlabs.com (non-working domain) I also tried flushing the DNS cache from: https://developers.google.com/speed/public-dns/cache. tldr: eastcutlabs.com (plural: returns a SERVFAIL) eastcutlab.com (singular: works) ==================================== eastcutlabs.com (not working) ``` resource "aws_route53_record" "Z1H2B5E0B5U9QA_eastcutlabs--com--_A_" { name = "eastcutlabs.com" records = \["104.198.14.52"] ttl = "300" type = "A" zone_id = "${aws_route53_zone.Z1H2B5E0B5U9QA_eastcutlabs--com.zone_id}" } resource "aws_route53_record" "Z1H2B5E0B5U9QA_eastcutlabs--com--_NS_" { name = "eastcutlabs.com" records = \["ns-770.awsdns-32.net.", "ns-1166.awsdns-17.org.", "ns-127.awsdns-15.com.", "ns-2018.awsdns-60.co.uk."] ttl = "172800" type = "NS" zone_id = "${aws_route53_zone.Z1H2B5E0B5U9QA_eastcutlabs--com.zone_id}" } resource "aws_route53_record" "Z1H2B5E0B5U9QA_eastcutlabs--com--_SOA_" { name = "eastcutlabs.com" records = \["ns-2018.awsdns-60.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400"] ttl = "900" type = "SOA" zone_id = "${aws_route53_zone.Z1H2B5E0B5U9QA_eastcutlabs--com.zone_id}" } resource "aws_route53_record" "Z1H2B5E0B5U9QA_www--eastcutlabs--com--_CNAME_" { name = "www.eastcutlabs.com" records = \["optimistic-wiles-20fec5.netlify.com"] ttl = "300" type = "CNAME" zone_id = "${aws_route53_zone.Z1H2B5E0B5U9QA_eastcutlabs--com.zone_id}" } ``` eastcutlab.com (working) ``` resource "aws_route53_record" "Z1ZRGWFIEUH3F5_eastcutlab--com--_A_" { name = "eastcutlab.com" records = \["104.198.14.52"] ttl = "300" type = "A" zone_id = "${aws_route53_zone.Z1ZRGWFIEUH3F5_eastcutlab--com.zone_id}" } resource "aws_route53_record" "Z1ZRGWFIEUH3F5_eastcutlab--com--_NS_" { name = "eastcutlab.com" records = \["ns-45.awsdns-05.com.", "ns-1994.awsdns-57.co.uk.", "ns-1046.awsdns-02.org.", "ns-948.awsdns-54.net."] ttl = "172800" type = "NS" zone_id = "${aws_route53_zone.Z1ZRGWFIEUH3F5_eastcutlab--com.zone_id}" } resource "aws_route53_record" "Z1ZRGWFIEUH3F5_eastcutlab--com--_SOA_" { name = "eastcutlab.com" records = \["ns-948.awsdns-54.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400"] ttl = "900" type = "SOA" zone_id = "${aws_route53_zone.Z1ZRGWFIEUH3F5_eastcutlab--com.zone_id}" } resource "aws_route53_record" "Z1ZRGWFIEUH3F5_www--eastcutlab--com--_CNAME_" { name = "www.eastcutlab.com" records = \["optimistic-wiles-20fec5.netlify.com"] ttl = "300" type = "CNAME" zone_id = "${aws_route53_zone.Z1ZRGWFIEUH3F5_eastcutlab--com.zone_id}" } ``` dig eastcutlabs.com (not working) ``` ; <<>> DiG 9.10.6 <<>> eastcutlabs.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7554 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;eastcutlabs.com. IN A ;; Query time: 99 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Mon Sep 23 19:20:22 PDT 2019 ;; MSG SIZE rcvd: 44 ``` dig eastcutlabs.com +trace (not working) ``` ... eastcutlabs.com. 172800 IN NS ns-127.awsdns-15.com. eastcutlabs.com. 172800 IN NS ns-770.awsdns-32.net. eastcutlabs.com. 172800 IN NS ns-1166.awsdns-17.org. eastcutlabs.com. 172800 IN NS ns-2018.awsdns-60.co.uk. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20190928044441 20190921033441 17708 com. G131mLtsBTVuH1wpOFbRs0/voaY_V7rxVJHc9XWhCelqZkbFiB6tVxKw oqpWdiXL_p4V40G3Koo8Y7y/Qd2M+hV4edC0nal1RrNt97hkRLQAcTJ/ wHZcMl84JbDtZT44UY1iHWv4GUxlxyaQiew/YceADjSzNtqG8mU1zNhC P1g= HHEA290R8BPOIQQR30IRSVVI46C9B0HV.com. 86400 IN NSEC3 1 1 0 - HHEALMV137V9EQO2DK68KA3F9MVS0D32 NS DS RRSIG HHEA290R8BPOIQQR30IRSVVI46C9B0HV.com. 86400 IN RRSIG NSEC3 8 2 86400 20190929051624 20190922040624 17708 com. pFc2boy242bdH_MGS/l_aAk_xjQ5BlplgNjmEWeIAMqObTSo7XgqCxtS 47XNGsRW2uxjT8sfZXEkysTYcHcfPvFWydDez8u6/T_uJjx5L2wRSHpJ 9tzyILeKubVEZmNDYn79Wj3DBVuiADOnyYlI6gh1dfd3tagS9XSG9XPk h3U= ;; Received 682 bytes from 192.26.92.30#53(c.gtld-servers.net) in 45 ms ;; Received 33 bytes from 205.251.196.142#53(ns-1166.awsdns-17.org) in 21 ms ``` dig eastcutlab.com (working) ``` ; <<>> DiG 9.10.6 <<>> eastcutlab.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64743 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;eastcutlab.com. IN A ;; ANSWER SECTION: eastcutlab.com. 300 IN A 104.198.14.52 ;; Query time: 21 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Mon Sep 23 19:24:39 PDT 2019 ;; MSG SIZE rcvd: 59 ``` dig eastcutlab.com +trace (working) ``` ... eastcutlab.com. 172800 IN NS ns-948.awsdns-54.net. eastcutlab.com. 172800 IN NS ns-1046.awsdns-02.org. eastcutlab.com. 172800 IN NS ns-1994.awsdns-57.co.uk. eastcutlab.com. 172800 IN NS ns-45.awsdns-05.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20190928044441 20190921033441 17708 com. G131mLtsBTVuH1wpOFbRs0/voaY_V7rxVJHc9XWhCelqZkbFiB6tVxKw oqpWdiXL_p4V40G3Koo8Y7y/Qd2M+hV4edC0nal1RrNt97hkRLQAcTJ/ wHZcMl84JbDtZT44UY1iHWv4GUxlxyaQiew/YceADjSzNtqG8mU1zNhC P1g= GL38I96QK11041TE88Q6CO1V4LOSIRCK.com. 86400 IN NSEC3 1 1 0 - GL3B3M8MBCJM4GS4D8D5OI5PPIBLOTMN NS DS RRSIG GL38I96QK11041TE88Q6CO1V4LOSIRCK.com. 86400 IN RRSIG NSEC3 8 2 86400 20190930042015 20190923031015 17708 com. w/D5rSb5jeBTdj8ObyfFCrHfqf1v6JktHHbQei06jIrXRIeVhSdgB9wL iQXgl9pd7YaYEcAuOlCsuhp0AQiFVrQ0dxDh6ugG/OittIFHAXHiptYk fF4wpInlo8NNV0DPtNFu_uIt4YKwu5ZjfxysY2odfBueG3HAugU0Xe9a _iQ= ;; Received 680 bytes from 192.26.92.30#53(c.gtld-servers.net) in 45 ms eastcutlab.com. 300 IN A 104.198.14.52 eastcutlab.com. 172800 IN NS ns-1046.awsdns-02.org. eastcutlab.com. 172800 IN NS ns-1994.awsdns-57.co.uk. eastcutlab.com. 172800 IN NS ns-45.awsdns-05.com. eastcutlab.com. 172800 IN NS ns-948.awsdns-54.net. ;; Received 195 bytes from 205.251.192.45#53(ns-45.awsdns-05.com) in 22 ms ``` Edited by: tomkit on Sep 23, 2019 8:00 PM
1
answers
0
votes
0
views
tomkit
asked 2 years ago

Route 53 Resolver for On-Prem Access to Private API Gateway over Direct Connect Options

I have API Gateway Private API using a VPC end point that will only be accessed by clients (browser and applications) from on premises over Direct Connect. x-apigw-api-id:{api-id} Header is not an option as some application code can not be modified at this time. The interim solution is NGINX on Fargate, but I want a solution without a proxy in the middle for operational simplicity. I have created a forwarder zone for {restapi-id}.execute-api.{region}.amazonaws.com on their on-prem DNS pointing to their deployed Route 53 Inbound Resolvers. What I have found is that the first response for an API Gateway DNS name is a CNAME to execute-api.eu-central-1.amazonaws.com, which will never get resolved up to an A record by our DNS or internet forwarders. A request directly to the Route53 Resolver using the FQDN for the private API will work because a client will ask the same Route 53 Resolver again to resolve the CNAME. However, I want clients talk to a local DNS server, which forwards to Route 53 Resolver, the returned CNAME is queried against local DNS which gets forwarded to internet instead of last used resolver. **Options: Is there a recommended pattern?** Option 1 - Create forwarding zone for execute-api.eu-central-1.amazonaws.com. This will solve the problem, however that means prod/non-prod API-gateway requests will go through a single VPC. However I want isolated prod / non-prod environments. Option 2 - Dedicated VPC with Private API Gateway, Route 53 Resolver, and VPC Endpoint used for all regional on-prem API access requests. Option 3 - A configuration (QiP / BIND) to re-ask last resolver for CNAME. **Additional Questions** 1 - Is there an option I am missing or even better a recommended architecture for this use case? 2 - Are there configurations I'm missing on Route 53 resolver to return the A record to the client? Have Route 53 Resolver ask for A records when receiving a CNAME.
1
answers
0
votes
0
views
Justin_C
asked 3 years ago
  • 1
  • 90 / page