この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
まいど、大阪の市田です。
Dome9では、Security GroupのルールをDome9の管理画面上から管理（追加、変更、削除）することができます。
ルールを追加する時は、許可するSourceに「IP CIDR」や 「DNS名」で登録することができるのですが 「DNS名でSecurity Groupのルールを登録できる、とは一体どういうことなんだろう？」と個人的に気になりました。
今回はこの挙動についてご紹介したいと思います。
事前準備
まず、検証するためのDNSレコードを用意します。今回はRoute53で自前で管理しているドメインに対してテスト用のレコード（dome9.xxx.info）を登録してみました。
「dome9.xxx.info」のAレコードを「198.51.100.1」で登録しました。
登録した内容の名前解決になっています。
Dome9からDNS名でSecurity Groupのルールを追加
この状態でDome9にDNS名でSecurity Groupの許可ルールを登録してみました。
「dome9.xxx.info」でSecurity Groupにルールが登録されました。
結果を確認してみます。
少し待ってからAWS側のSecurity Groupの設定を見ると、、、「dome9.xxx.info」に対して 名前解決したIPが登録されていました！！面白いですね。
IPが変わった場合の確認
次に気になったのは、「IPアドレスが変わった場合」はどうなるのか？ということです。
そこで、先程のAレコードのIPを「198.51.100.1」から「198.51.100.100」に変更してみます。
名前解決の結果も変更されたものになっています。
5分ほど待ってから、AWS側のSecurity Groupを確認してみます。
すると、なんとSourceのIPアドレスが新しい内容に変わっていました！！（２度びっくり）
Dome9の履歴を確認
Dome9の画面からDome9側の挙動を確認することもできました。
Historyの詳細を開くと、下記のようにイベントの内容が表示されます。どうやら該当するイベントをCloudTrailから取得しているようです。
（Dome9用のIAM Roleにはcloudtrail:LookupEventsも付与されます）
なお、下記のHistory画面で複数のイベントが見えるのは、テストを何度か繰り返したためです。
CloudTrailで確認
この挙動はCloudTrailからも確認することができます。
下記のスクリーンショットを見ると、対象のSecurity Groupに対して「AuthorizeSecurityGroupIngress」、「RevokeSecurityGroupIngress」 というイベントが発生していることが分かります。
「AuthorizeSecurityGroupIngress」で新しいIPアドレスの許可ルールを追加し、「RevokeSecurityGroupIngress」で変更前の古いルールを削除した、ということですね。
最後に
ユースケースとしては、契約プロバイダの関係等で拠点IPアドレスが固定できない場合などに有効な機能かなと思いました。
AWS Lambdaなどを利用して同様のことはできると思いますが、コードの保守等が煩わしい場合には便利ですね。
以上です。