Route 53 and Azure Services
Overview
In this article, we summarize Route 53 features and compare with Azure services. Seems to me AWS invested more in its Route 53 product.
We will discuss some of the features in more detail, including
- public and private hosted zones
- DNS query logging
- DNSSEC
- Route 53 resolver
- Centralized DNS management in hybrid network
- Scaling DNS Management Across Multiple Accounts and VPCs
- CloudWatch Contributor Insights and Anomaly Detection
Public Hosted Zone
You could use Route53 for zone management only, or you could use route53 for both domain registration and zone management.
In case you register domain with other domain registrar, update the registration with the authoritative name servers listed in your zone NS record.
Private Hosted Zone
Private hosted zone list four name servers as well.
Query Logging
DNS query log can be sent over to different destination, here the screenshot shows two CloudWatch log group, one is for pubic hosted zone query log, one is for route 53 resolver query log.
In Azure, there are metrics associated with Azure DNS, but I’m not sure if it supports any diagnostic log.
Route 53 Resolver
Based on AWS blog, the vendor does not recommend to use route53 resolver rules for the centralized DNS management within AWS accounts.
Although it is possible to use forwarding rules to resolve private hosted zones in other VPCs, we do not recommend that. The most reliable, performant and low-cost approach is to share and associate private hosted zones directly to all VPCs that need them.
Also based on AWS white paper, you don’t need to peer spoke VPCs to the centralized DNS resolver endpoint VPC, or connect them via Transit Gateway. You use RAM to share resolver rules with spoke VPC and associate spoke private hosted zone with the centralized DNS VPC.
Centralized DNS management in hybrid network
Coordinating DNS resolution between AWS Landing Zone setup and on-premises resources is one of the most critical pieces in a hybrid network. AWS route 53 resolver endpoint and forwarding rules can help to address the challenge.
When configure Route53 endpoint, AWS create elastic network interface.
On prem DNS server forward inbound DNS query to your VPC through inbound Route 53 resolver endpoint, you configure your on prem DNS server to forward to the IP address of the endpoint elastic network interface.
For outbound forwarding, you also specify domain name of the query that you want to forward and target IP address (your on prem DNS resolver IP address). From your vpc, when query <sth>.corp.internal, it is forwarded to your on prem network.
In Azure, you will have to build your own DNS bind server in Azure to handle forwarding and achieve the name resolution between the public cloud and on prem network.
DNS Management Across Multiple Accounts and VPCs
AWS whitepaper proposed multiple options. Both options rely on associating one single zone to multiple VPCs, meaning if you need to resolve a FQDN from a specific domain in ten other VPCs, all these ten VPCs have to be associated with this specific zone.
Private hosted zones in one shared account.
Private hosted zone is distributed to each account.
There is a quota limit on how many VPCs can be associated with a zone, Amazon VPCs that you can associate with a private hosted zone per hosted zone is 300 (https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DNSLimitations.html#limits-api-entities-hosted-zones), this quota can be increased upon request.
In my opinion, this recommendation requires more work to manage the zone association for ongoing basis.
In Azure, it’s possible to add multiple vnet links to a zone, but since you already build your own Azure DNS forwarder, you could utilize the same infrastructure to support centralized DNS management across multiple Azure subscriptions.
DNSSEC
Domain Name System Security Extensions (DNSSEC) signing lets DNS resolvers validate that a DNS response came from Amazon Route 53 and has not been tampered with. DNSSEC signing is for public hosted zone.
When you enable DNSSEC signing for a hosted zone, Route 53 adds cryptographic signatures to your DNS records. You will also need to validate from resolver.
DNSSEC for a domain
First enable DNSSEC signing for the zone, Route 53 create KSK (key signing key) based on your asymmetric key from KMS.
Signature is created or the record is signed in your hosted zone with the private key.
After DNSSEC signing is enabled, retrieve Delegation Signer (DS) record information from the hosted zone.
Last step is to add public key to the domain. From registered domain, at the DNSSEC status field, choose Manage keys.
Public key and the algorithm are kept in the registry for the top-level domain (TLD).
Enable Resolver DNSSEC Validation
The validation only applies to public DNS records.
DNS resolver receives Delegation Signer (DS) record from the TLD registry, DS record contains public key and algorithm. After the resolver gets the answer from name server, signature of the DNS record is validated by resolver using the public key.
CloudWatch Contributor Insights and Anomaly Detection
Environment Setup Steps
- Create DNS Firewall Group and Rules
(use AWS malware block list and create your own deny and allow list
Note: Managed domain lists cannot be downloaded or browsed — https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html. ) - Associate DNS Firewall group with VPC
- Create CloudWatch log group
- Enable resolver query log for the VPC
- Configure CloudWatch Contributor Insights
My own domain list and associated with deny rule.
CloudWatch Insight Rule for blocked DNS query.
Generate Query Traffic
Create EC2 in the VPC, perform nslookup for couple of FQDNs. They are blocked by DNS firewall, badquery1 is blocked by AWS manged domain list. badquery7 is blocked by user domain list.
sh-4.2$ nslookup www.badquery1.com
Server: 172.31.0.2
Address: 172.31.0.2#53** server can't find www.badquery1.com: NXDOMAINsh-4.2$ nslookup www.badquery7.com
Server: 172.31.0.2
Address: 172.31.0.2#53Non-authoritative answer:
*** Can't find www.badquery7.com: No answer
Somehow CloudWatch log does not capture DNS firewall rule related fields for the AWS domain list, it only populated those fields for use domain list rule.
Top Contributor
Here shows from my EC2 IP address, multiple DNS queries are blocked by DNS firewall.
Somehow it does not count the query for www.badquery1.com, my best guess is that the insight covers user domain list rule only.
VpcFirewallQueryVolume Metric Anomaly Detection
CloudWatch Anomaly Detection surfaces anomalies with minimal user intervention. When you enable the feature for a specific metric, it generates a machine learning (ML) model by applying statistical and ML algorithms to continuously analyze your systems and applications to determine “normal” baselines — a range of expected values that represent normal metric behavior.
- Enable anomaly detection for the metric
- CloudWatch Anomaly Detection uses up to two weeks of historical data for training. For the best result, at least three days of data is recommended.
- In a graph with anomaly detection, the expected range of values is shown as a gray band. If the metric’s actual value goes beyond this band, it is shown as red during that time.
Alert can be configured using the anomaly detection band as a threshold.
References
This blog covers “Resolving private domains between workloads running in different AWS accounts” through sharing resolver rule.
This blog says “best practices for Route 53 Resolver:” Although it is possible to use forwarding rules to resolve private hosted zones in other VPCs, we do not recommend that. The most reliable, performant and low-cost approach is to share and associate private hosted zones directly to all VPCs that need them.
