Amazon Route 53 FAQs Amazon Web Services Flashcards
Amazon Route 53 has a simple web service interface that lets you get started in minutes. Your DNS records are organized into “hosted zones” that you configure with the AWS Management Console or Route 53’s API. To use Route 53, you simply:
Q. How do I get started with Amazon Route 53?
Route 53 is built using AWS’s highly available and reliable infrastructure. The globally distributed nature of our DNS servers helps ensure a consistent ability to route your end users to your application by circumventing any internet or network related issues. Route 53 is designed to provide the level of dependability required by important applications. Using a global anycast network of DNS servers around the world, Route 53 is designed to automatically answer queries from the optimal location depending on network conditions. As a result, the service offers low query latency for your end users.
Q. How does Amazon Route 53 provide high availability and low latency?
To provide you with a highly available service, each Amazon Route 53 hosted zone is served by its own set of virtual DNS servers. The DNS server names for each hosted zone are thus assigned by the system when that hosted zone is created.
Q. What are the DNS server names for the Amazon Route 53 service?
Amazon Route 53 charges are based on actual usage of the service for Hosted Zones, Queries, Health Checks, and Domain Names. For full details, see the Amazon Route 53 pricing page.
Q. What is the price of Amazon Route 53?
You can control management access to your Amazon Route 53 hosted zone by using the AWS Identity and Access Management (IAM) service. AWS IAM allows you to control who in your organization can make changes to your DNS records by creating multiple users and managing the permissions for each of these users within your AWS Account. Learn more about AWS IAM here.
Q. What types of access controls can I set for the management of my Domains on Amazon Route 53?
When you sign up for a new AWS service, it can take up to 24 hours in some cases to complete activation, during which time you cannot sign up for the service again. If you've been waiting longer than 24 hours without receiving an email confirming activation, this could indicate a problem with your account or the authorization of your payment details. Please contact AWS Customer Service for help.
Q. I have subscribed for Amazon Route 53 but when I try to use the service it says "The AWS Access Key ID needs a subscription for the service."
Yes. The Amazon Route 53 SLA provides for a service credit if a customer’s monthly uptime percentage is below our service commitment in any billing cycle. More information can be found here.
Q. Does Amazon Route 53 offer a Service Level Agreement (SLA)?
Hosted zones are billed once when they are created and then on the first day of each month.
Q. When is my hosted zone charged?
Hosted zones have a grace period of 12 hours--if you delete a hosted zone within 12 hours after you create it, we don't charge you for the hosted zone. After the grace period ends, we immediately charge the standard monthly fee for a hosted zone. If you create a hosted zone on the last day of the month (for example, January 31st), the charge for January might appear on the February invoice, along with the charge for February.
Q. Why do I see two charges for the same hosted zone in the same month?
You can configure Amazon Route 53 to log information about the queries that Amazon Route 53 receives including date-time stamp, domain name, query type, location etc. When you configure query logging, Amazon Route 53 starts to send logs to CloudWatch Logs. You use CloudWatch Logs tools to access the query logs. For more information please see our documentation.
Q. Does Amazon Route 53 provide query logging capability?
Yes. Anycast is a networking and routing technology that helps your end users’ DNS queries get answered from the optimal Route 53 location given network conditions. As a result, your users get high availability and improved performance with Route 53.
Q. Does Amazon Route 53 use an anycast network?
Each Amazon Route 53 account is limited to a maximum of 500 hosted zones and 10,000 resource record sets per hosted zone. Complete our request for a higher limit and we will respond to your request within two business days.
Q. Is there a limit to the number of hosted zones I can manage using Amazon Route 53?
Amazon Route 53 currently supports the following DNS record types:
Q. Which DNS record types does Amazon Route 53 support?
Yes. Amazon Route 53 offers a special type of record called an 'Alias' record that lets you map your zone apex (example.com) DNS name to the DNS name for your ELB load balancer (such as my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com). IP addresses associated with load balancers can change at any time due to scaling up, scaling down, or software updates. Route 53 responds to each request for an Alias record with one or more IP addresses for the load balancer. Route 53 supports alias records for three types of load balancers: Application Load Balancers, Network Load Balancers, and Classic Load Balancers. There is no additional charge for queries to Alias records that are mapped to AWS ELB load balancers. These queries are listed as “Intra-AWS-DNS-Queries” on the Amazon Route 53 usage report.
Q. Can I point my zone apex (example.com versus www.example.com) at my Elastic Load Balancer?
Q. Can I point my zone apex (example.com versus www.example.com) at my Amazon CloudFront distribution?
Q. Can I point my zone apex (example.com versus www.example.com) at my AWS Elastic Beanstalk environment?
Yes. Amazon Route 53 offers a special type of record called an ‘Alias’ record that lets you map your zone apex (example.com) DNS name to your Amazon API Gateway DNS name (i.e. api-id.execute-api.region.amazonaws.com/stage). IP addresses associated with Amazon API Gateway can change at any time due to scaling up, scaling down, or software updates. Route 53 responds to each request for an Alias record with one or more IP addresses for the API Gateway. There is no additional charge for queries to Alias records that are mapped to Amazon API Gateways. These queries are listed as “Intra-AWS-DNS-Queries” on the Route 53 usage report.
Q. Can I point my zone apex (example.com versus www.example.com) at my Amazon API Gateway?
Yes. Amazon Route 53 offers a special type of record called an ‘Alias’ record that lets you map your zone apex (example.com) DNS name to your Amazon VPC Endpoint DNS name (i.e. vpce-svc-03d5ebb7d9579a2b3.us-east-1.vpce.amazonaws.com). IP addresses associated with Amazon VPC Endpoints can change at any time due to scaling up, scaling down, or software updates. Route 53 responds to each request for an Alias record with one or more IP addresses for the VPC endpoint. There is no additional charge for queries to Alias records that are mapped to Amazon VPC endpoints. These queries are listed as “Intra-AWS-DNS-Queries” on the Amazon Route 53 usage report.
Q. Can I point my zone apex (example.com versus www.example.com) at my Amazon VPC endpoint?
Q. How can I use Amazon Route 53 with Amazon Simple Storage Service (Amazon S3) and Amazon CloudFront?
LBR (Latency Based Routing) is a new feature for Amazon Route 53 that helps you improve your application’s performance for a global audience. You can run applications in multiple AWS regions and Amazon Route 53, using dozens of edge locations worldwide, will route end users to the AWS region that provides the lowest latency.
Q. What is Amazon Route 53's Latency Based Routing (LBR) feature?
You can start using Amazon Route 53’s new LBR feature quickly and easily by using either the AWS Management Console or a simple API. You simply create a record set that includes the IP addresses or ELB names of various AWS endpoints and mark that record set as an LBR-enabled Record Set, much like you mark a record set as a Weighted Record Set. Amazon Route 53 takes care of the rest - determining the best endpoint for each request and routing end users accordingly, much like Amazon CloudFront, Amazon’s global content delivery service, does. You can learn more about how to use Latency Based Routing in the Amazon Route 53 Developer Guide.
Q. How do I get started using Amazon Route 53's Latency Based Routing (LBR) feature?
Like all AWS services, there are no upfront fees or long term commitments to use Amazon Route 53 and LBR. Customers simply pay for the hosted zones and queries they actually use. Please visit the Amazon Route 53 pricing page for details on pricing for Latency Based Routing queries.
Q. What is the price for Amazon Route 53's Latency Based Routing (LBR) feature?
You can start using Amazon Route 53’s Geo DNS feature quickly and easily by using either the AWS Management Console or the Route 53 API. You simply create a record set and specify the applicable values for that type of record set, mark that record set as a Geo DNS-enabled Record Set, and select the geographic region (global, continent, country, or state) that you want the record to apply to. You can learn more about how to use Geo DNS in the Amazon Route 53 Developer Guide.
Q. How do I get started using Amazon Route 53's Geo DNS feature?
Yes, we strongly recommend that you configure a global record, to ensure that Route 53 can provide a response to DNS queries from all possible locations—even if you have created specific records for each continent, country, or state where you expect your end users will be located. Route 53 will return the value contained in your global record in the following cases:
Q. When using Geo DNS, do I need a "global" record? When would Route 53 return this record?
Yes, you can have Geo DNS records for overlapping geographic regions (e.g., a continent and countries within that continent, or a country and states within that country). For each end user’s location, Route 53 will return the most specific Geo DNS record that includes that location. In other words, for a given end user’s location, Route 53 will first return a state record; if no state record is found, Route 53 will return a country record; if no country record is found, Route 53 will return a continent record; and finally, if no continent record is found, Route 53 will return the global record.
Q. Can I have a Geo DNS record for a continent and different Geo DNS records for countries within that continent? Or a Geo DNS record for a country and Geo DNS records for states within that country?
Like all AWS services, there are no upfront fees or long term commitments to use Amazon Route 53 and Geo DNS. Customers simply pay for the hosted zones and queries they actually use. Please visit the Amazon Route 53 pricing page for details on pricing for Geo DNS queries.
Q. What is the price for Route 53's Geo DNS feature?
Geo DNS bases routing decisions on the geographic location of the requests. In some cases, geography is a good proxy for latency; but there are certainly situations where it is not. LatencyBased Routing utilizes latency measurements between viewer networks and AWS datacenters. These measurements are used to determine which endpoint to direct users toward.
Q. What is the difference between Latency Based Routing and Geo DNS?
Route 53 now supports multivalue answers in response to DNS queries. While not a substitute for a load balancer, the ability to return multiple health-checkable IP addresses in response to DNS queries is a way to use DNS to improve availability and load balancing. If you want to route traffic randomly to multiple resources, such as web servers, you can create one multivalue answer record for each resource and, optionally, associate an Amazon Route 53 health check with each record. Amazon Route 53 supports up to eight healthy records in response to each DNS query.
Q. Does Amazon Route 53 support multiple values in response to DNS queries?
A traffic policy is the set of rules that you define to route end users’ requests to one of your application’s endpoints. You can create a traffic policy using the visual policy builder in the Amazon Route 53 Traffic Flow section of the Amazon Route 53 console. You can also create traffic policies as JSON-formatted text files and upload these policies using the Route 53 API, the AWS CLI, or the various AWS SDKs.
Q. What is the difference between a traffic policy and a policy record?
Yes. You can reuse a policy to manage more than one DNS name in one of two ways. First, you can create additional policy records using the policy. Note that there is an additional charge for using this method because you are billed for each policy record that you create.
Q. Can I use the same policy to manage routing for more than one DNS name?
Yes, it is possible to create an Alias record pointing to a DNS name that is being managed by a traffic policy.
Q. Can I create an Alias record pointing to a DNS name that is managed by a traffic policy?
No. We only charge for policy records; there is no charge for creating the traffic policy itself.
Q. Is there a charge for traffic policies that don’t have a policy record?
You are billed per policy record. A policy record represents the application of a Traffic Flow policy to a specific DNS name (such as www.example.com) in order to use the traffic policy to manage how requests for that DNS name are answered. Billing is monthly and is prorated for partial months. There is no charge for traffic policies that are not associated with a DNS name via a policy record. For details on pricing, see the Amazon Route 53 pricing page.
Q. How am I billed for using Amazon Route 53 Traffic Flow?
Traffic Flow supports all Amazon Route 53 DNS Routing policies including latency, endpoint health, multivalue; answers, weighted round robin, and geo. In addition to these, Traffic Flow also supports geoproximity based routing with traffic biasing.
Q. What are the advanced query types supported in Amazon Route 53 Traffic Flow?
When you create a traffic flow policy, you can specify either an AWS region (if you're using AWS resources) or the latitude and longitude for each endpoint. For example, suppose you have EC2 instances in the AWS US East (Ohio) region and in the US West (Oregon) region. When an user in Seattle visits your website, geoproximity routing will route the DNS query to the EC2 instances in the US West (Oregon) region because it's closer geographically. For more information please see the documentation on geoproximity routing.
Q. How does a traffic policy using geoproximity rule route DNS traffic?
Changing the geoproximity bias value on an endpoint either expands or shrinks the area from which Route 53 routes traffic to a resource. The geoproximity bias can't accurately predict the load factor, though, because a small shift in the size of geographic areas might include or exclude major metropolitan areas that generate large numbers of queries. For more information please refer to our documentation.
Q. How does the geoproximity bias value of an endpoint affect DNS traffic routing to other endpoints?
As of today, bias can only be applied to geoproximity rules.
Q. Can I use bias for other Traffic Flow rules?
Private DNS is a Route 53 feature that lets you have authoritative DNS within your VPCs without exposing your DNS records (including the name of the resource and its IP address(es) to the Internet.
Q. What is Private DNS?
Yes, you can manage private IP addresses within Virtual Private Clouds (VPCs) using Amazon Route 53’s Private DNS feature. With Private DNS, you can create a private hosted zone, and Route 53 will only return these records when queried from within the VPC(s) that you have associated with your private hosted zone. For more details, see the Amazon Route 53 Documentation.
Q. Can I use Amazon Route 53 to manage my organization’s private IP addresses?
You can resolve internal DNS names from resources within your VPC that do not have Internet connectivity. However, to update the configuration for your Private DNS hosted zone, you need Internet connectivity to access the Route 53 API endpoint, which is outside of VPC.
Q. Do I need connectivity to the outside Internet in order to use Private DNS?
No. Route 53 Private DNS uses VPC to manage visibility and provide DNS resolution for private DNS hosted zones. To take advantage of Route 53 Private DNS, you must configure a VPC and migrate your resources into it.
Q. Can I still use Private DNS if I’m not using VPC?
Yes, you can associate multiple VPCs with a single hosted zone.
Q. Can I use the same private Route 53 hosted zone for multiple VPCs?
Yes, you can associate VPCs belonging to different accounts with a single hosted zone. You can see more details here.
Q. Can I associate VPCs and private hosted zones that I created under different AWS accounts?
Yes, you can block domains and specific DNS names by creating these names in one or more Private DNS hosted zones and pointing these names to your own server (or another location that you manage).
Q. Can I use Private DNS to block domains and DNS names that I don’t want to be reached from within my VPC?
Visit the Amazon Route 53 Developer Guide for details on getting started. You can also configure DNS Failover from within the Route 53 Console.
Q. How do I get started with DNS Failover?
Yes, you can use DNS Failover to maintain a backup site (for example, a static site running on an Amazon S3 website bucket) and fail over to this site in the event that your primary site becomes unreachable.
Q. Can I configure a backup site to be used only when a health check fails?
You can associate any record type supported by Route 53 except SOA and NS records.
Q. What DNS record types can I associate with Route 53 health checks?
Yes. You can configure DNS Failover for Elastic Load Balancers and Amazon S3 website buckets via the Amazon Route 53 Console without needing to create a health check of your own. For these endpoint types, Route 53 automatically creates and manages health checks on your behalf which are used when you create an Alias record pointing to the ELB or S3 website bucket and enable the "Evaluate Target Health" parameter on the Alias record.
Q. Can I health check an endpoint if I don’t know its IP address?
Yes. Just like you can create a Route 53 resource record that points to an address outside AWS, you can set up health checks for parts of your application running outside AWS, and you can fail over to any endpoint that you choose, regardless of location. For example, you may have a legacy application running in a datacenter outside AWS and a backup instance of that application running within AWS. You can set up health checks of your legacy application running outside AWS, and if the application fails the health checks, you can fail over automatically to the backup instance in AWS.
Q. One of my endpoints is outside AWS. Can I set up DNS Failover on this endpoint?
No, Route 53 does not make routing decisions based on the load or available traffic capacity of your endpoints. You will need to ensure that you have available capacity at your other endpoints, or the ability to scale at those endpoints, in order to handle the traffic that had been flowing to your failed endpoint.
Q. If failover occurs and I have multiple healthy endpoints remaining, will Route 53 consider the load on my healthy endpoints when determining where to send traffic from the failed endpoint?
The default is a threshold of three health check observations: when an endpoint has failed three consecutive observations, Route 53 will consider it failed. However, Route 53 will continue to perform health check observations on the endpoint and will resume sending traffic to it once it passes three consecutive observations. You can change this threshold to any value between 1 and 10 observations. For more details, see the Amazon Route 53 Developer Guide.
Q. How many consecutive health check observations does an endpoint need to fail to be considered “failed”?
After a failed endpoint passes the number of consecutive health check observations that you specify when creating the health check (the default threshold is three observations), Route 53 will restore its DNS records automatically, and traffic to that endpoint will resume with no action required on your part.
Q. When my failed endpoint becomes healthy again, how is the DNS failover reversed?
By default, health check observations are conducted at an interval of 30 seconds. You can optionally select a fast interval of 10 seconds between observations.
Q. What is the interval between health check observations?
Each health check is conducted from multiple locations around the world. The number and set of locations is configurable; you can modify the number of locations from which each of your health checks is conducted using the Amazon Route 53 console or API. Each location checks the endpoint independently at the interval that you select: the default interval of 30 seconds, or an optional fast interval of 10 seconds. Based on the current default number of health checking locations, you should expect your endpoint to receive one request every 2-3 seconds on average for standard interval health checks and one or more requests per second for fast-interval health checks.
Q. How much load should I expect a health check to generate on my endpoint (for example, a web server)?
In simplest terms, the following events will take place if a health check fails and failover occurs:
Q. What is the sequence of events when failover happens?
The time for which a DNS resolver caches a response is set by a value called the time to live (TTL) associated with every record. We recommend a TTL of 60 seconds or less when using DNS Failover, to minimize the amount of time it takes for traffic to stop being routed to your failed endpoint. In order to configure DNS Failover for ELB and S3 Website endpoints, you need to use Alias records which have fixed TTL of 60 seconds; for these endpoint types, you do not need to adjust TTLs in order to use DNS Failover.
Q. Do I need to adjust the TTL for my records in order to use DNS Failover?
Route 53 can only fail over to an endpoint that is healthy. If there are no healthy endpoints remaining in a resource record set, Route 53 will behave as if all health checks are passing.
Q. What happens if all of my endpoints are unhealthy?
Yes. You can configure DNS Failover without using LBR. In particular, you can use DNS failover to configure a simple failover scenario where Route 53 monitors your primary website and fails over to a backup site in the event that your primary site is unavailable.
Q. Can I use DNS Failover without using Latency Based Routing (LBR)?
Yes. Route 53 supports health checks over HTTPS, HTTP or TCP.
Q. Can I configure a health check on a site accessible only via HTTPS?
No, HTTPS health checks test whether it’s possible to connect with the endpoint over SSL and whether the endpoint returns a valid HTTP response code. However, they do not validate the SSL certificate returned by the endpoint.
Q. Do HTTPS health checks validate the endpoint’s SSL certificate?
Yes, HTTPS health checks support SNI.
Q. Do HTTPS health checks support Server Name Indication (SNI)?
You can use Route 53 health checks to check for the presence of a designated string in a server response by selecting the “Enable String Matching” option. This option can be used to check a web server to verify that the HTML it serves contains an expected string. Or, you can create a dedicated status page and use it to check the health of the server from an internal or operational perspective. For more details, see the Amazon Route 53 Developer Guide.
Q. How can I use health checks to verify that my web server is returning the correct content?
You can view the current status of a health check, as well as details on why it has failed, in the Amazon Route 53 console and via the Route 53 API.
Q. How do I see the status of a health check that I’ve created?
Amazon Route 53 health checks include an optional latency measurement feature which provides data on how long it takes your endpoint to respond to a request. When you enable the latency measurement feature, the Amazon Route 53 health check will generate additional Amazon CloudWatch metrics showing the time required for Amazon Route 53’s health checkers to establish a connection and to begin receiving data. Amazon Route 53 provides a separate set of latency metrics for each AWS region where Amazon Route 53 health checks are conducted.
Q. How can I measure the performance of my application’s endpoints using Amazon Route 53?
Because each Route 53 health check publishes its results as a CloudWatch metric, you can configure the full range of CloudWatch notifications and automated actions which can be triggered when the health check value changes beyond a threshold that you specify. First, in either the Route 53 or CloudWatch console, configure a CloudWatch alarm on the health check metric. Then add a notification action and specify the email or SNS topic that you want to publish your notification to. Please consult the Route 53 Developer Guide for full details.
Q. How can I be notified if one of my endpoints starts failing its health check?
Confirmation emails can be re-sent from the SNS console. To find the name of the SNS topic associated with the alarm, click the alarm name within the Route 53 console and looking in the box labeled "Send notification to."
Q: I created an alarm for my health check, but I need to re-send the confirmation email for the alarm's SNS topic. How can I re-send this email?
The recommended method for setting up DNS Failover with ELB endpoints is to use Alias records with the "Evaluate Target Health" option. Because you don't create your own health checks for ELB endpoints when using this option, there are no specific CloudWatch metrics generated by Route 53 for these endpoints.
Q. I’m using DNS Failover with Elastic Load Balancers (ELBs) as endpoints. How can I see the status of these endpoints?
Amazon Route 53 performs health checks of the Amazon S3 service itself in each AWS region. When you enable Evaluate Target Health on an Alias record pointing to an Amazon S3 Website bucket, Amazon Route 53 will take into account the health of the Amazon S3 service in the AWS region where your bucket is located. Amazon Route 53 does not check whether a specific bucket exists or contains valid website content; Amazon Route 53 will only fail over to another location if the Amazon S3 service itself is unavailable in the AWS region where your bucket is located.
Q. For Alias records pointing to Amazon S3 Website buckets, what is being health checked when I set Evaluate Target Health to “true”?
CloudWatch metrics for Route 53 health checks are available free of charge.
Q. What is the cost to use CloudWatch metrics for my Route 53 health checks?
Yes. Amazon Route 53’s metric based health checks let you perform DNS failover based on any metric that is available within Amazon CloudWatch, including AWS-provided metrics and custom metrics from your own application. When you create a metric based health check within Amazon Route 53, the health check becomes unhealthy whenever its associated Amazon CloudWatch metric enters an alarm state.
Q. Can I configure DNS Failover based on internal health metrics, such as CPU load, network, or memory?
Occasionally, Amazon Route 53 customers create health checks that specify an IP address or domain name that does not belong to them. If your web server is getting unwanted HTTP(s) requests that you have traced to Amazon Route 53 health checks, please provide information on the unwanted health check using this form, and we will work with our customer to fix the problem.
Q. My web server is receiving requests from a Route 53 health check that I did not create. How can I stop these requests?
If you specify a domain name as the endpoint of an Amazon Route 53 health check, Amazon Route 53 will look up the IPv4 address of that domain name and will connect to the endpoint using IPv4. Amazon Route 53 will not attempt to look up the IPv6 address for an endpoint that is specified by domain name. If you want to perform a health check over IPv6 instead of IPv4, select "IP address" instead of "domain name" as your endpoint type, and enter the IPv6 address in the “IP address” field.
Q. If I specify a domain name as my health check target, will Amazon Route 53 check over IPv4 or IPv6?
AWS now publishes its current IP address ranges in JSON format. To view the current ranges, download the .json file using the following link. If you access this file programmatically, ensure that the application downloads the file only after successfully verifying the TLS certificate that is returned by the AWS server.
Q. Where can I find the IPv6 address ranges for Amazon Route 53’s DNS servers and health checkers?
Yes. You can use the AWS Management Console or API to register new domain names with Route 53. You can also request to transfer in existing domain names from other registrars to be managed by Route 53. Domain name registration services are provided under our Domain Name Registration Agreement.
Q. Can I register domain names with Amazon Route 53?
Route 53 offers a wide selection of both generic Top Level Domains (“gTLDs”: for example, .com and .net) and country-code Top Level Domains (“ccTLDs”: for example, .de and .fr). For the complete list, please see the Route 53 Domain Registration Price List.
Q. What Top Level Domains (“TLDs”) do you offer?
To get started, log into your account and click on “Domains”. Then, click the big blue “Register Domain” button and complete the registration process.
Q. How can I register a domain name with Route 53?
Depending on the TLD you’ve selected, registration can take from a few minutes to several hours. Once the domain is successfully registered, it will show up in your account.
Q. How long does it take to register a domain name?
The initial registration period is typically one year, although the registries for some top-level domains (TLDs) have longer registration periods. When you register a domain with Amazon Route 53 or you transfer domain registration to Amazon Route 53, we configure the domain to renew automatically. For more information, see Renewing Registration for a Domain in the Amazon Route 53 Developer Guide.
Q. How long is my domain name registered for?
In order to register a domain name, you need to provide contact information for the registrant of the domain, including name, address, phone number, and email address. If the administrative and technical contacts are different, you need to provide that contact information, too.
Q. What information do I need to provide to register a domain name?
For a list of TLDs please see the price list and for the specific registration requirements for each, please see the Amazon Route 53 Developer Guide and our Domain Name Registration Agreement.
Q. Where can I find the requirements for specific TLDs?
When your domain name is created we automatically associate your domain with four unique Route 53 name servers, known as a delegation set. You can view the delegation set for your domain in the Amazon Route 53 console. They're listed in the hosted zone that we create for you automatically when you register a domain.
Q. What name servers are used to register my domain name?
AWS resells domain names that are registered with ICANN-accredited registrars. Amazon Registrar, Inc. is an Amazon company that is accredited by ICANN to register domains. The registrar of record is the “Sponsoring Registrar” listed in the WHOIS record for your domain to indicate which registrar your domain is registered with.
Q. What is Amazon Registrar, Inc. and what is a registrar of record?
See our documentation for a list of the domains that you can currently register using Amazon Route 53. This list includes information about which registrar is the current registrar of record for each TLD that we sell.
Q. Which top-level domains does Amazon Route 53 register through Amazon Registrar and which ones does it register through Gandi?
No. We plan to add this functionality soon.
Q. Can I transfer my .com and .net domain registrations from Gandi to Amazon?
First, you need to get a list of the DNS record data for your domain name, generally available in the form of a “zone file” that you can get from your existing DNS provider. With the DNS record data in hand, you can use Route 53’s Management Console or simple web-services interface to create a hosted zone that can store the DNS records for your domain name and follow its transfer process, which will include such steps as updating the name servers for your domain name to the ones associated with your hosted zone. To complete the domain name transfer process, contact the registrar with whom you registered your domain name and follow its transfer process, which will include steps such as updating the name servers for your domain name to the ones associated with your hosted zone. As soon as your registrar propagates the new name server delegations, the DNS queries from your end users will start to get answered by the Route 53 DNS servers.
Q. How do I transfer my existing domain name registration to Amazon Route 53 without disrupting my existing web traffic?
You can view the status of domain name transfers in the “Alerts” section on the homepage of the Route 53 console.
Q. How do I check on the status of my transfer request?
You will need to contact your current registrar in order to determine why your transfer failed. Once they have resolved the issue, you can resubmit your transfer request.
Q. What do I do if my transfer wasn’t successful?
In order to move your domain name away from Route 53, you need to initiate a transfer request with your new registrar. They will request the domain name be moved to their management.
Q. How do I transfer my domain name to a different registrar?
Each new Amazon Route 53 account is limited to a maximum of 50 domains. Complete our request form for a higher limit and we will respond to your request within two business days.
Q. Is there a limit to the number of domains I can manage using Amazon Route 53?
Amazon Route 53’s DNS services does NOT support DNSSEC at this time. However, our domain name registration service supports configuration of signed DNSSEC keys for domains when DNS service is configured at another provider. More information on configuring DNSSEC for your domain name registration can be found here.
Q. Does Amazon Route 53 DNS support DNSSEC?
See our documentation for a step-by-step guide on transferring your DNSSEC-enabled domain to Amazon Route 53.
Q. How do I transfer a domain registration that has DNSSEC enabled to Amazon Route 53?
Conditional forwarding rules allow Resolver to forward queries for specified domains to the target IP address of your choice, typically an on-premises DNS resolver. Rules are applied at the VPC level and can be managed from one account and shared across multiple accounts.
Q. What are conditional forwarding rules?
Those rules will no longer be usable by the accounts you previously shared them with. This means that if those rules were associated to VPCs in those accounts, they will be disassociated from those VPCs.
Q. What happens if I decide to stop sharing rules with other accounts?
Visit our AWS Region Table to see which regions Route 53 Resolver has launched in.
Q. What regions are available for Route 53 Resolver?
No. Amazon Route 53 public and private DNS, traffic flow, health checks, and domain name registration are all global services.
Q. Does regional support for Route 53 Resolver mean that all of Amazon Route 53 is now regional?
Visit the Amazon Route 53 developer guide for details on getting started. You can also configure Resolver from within the Amazon Route 53 console.
Q. How do I get started with Route 53 Resolver?