Tag: route53

Route 53 提供 100% SLA，而 Route 53 Resolver 提供 99.99% SLA

AWS 宣佈 Route 53 提供 100% 的 SLA，而 Route 53 Resolver 則提供 99.99% 的 SLA：「Amazon Route 53 Resolver Endpoints announces 99.99% Service Level Agreement and updates its Service Level Agreement for Route 53 hosted zones」。

Route 53 的部份指的是 hosted zone，參考「Amazon Route 53 Service Level Agreement」這邊，可以看到是 2022/08/29 更新的條款。

Route 53 Resolver 的部份可以參考「Amazon Route 53 Resolver Endpoints Service Level Agreement」這邊，也是 2022/08/29 更新的條款。

要注意 99.99% 是指 Multi-AZ Resolver Endpoints SLA；如果是 Single-AZ Resolver Endpoints SLA 看起來是設定在 99.5%。

不確定是不是 AWS 的第一個 100% SLA 條款...

Route 53 支援 DNS64，以及 NAT Gateway 支援 NAT64

AWS 宣佈了一套機制，讓 IPv6-only 的機器可以連到 IPv4-only 的服務：「Let Your IPv6-only Workloads Connect to IPv4 Services」。

首先是 DNS64，針對只有 IPv4-only 的 A record 自動加上 AAAA record (如果已經有 AAAA record 的則不變)，這邊提到的 64:ff9b::/96 是來自 DNS64 標準內的規範：

The DNS resolver first checks if the record contains an IPv6 address (AAAA record). If it does, the IPv6 address is returned. The IPv6 host can connect to the service using just IPv6. When the record only contains an IPv4 address, the Route 53 resolver synthesizes an IPv6 address by prepending the well-known 64:ff9b::/96 prefix to the IPv4 address.

再來就是 NAT Gateway 可以把 64:ff9b::/96 透過 NAT64 轉到 IPv4 network 上：

You may configure subnet routing to send all packets starting with 64:ff9b::/96 to the NAT gateway. The NAT gateway recognizes the IPv6 address prefix, extracts the IPv4 address from it, and initiates an IPv4 connection to the destination. As usual, the source IPv4 address is the IPv4 address of the NAT gateway itself.

由於有些 protocol 會帶 IP address 資訊，所以不能保證 NAT64 一定會動，但大多數的情況應該是可以解決，至少提供了 IPv6-only server 連到 IPv4-only network 上的方法...

AWS 推出 Amazon Route 53 Resolver DNS Firewall

長久以來的洞總算有比較好的方法補上了，AWS 推出了 Amazon Route 53 Resolver DNS Firewall：「Introducing Amazon Route 53 Resolver DNS Firewall」。

Route 53 Resolver 是 AWS 官方提供的 DNS Resolver，沒有特殊的設定的話通常會在 x.x.x.2 (/24 或是更大的網段)，先前一直沒有辦法解決 data leak 的問題，也就是透過 DNS 把敏感資料從 private network 裡丟出去。

以前的作法是透過 security group 擋掉對 Route 53 Resolver 的流量 (或是透過 VPC 的 Firewall 擋)，然後自己架設兩台 DNS resolver 過濾，現在 Route 53 Resolver 支援 DNS Firewall，提供 allowlist 與 blocklist 這兩個功能使用，總算是把這件事情解的比較乾淨了：

Route 53 Resolver DNS Firewall lets you create “blocklists” for domains you don’t want your VPC resources to communicate with via DNS. You can also take a stricter, “walled-garden” approach by creating “allowlists” that permit outbound DNS queries only to domains you specify. You can also create alerts for when outbound DNS queries match certain firewall rules, allowing you to test your rules before deploying for production traffic.

另外這次的 DNS Firwall 提供了兩組由 AWS 維護的清單讓人使用，包括了 malware 與 botnet：

Route 53 Resolver DNS Firewall offers two managed domain lists—malware domains and botnet command and control domains—enabling you to get started quickly with managed protections against common threats.

這樣省事多了...

Amazon Route 53 支援 DNSSEC

