![[アップデート] Amazon Route 53のPublic Hosted ZoneでIPベースルーティングができるようになりました](https://devio2023-media.developers.io/wp-content/uploads/2019/05/amazon-route-53.png)
[アップデート] Amazon Route 53のPublic Hosted ZoneでIPベースルーティングができるようになりました
アクセス元のIPアドレスによって名前解決の結果を変えたいな
こんにちは、のんピ(@non____97)です。
皆さんはアクセス元のIPアドレスによって名前解決の結果を変えたいなと思ったことはありますか? 私はあります。
名前解決先のドメインによってリゾルバーを変える機能として条件付きフォワーダーがあります。それと同じような使い勝手で、アクセス元のIPアドレスによって名前解決の結果を変えたくなる時がたまにあります。
今回、Amazon Route 53のPublic Hosted ZoneでIPベースルーティングができるようになりました。
まさに欲しかった機能が来たぞという感じですね。
AWS公式ブログも投稿されています。
早速触ってみたので紹介します。
いきなりまとめ
- IPベースルーティングを使うことで、アクセス元のIPアドレスによって名前解決の結果を変更することが可能
- CIDRコレクションにルーティング先を変更したいアクセス元IPアドレスのCIDRを指定する
- CIDRコレクションには以下のCIDRブロックを複数追加可能
- IPv4 :
/0〜/24 - IPv6 :
/0〜/48
- IPv4 :
- アクセス元のクライアント(スタブリゾルバ)のIPアドレスでルーティングをしたい場合は、キャッシュDNSサーバーがEDNS0のedns-client-subnetをサポートしている必要がある
- キャッシュDNSサーバーがedns-client-subnetをサポートしていない環境でIPベースルーティングを使用する場合は、キャッシュDNSサーバーのIPアドレスをCIDRコレクションに追加しておく必要がある
- 2022/6/3時点、Private Hosted Zoneでは未サポート
IPベースルーティングの確認
特徴
まず、IPベースルーティングとはどんな機能か確認します。
IPベースルーティングとは文字通り、アクセス元のIPアドレスによって名前解決の結果を変更する機能です。
使い方としては、まず、CIDRコレクションというIPアドレスの範囲をまとめたリソースを作成します。そして、CIDRコレクションとレコードを関連付けることで、アクセス元IPアドレスがCIDRコレクションにマッチした場合に、それに対応したレコードを返却するといった形です。
CIDRコレクションには以下のようなCIDRブロックを複数追加することができます。
- IPv4 :
/0〜/24 - IPv6 :
/0〜/48
/32で指定することはできないので、ピンポイントでこのIPアドレスからのみ結果を変えるということは2022/6/3時点ではできなさそうですね。
注意点は、アクセス元のクライアント(スタブリゾルバ)のIPアドレスでルーティングをしたい場合は、キャッシュDNSサーバーがEDNS0のedns-client-subnetをサポートしている必要がある点です。
Route 53では位置情報ルーティングポリシーや地理的近接性ルーティングポリシー、レイテンシールーティングポリシーの精度を向上させるためにedns-client-subnetを使用しています。
To improve the accuracy of geolocation, geoproximity, IP-based, and latency routing, Amazon Route 53 supports the edns-client-subnet extension of EDNS0. (EDNS0 adds several optional extensions to the DNS protocol.) Route 53 can use edns-client-subnet only when DNS resolvers support it:
- When a browser or other viewer uses a DNS resolver that does not support edns-client-subnet, Route 53 uses the source IP address of the DNS resolver to approximate the location of the user and responds to geolocation queries with the DNS record for the resolver's location.
When a browser or other viewer uses a DNS resolver that does support edns-client-subnet, the DNS resolver sends Route 53 a truncated version of the user's IP address. Route 53 determines the location of the user based on the truncated IP address rather than the source IP address of the DNS resolver; this typically provides a more accurate estimate of the user's location. Route 53 then responds to geolocation queries with the DNS record for the user's location.
EDNS0 is not applicable to private hosted zones. For private hosted zones Route 53 uses data from the Route 53 Resolvers in the AWS Region that the private hosted zone is in to make geolocation and latency routing decisions.
How Amazon Route 53 uses EDNS0 to estimate the location of a user - Amazon Route 53
実際に、EDNS Compliance TesterでRoute 53上のドメインがedns-client-subnetをサポートしているか確認できました。
キャッシュDNSサーバーがedns-client-subnetをサポートしている場合は、アクセス元のクライアント(スタブリゾルバ)のIPアドレスをX-Forwarded-ForのようにコンテンツDNSサーバーに通知することができるので、アクセス元のクライアント(スタブリゾルバ)のIPアドレスでルーティングすることが可能です。
一方で、edns-client-subnetをサポートしていない場合は、ルーティングの判定に使用されるIPアドレスはキャッシュDNSサーバーのIPアドレスになります。そのため、キャッシュDNSサーバーがedns-client-subnetをサポートしていない環境でIPベースルーティングを使用する場合は、キャッシュDNSサーバーのIPアドレスをCIDRコレクションに追加しておく必要があります。
キャッシュDNSサーバーがedns-client-subnetをサポートしているかを確認する方法は以下AWS公式ドキュメントで紹介されています。
紹介されているコマンドで、キャッシュDNSサーバーがedns-client-subnetをサポートしているか確認してみます。
# Amazon Provided DNS $ dig +nocl TXT o-o.myaddr.l.google.com +short @169.254.169.253 "44.192.160.25" # Google Public DNS $ dig +nocl TXT o-o.myaddr.l.google.com +short @8.8.8.8 "74.125.18.1" "edns0-client-subnet 54.159.156.0/24" # 1.1.1.1 $ dig +nocl TXT o-o.myaddr.l.google.com +short @1.1.1.1 "2400:cb00:354:1024::ac46:859b" # Quad9 $ dig +nocl TXT o-o.myaddr.l.google.com +short @9.9.9.9 "74.63.17.243" # Dyn Internet Guide $ dig +nocl TXT o-o.myaddr.l.google.com +short @216.146.35.35 "129.149.56.47"
出力結果にedns0-client-subnetの行があるキャッシュDNSサーバーがedns-client-subnetをサポートしています。上の結果だと8.8.8.8はedns-client-subnetをサポートしており、クライアントサブネット54.159.156.0/24がコンテンツDNSサーバーに送信されています。
ユースケース
ユースケースとしては、社内で使用しているIPアドレスからのアクセスする場合にのみ、先行して新しいバージョンのコンテンツを提供するケースが挙げられます。社内だけ先行してテストするというのがしやすくなりますね。
ただし、上述した通りIPv4のサブネットマスクの最小は/24なので、管理しているグローバルIPアドレスが/25や/26など/24未満の場合には向いていないです。
AWS公式ドキュメントにもいくつかユースケースが紹介されていました。
Geolocation and latency-based routing is based on data that Route 53 collects and keeps up to date. This approach works well for the majority of customers, but IP-based routing offers you the additional ability to optimize routing based on specific knowledge of your customer base. For example, a global video content provider may want to route end users from a particular Internet Service.
Some common use cases for IP-based routing are as follows:
- You want to route end users from certain ISPs to specific endpoints in order to optimize network transit costs or performance.
- You want to add overrides to existing Route 53 routing types such as geolocation routing based on your knowledge of your clients' physical locations.
制限事項
2022/6/3時点で、いくつか制限事項もあるので紹介します。
- アカウントごとに作成できるCIDRコレクションは最大5つ
- Service Quotas で上限引き上げ可能
- 各CIDRコレクションには最大1,000のCIDRブロック追加可能
- Service Quotas で上限引き上げ可能
- Private Hosted Zoneでは未サポート
最新のクォータについては以下AWS公式ドキュメントをご覧ください。
料金
料金についても触れておきます。
IPベースルーティングを使用する際、クエリ毎に以下の課金が発生します。
- $0.80 : 100万クエリ毎(最初の10億クエリまで)
- $0.40 : 100万クエリ毎(最初の10億クエリまで)
また、IPベースルーティングを使用する際に必要なCIDRコレクションについても課金が発生します。
- 無料 : 1000CIDRブロックまで
- $0.0015 : 1000CIDRブロックを超過したCIDRブロック毎（1時間ごとに按分）
最新の料金はAWS公式ページをご覧ください。
やってみた
CIDRコレクションの作成
それではIPベースルーティングの動作確認をしてみます。
まず、CIDRコレクションの作成をします。
CIDRコレクションに追加するCIDRを把握するため、クライアントとして使用するEC2インスタンスのグローバルIPアドレスを確認します。
$ curl https://checkip.amazonaws.com/ 34.230.33.206
こちらのIPアドレスがどのようなネットワークに属していて、誰に管理されているかwhoisで確認します。
# whois コマンドがあるか確認 $ which whois which: no whois in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin) # whois をインストール $ sudo yum install whois Loaded plugins: extras_suggestions, langpacks, priorities, update-motd amzn2-core | 3.7 kB 00:00:00 Resolving Dependencies --> Running transaction check ---> Package whois.x86_64 0:5.1.1-2.amzn2.0.1 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================================================================= Package Arch Version Repository Size ================================================================================================================================= Installing: whois x86_64 5.1.1-2.amzn2.0.1 amzn2-core 72 k Transaction Summary ================================================================================================================================= Install 1 Package Total download size: 72 k Installed size: 218 k Is this ok [y/d/N]: y Downloading packages: whois-5.1.1-2.amzn2.0.1.x86_64.rpm | 72 kB 00:00:00 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : whois-5.1.1-2.amzn2.0.1.x86_64 1/1 Verifying : whois-5.1.1-2.amzn2.0.1.x86_64 1/1 Installed: whois.x86_64 0:5.1.1-2.amzn2.0.1 Complete! # "34.230.33.206" がどのようなネットワークに属していて、誰に管理されているか確認 $ whois 34.230.33.206 # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/resources/registry/whois/tou/ # # If you see inaccuracies in the results, please report at # https://www.arin.net/resources/registry/whois/inaccuracy_reporting/ # # Copyright 1997-2022, American Registry for Internet Numbers, Ltd. # NetRange: 34.192.0.0 - 34.255.255.255 CIDR: 34.192.0.0/10 NetName: AT-88-Z NetHandle: NET-34-192-0-0-1 Parent: NET34 (NET-34-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Amazon Technologies Inc. (AT-88-Z) RegDate: 2016-09-12 Updated: 2016-09-12 Ref: https://rdap.arin.net/registry/ip/34.192.0.0 OrgName: Amazon Technologies Inc. OrgId: AT-88-Z Address: 410 Terry Ave N. City: Seattle StateProv: WA PostalCode: 98109 Country: US RegDate: 2011-12-08 Updated: 2021-07-28 Comment: All abuse reports MUST include: Comment: * src IP Comment: * dest IP (your IP) Comment: * dest port Comment: * Accurate date/timestamp and timezone of activity Comment: * Intensity/frequency (short log extracts) Comment: * Your contact details (phone and email) Without these we will be unable to identify the correct owner of the IP address at that point in time. Ref: https://rdap.arin.net/registry/entity/AT-88-Z OrgRoutingHandle: ARMP-ARIN OrgRoutingName: AWS RPKI Management POC OrgRoutingPhone: +1-206-266-4064 OrgRoutingEmail: aws-rpki-routing-poc@amazon.com OrgRoutingRef: https://rdap.arin.net/registry/entity/ARMP-ARIN OrgAbuseHandle: AEA8-ARIN OrgAbuseName: Amazon EC2 Abuse OrgAbusePhone: +1-206-266-4064 OrgAbuseEmail: abuse@amazonaws.com OrgAbuseRef: https://rdap.arin.net/registry/entity/AEA8-ARIN OrgRoutingHandle: IPROU3-ARIN OrgRoutingName: IP Routing OrgRoutingPhone: +1-206-266-4064 OrgRoutingEmail: aws-routing-poc@amazon.com OrgRoutingRef: https://rdap.arin.net/registry/entity/IPROU3-ARIN OrgTechHandle: ANO24-ARIN OrgTechName: Amazon EC2 Network Operations OrgTechPhone: +1-206-266-4064 OrgTechEmail: amzn-noc-contact@amazon.com OrgTechRef: https://rdap.arin.net/registry/entity/ANO24-ARIN OrgNOCHandle: AANO1-ARIN OrgNOCName: Amazon AWS Network Operations OrgNOCPhone: +1-206-266-4064 OrgNOCEmail: amzn-noc-contact@amazon.com OrgNOCRef: https://rdap.arin.net/registry/entity/AANO1-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/resources/registry/whois/tou/ # # If you see inaccuracies in the results, please report at # https://www.arin.net/resources/registry/whois/inaccuracy_reporting/ # # Copyright 1997-2022, American Registry for Internet Numbers, Ltd. #
34.192.0.0/10というネットワークでAmazon Technologies Inc.に管理されているようですね。
なお、AWSで使用されるグローバルIPアドレスは以下公式ドキュメントで公開されています。そのため、わざわざwhoisで確認する必要はありません。
CIDRを確認したら、Route 53のコンソールからCIDRコレクション-CIDRコレクションを作成をクリックします。
コレクション名やCIDRの場所を入力して、CIDRコレクションを作成をクリックします。
CIDRコレクションの作成ができました。
Public Hosted Zoneの作成
次にPublic Hosted Zoneの作成をします。
corp.non-97.netというドメイン名でPublic Hosted Zoneを作成しました。
親ドメインのnon-97.netはGoogle Domainsで管理しています。以下記事を参考に、Google Domainsでcorp.non-97.netのNSレコードを指定してあげます。
設定後、手元のPCからcorp.non-97.netのNSレコードを確認すると、AWSのDNSサーバーが返ってきました。
> dig corp.non-97.net NS ; <<>> DiG 9.10.6 <<>> corp.non-97.net NS ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13926 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;corp.non-97.net. IN NS ;; ANSWER SECTION: corp.non-97.net. 172800 IN NS ns-119.awsdns-14.com. corp.non-97.net. 172800 IN NS ns-1201.awsdns-22.org. corp.non-97.net. 172800 IN NS ns-2012.awsdns-59.co.uk. corp.non-97.net. 172800 IN NS ns-737.awsdns-28.net. ;; AUTHORITY SECTION: corp.non-97.net. 172800 IN NS ns-119.awsdns-14.com. corp.non-97.net. 172800 IN NS ns-1201.awsdns-22.org. corp.non-97.net. 172800 IN NS ns-2012.awsdns-59.co.uk. corp.non-97.net. 172800 IN NS ns-737.awsdns-28.net. ;; Query time: 132 msec ;; SERVER: 127.0.2.2#53(127.0.2.2) ;; WHEN: Fri Jun 03 10:19:16 JST 2022 ;; MSG SIZE rcvd: 241
IPベースルーティングのレコードの作成
それでは、本題のIPベースルーティングのレコードの作成をします。
私はクラスメソッド唯一で、全国に5人しかいない「「2022 APN AWS Top Engineers (Networking)」」に選ばれたので、レコード名はtop-engineerとでもしておきます。ゾーンの種類がPublic Hosted Zoneなので値にはグローバルIPアドレスを指定したいところですが、私はグローバルIPアドレスの管理はしていないです。他所様のグローバルIPアドレスを指定するのも良くないので10.1.1.1とプライベートIPアドレスを指定してあげます。
ルーティングポリシーはもちろんIPベースで、IPベースでは先ほど作成したCIDRコレクション内のCIDRの場所であるus-east-1を指定します。
ちなみに別で用意したPrivate Hosted Zoneのprivate.non-97.netではルーティングポリシーでIPベースを指定することはできませんでした。Private Hosted Zoneでサポートされるようになるのを気長に待ちましょう。
動作確認
それでは、動作確認をします。
まず、普通にEC2インスタンスからtop-engineer.corp.non-97.netの名前解決をしてみます。
$ dig top-engineer.corp.non-97.net ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> top-engineer.corp.non-97.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15978 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;top-engineer.corp.non-97.net. IN A ;; Query time: 0 msec ;; SERVER: 10.0.0.2#53(10.0.0.2) ;; WHEN: Fri Jun 03 01:30:48 UTC 2022 ;; MSG SIZE rcvd: 57
CIDRコレクションに追加したIPアドレスから問い合わせたにも関わらず、ANSWER SECTIONがないですね。
原因はAmazon Provided DNS(10.0.0.2)がキャッシュDNSサーバーとして指定されているからです。
以下の通り、Amazon Provided DNSはedns-client-subnetをサポートしていません。
# "edns0-client-subnet" が含まれる結果がない $ dig +nocl TXT o-o.myaddr.l.google.com +short @169.254.169.253 "44.192.161.132"
そのため、IPベースルーティングの判定で使用されたIPアドレスはクライアントのIPアドレスである34.230.33.206ではなく、Amazon Provided DNSのIPアドレスである44.192.161.132になります。
次に、名前解決する際にtop-engineer.corp.non-97.netを管理しているコンテンツDNSサーバーの一つである@ns-737.awsdns-28.netを指定してあげます。
$ dig top-engineer.corp.non-97.net @ns-737.awsdns-28.net. ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> top-engineer.corp.non-97.net @ns-737.awsdns-28.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28636 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;top-engineer.corp.non-97.net. IN A ;; ANSWER SECTION: top-engineer.corp.non-97.net. 60 IN A 10.1.1.1 ;; AUTHORITY SECTION: corp.non-97.net. 172800 IN NS ns-119.awsdns-14.com. corp.non-97.net. 172800 IN NS ns-1201.awsdns-22.org. corp.non-97.net. 172800 IN NS ns-2012.awsdns-59.co.uk. corp.non-97.net. 172800 IN NS ns-737.awsdns-28.net. ;; Query time: 1 msec ;; SERVER: 205.251.194.225#53(205.251.194.225) ;; WHEN: Fri Jun 03 01:46:14 UTC 2022 ;; MSG SIZE rcvd: 210
IPベースルーティングのレコードの値である10.1.1.1が返ってきました。これはキャッシュDNSサーバーを介さずに、CIDRコレクションに登録されているIPアドレスを持ったクライアントから直接コンテンツDNSサーバーに問い合わせているからです。
手元のPCからdig top-engineer.corp.non-97.net @ns-737.awsdns-28.net.を叩いても名前解決できませんでした。IPベースルーティングがしっかりされていることが分かりますね。
> dig top-engineer.corp.non-97.net @ns-737.awsdns-28.net. 1.8m 金 6/ 3 10:49:57 2022 ; <<>> DiG 9.10.6 <<>> top-engineer.corp.non-97.net @ns-737.awsdns-28.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7340 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;top-engineer.corp.non-97.net. IN A ;; AUTHORITY SECTION: corp.non-97.net. 900 IN SOA ns-737.awsdns-28.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 ;; Query time: 176 msec ;; SERVER: 205.251.194.225#53(205.251.194.225) ;; WHEN: Fri Jun 03 10:49:58 JST 2022 ;; MSG SIZE rcvd: 138
次に、edns-client-subnetをサポートしている8.8.8.8をキャッシュDNSサーバーにして名前解決してみます。
$ dig top-engineer.corp.non-97.net @8.8.8.8 ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> top-engineer.corp.non-97.net @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17418 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;top-engineer.corp.non-97.net. IN A ;; ANSWER SECTION: top-engineer.corp.non-97.net. 60 IN A 10.1.1.1 ;; Query time: 67 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Jun 04 03:43:58 UTC 2022 ;; MSG SIZE rcvd: 73
IPベースルーティングのレコードの値である10.1.1.1が返ってきました。edns-client-subnetによりクライアントのIPアドレス34.230.33.206でルーティングされたようですね。
手元のPCからもdig top-engineer.corp.non-97.net @8.8.8.8を叩いて、確認してみます。
> dig top-engineer.corp.non-97.net @8.8.8.8 ; <<>> DiG 9.10.6 <<>> top-engineer.corp.non-97.net @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58670 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;top-engineer.corp.non-97.net. IN A ;; AUTHORITY SECTION: corp.non-97.net. 900 IN SOA ns-737.awsdns-28.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 ;; Query time: 212 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Jun 04 12:52:48 JST 2022 ;; MSG SIZE rcvd: 138
手元のPCはCIDRコレクションに登録されているCIDRブロック34.192.0.0/10に属しているIPアドレスを持っていないので、ANSWER SECTIONがないですね。
他のルーティングポリシーとの違いを確認して適切なルーティングポリシーを選択しよう
Amazon Route 53のPublic Hosted ZoneでIPベースルーティングができるようになったアップデートを紹介しました。
これでRoute 53のルーティングポリシーは8つになりました。
- シンプルルーティングポリシー
- フェイルオーバールーティングポリシー
- 位置情報ルーティングポリシー
- 地理的近接性ルーティングポリシー
- レイテンシールーティングポリシー
- 複数値回答ルーティングポリシー
- 加重ルーティングポリシー
- IPベースルーティングポリシー
このタイミングで各ルーティングポリシーがどのような動きするのか改めて確認しておきたいですね。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