也是個大家等蠻久的功能，AWS 總算在 Amazon Route 53 上推出 DNSSEC 了：「Announcing Amazon Route 53 support for DNSSEC」。

他需要掛 AWS KMS，這部份會有一些費用在裡面，不過應該是還好...

不過 web console 目前有個明顯的缺點：透過 Route 53 註冊的網域，又用 Route 53 自家服務的情況下，設定 DNSSEC 的整合沒有做的很好，不能直接快速設定。

現在得自己設定演算法，然後複製 public key 到另外一邊，當你有一堆網域要設定的時候就會覺得很煩了...

AWS 推出 Route 53 Resolver Query Logs

AWS 推出可以讓你 debug 的功能：「Log your VPC DNS queries with Route 53 Resolver Query Logs」。

這個功能可以記錄 VPC 內的 DNS query：

然後也可以統計與分析：

主要是很多 debug 會需要 DNS query，但 AWS 上不太容易看到 DNS query 資訊 (常見的方式是自己另外架 DNS Resolver)，這個功能可以緩解這個問題...

Amazon Route 53 增加了即時的 Query 數量資訊

AWS 對 Route 53 增加了 Query 數量的資訊 (加到 CloudWatch 內)：「Amazon Route 53 Now Publishes Query Volume Metrics for Public Hosted Zones」。

下午的時候連進去看沒看到，回家後想起來 Route 53 是全球性服務，切到 us-east-1 上就看到了...

算是很基本的功能，這樣可以很方便的看一下使用情況，然後就可以透過這些資料調整 TTL，有些為了要快速切換的可以設短一點，有些不太變動但 query 量很大的則是要設長一點...

Amazon ECS 的 Service Discovery

AWS 宣佈了 Amazon ECS 也支援 Route 53 提供的 Service Discovery 了：「Introducing Service Discovery for Amazon ECS」。

也就是說現在都整合好了... 比較一下先前需要自己包裝起來套用的方式會少不少功夫：

Previously, to ensure that services were able to discover and connect with each other, you had to configure and run your own service discovery system or connect every service to a load balancer. Now, you can enable service discovery for your containerized services with a simple selection in the ECS console, AWS CLI, or using the ECS API.

AWS 在 2016 年的時候有寫一篇「Service Discovery for Amazon ECS Using DNS」在講怎麼透過事件的觸發配合 AWS Lambda 把服務掛上去或是移除掉：

Recently, we proposed a reference architecture for ELB-based service discovery that uses Amazon CloudWatch Events and AWS Lambda to register the service in Amazon Route 53 and uses Elastic Load Balancing functionality to perform health checks and manage request routing. An ELB-based service discovery solution works well for most services, but some services do not need a load balancer.

現在看起來都可以改用 Auto Naming API 了...

Amazon Route 53 的 Auto Naming API 可以指到 CNAME 位置了

Amazon Route 53 的 Auto Naming API 可以拿來跑 Service Discovery (參考先前的「用 Amazon Route 53 做 Service Discovery」這篇)，當時是 A/AAAA/SRV record，現在則可以註冊 CNAME 了：「Amazon Route 53 Auto Naming Announces Support for CNAME Record Type and Alias to ELB」。

最直接的影響就是 ELB 的部份了，透過 ELB 處理前端的話，覆載平衡以及數量限制的問題就會減輕很多 (之前是靠 Round-robin DNS 打散，而且限制一次最多回應五個 record)：

Beginning today, you can use the Amazon Route 53 Auto Naming APIs to create CNAME records when you register instances of your microservices, and your microservices can discover the CNAMEs by querying DNS for the service name. Additionally, you can use the Amazon Route 53 Auto Naming APIs to create Route 53 alias records that route traffic to Amazon Elastic Load Balancers (ELBs).

用 Amazon Route 53 做 Service Discovery

Amazon Route 53 的新功能，可以解決以前自己要建立 Service Discovery 服務的工作：「Amazon Route 53 Releases Auto Naming API for Service Name Management and Discovery」。官方的文件在「Using Autonaming for Service Discovery」這邊。

不過目前有些限制，一個 namespace (domain name) 目前只能有五個服務：

DNS settings for up to five records.

然後 DNS 回應時，最多回八個 record：

When Amazon Route 53 receives a DNS query for the name of an instance, such as backend.example.com, it responds with up to eight IP addresses (for A or AAAA records) or up to eight SRV record values.

回應八個 record，但應該是可以註冊超過八個吧... (i.e. 每次都回不一樣)

自建服務 (像是 Cassandra 或是 ScyllaDB) 可以直接用這個服務掛上去，就不用自己架 Consul 了。

目前支援了這四區，亞洲不在這波提供範圍：

Amazon Route 53 Auto Naming is available in US East (N. Virginia), US East (Ohio), US West (Oregon), and EU (Ireland) regions.

AWS 提供 Hybrid Cloud 環境下 DNS 管理的說明

不知道為什麼出現在 browser tab 上，不知道是哪邊看到的... AWS 放出了一份文件，在講 hybrid cloud 環境下當你同時有一般 IDC 機房，而且使用內部 domain 在管理時，網路與 AWS 打通後要怎麼解決 DNS resolver 的問題：「Hybrid Cloud DNS Solutions for Amazon VPC」。

有些東西在官方的說明文件內都寫過，但是是 AWS 的特殊設計，這邊就會重複說明 XDDD

像是這份文件裡提到 Amazon DNS Server 一定會在 VPC 的 base 位置加二 (舉例來說，10.0.0.0/16 的 VPC，Amazon DNS Server 會在 10.0.0.2)：

Amazon DNS Server
The Amazon DNS Server in a VPC provides full public DNS resolution, with additional resolution for internal records for the VPC and customer-defined Route 53 private DNS records.4 The AmazonProvidedDNS maps to a DNS server running on a reserved IP address at the base of the VPC network range, plus two. For example, the DNS Server on a 10.0.0.0/16 network is located at 10.0.0.2. For VPCs with multiple CIDR blocks, the DNS server IP address is located in the primary CIDR block.

在官方文件裡，則是在「DHCP Options Sets」這邊提到一樣的事情：

When you create a VPC, we automatically create a set of DHCP options and associate them with the VPC. This set includes two options: domain-name-servers=AmazonProvidedDNS, and domain-name=domain-name-for-your-region. AmazonProvidedDNS is an Amazon DNS server, and this option enables DNS for instances that need to communicate over the VPC's Internet gateway. The string AmazonProvidedDNS maps to a DNS server running on a reserved IP address at the base of the VPC IPv4 network range, plus two. For example, the DNS Server on a 10.0.0.0/16 network is located at 10.0.0.2. For VPCs with multiple IPv4 CIDR blocks, the DNS server IP address is located in the primary CIDR block.

另外也還是有些東西在官方的說明文件內沒看過，像是講到 Elastic Network Interface (ENI) 對 Amazon DNS Server 是有封包數量限制的；這點我沒在官方文件上找到，明顯在量太大的時候會中獎，然後開 Support Ticket 才會發現的啊 XDDD：

Each network interface in an Amazon VPC has a hard limit of 1024 packets that it can send to the Amazon Provided DNS server every second.

Anyway... 這份文件裡面提供三種解法：

  • Secondary DNS in a VPC，直接用程式抄一份到 Amazon Route 53 上，這樣 Amazon DNS Server 就可以直接看到了，這也是 AWS 在一般情況下比較推薦的作法。
  • Highly Distributed Forwarders，每台 instance 都跑 Unbound，然後針對不同的 domain 導開，這樣可以有效避開單一 ENI 對 Amazon DNS Server 的封包數量限制，但缺點是這樣的設計通常會需要像是 Puppet 或是 Chef 之類的軟體管理工具才會比較好設定。
  • Zonal Forwarders Using Supersede，就是在上面架設一組 Unbound 伺服器集中管理，透過 DHCP 設定讓 instance 用。但就要注意量不能太大，不然 ENI 對 Amazon DNS Server 的限制可能會爆掉 XD

都可以考慮看看...