Azure DNSにDNSを変更して、レコードをPowerShellで移行してみよう


こんにちは！Amiです！今回は久しぶりに M1 MacBook Proからの投稿です。 今日はmacOS へ PowerShell を インストールして Azure DNSにDNSを変更して、Microsoft365関連のレコードを移行するメモを残していきます。 

今回の作業自体はブラウザで完結しますが、それでは面白くないのでPowerShellを使ったコードでレコードの委任をやっていこうと思います。（てんこ盛り）

一般的にPowerShellなどのスクリプトを使うタスクは高い頻度で、反復的に行う作業に適していますので、実施回数が運用上多くない場合は無理にスクリプト化せずに手作業でやったほうが安くつく（人件費）ケースがほとんどです。

下準備：MacにPowershellのインストール
 （諸事情で未実施）

この手順では公式ドキュメントをなぞってサックッと終わらせます。

多くの場合問題にはなりませんが、MSが推奨している導入方法がHomebrewを使用した方法なので、企業さんなどでPowershellを入れる際には考慮が必要かもです。Powershell導入後もいくつか手順があるのでドキュメントをしっかり読んで忘れずに進めましょう。。。

※別件の検証作業でMacが文鎮になってしまったので、中途半端ですがWindowsのPowerShellでやります。ごめんなさい！


macOS向け Powershell のインストール


  
1
sudo installer -pkg powershell-7.1.3-osx-x64.pkg -target /
 

  
sudo installer -pkg powershell-7.1.3-osx-x64.pkg -target /

残りの手順については下記のドキュメントを参照して実施してください！

下準備：Azure PowerShellのインストール
 （Windowsはここから）

PowerShellからAzureにアクセスする手段としてAzure PowerShell モジュールが提供されています。 ここでは公式ドキュメントをなぞってサックッと終わらせます。

AZモジュールとAzureRMモジュールの2種類ありますが、AzureRMモジュールは2024年にサポート切れになるので、要件がなければAZモジュールの使用がおすすめです。

本記事ではAZモジュールを使って作業を進めます。ちなみにMSI形式でインストールしたほうが環境差異による失敗が少ないと考えられるため、不安な方はMSI形式でのインストールも試してみてください！


下準備：DNS変更（名前解決要求の向き先を変える）って？



DNSはどのサーバが何処(IPアドレスの世界で何処にあるか)にあるかを階層構造で管理する仕組みです。 画像内の紫字の箇所に注目してほしいのですが、  XXX .comはお名前.com DNSが知ってるよと回答していますので XXX.comの知っているひとは Azure DNSだよとみんなに(他のDNS)に知らせて、次の問い合わせからお名前.comではなくAzure DNSに解決の要求を飛ぶようにすることを言います。これがやっていきます。

※あくまでもイメージなので厳密な仕様とは異なります。 この作業を分かった気になる分には十分なはず。。。


名前解決要求をお名前ドットコムDNSからAzureDNSに向けるには


今回の目的は名前解決要求をお名前ドットコムDNSからAzureDNSに向けることです。
名前解決はざっくりルートDNSサーバーからCOM→exampleと順をたどって解決していきます。 今回はトップレベルドメイン（.com）から、exampleというドメインを解決しようとした際に、参照されるDNSサーバを変更する作業を行おうと思います。
（どこが変わるのかのイメージ像は画像に記載された通りです。）
この作業を行うための主な作業内容と順番は次のようになります。 
  1. 下準備：AzureDNSでレコードを作成 
  2. 移行作業：DNSの変更先情報をお名前ドットコムに登録 
  3. 移行中待機：TTLの時間をもとに数時間の平行運用 
  4. テスト：DNSレコードを確認
  5. 平衡運用終了：お名前ドットコムの不要なレコードを削除して終了。 
要点としては１の移行先のサーバにあらかじめレコードを登録して受け入れの準備を先にすること、 DNSの設定変更は情報が他のサーバに伝わり切るまで時間がかかるので、一発切替が難しく、並行運用が必要になることです。 切り戻しに備えて、移行が完了するまで、移行元のDNSはと登録されたレコードは生かしておくのがベストだと思います。

※TTLは どれくらいの時間にするかは、諸説ありますが、作業時間や要件に合わせて適宜決めていいと思います。短くする必要がある場合は大体の場合その日に疎通確認したいや今すぐきり変えたい要件があると思うので、要件に合わせて別途調整してください。 今回登録されてるレコードは全てTTLが3600となっており個人的には許容範囲内なので触っていません。また、ほかの環境でDNSキャッシュ情報を保持しているケースも考慮できるので。
実際は数時間ではなく数日かけて移行を行うケースなどもあります。　

1. 下準備: AzureDNSでレコードを作成

まずはお名前.com DNSに登録されてるレコードをローカルにコピーします。
DNSレコード設定(onamae.com)からアクセスすると便利です。
画面中ほどにエクスポートボタンがあり登録されているレコードをテキストでエクスポートできるので便利です。

また、右のようなコマンドでも引っ張ってこれます。
 
1
nslookup -type=ANY -debug -timeout=5 [お使いのドメイン名] 8.8.8.8
 
 
nslookup -type=ANY -debug -timeout=5 [お使いのドメイン名] 8.8.8.8




まずはPowershellを起動して、Connect-AzAccount コマンドでAzureに接続します。
ログインプロンプトが出てくるので、必要に応じてログインしてください。

①. リソースグループの作成

　AzureDNSでゾーンを作成する前にリソースグループを作成します。
　「New-AzResourceGroup -name 「リソースグループ名」 -location "japaneast"」


②．DNSゾーンの作成

先ほど作成したリソースグループに移行したいドメインのゾーンを作成します。
「New-AzDnsZone -Name [お使いのドメイン名] -ResourceGroupName 「リソースグループ名」」


ちなみに以下のレコードはゾーン作成時に自動生成されるため、明示的に作成する必要はありません。

③. DNS レコードの作成

レコードを作成します。先の手順でエクスポートしたレコードのパラメータを使うと便利です。私の環境ではMicrosoft365関連のレコードを登録するため、
CNAME、TXT、MXなどの複数種類のレコードを登録する必要があります。
リファレンスを読んでコマンドのパラメータを確認します。

 
1
2
3
4
5
6
7
$Zone_name = "Your_Zone_Name"
$RG_name = "Your_ResourceGroupName"
 
$Records = @()
$Records += New-AzDnsRecordConfig -Cname autodiscover.outlook.com.
$RecordSet = New-AzDnsRecordSet -Name "autodiscover" -RecordType CNAME -ResourceGroupName $RG_name -TTL 3600 -ZoneName $Zone_name -DnsRecords $Records
...
 
 
$Zone_name = "Your_Zone_Name"
$RG_name = "Your_ResourceGroupName"

$Records = @()
$Records += New-AzDnsRecordConfig -Cname autodiscover.outlook.com.
$RecordSet = New-AzDnsRecordSet -Name "autodiscover" -RecordType CNAME -ResourceGroupName $RG_name -TTL 3600 -ZoneName $Zone_name -DnsRecords $Records
...

④. 作成したDNSレコードの確認

一通りNew-AzDnsRecordSetなどのコマンドで、レコードの作成ができたら、Get-AzDnsRecordSetを実行して、作成したレコードを確認します。

「コマンド」

2.移行作業：DNSの変更先情報をお名前ドットコムに登録 

お名前.comに DNSサーバを登録します。登録するDNSサーバはDNSゾーンを作成した際に
表示された[Name Servers]のパラメータを登録していきます。
こんな具合です↓
環境ごとに指定するDNSサーバが異なるので実際に作業する際はご自身の[Name Servers]
のパラメータを確認の上作業してくださいね。
登録が終わったら、あとはDNSの設定変更がほかのキャッシュサーバ等に浸透するのを待つだけです。 登録した後に7時間ほど寝てしまっていたので切り替わる瞬間まで、向き先の確認を行ってはいません。果報は寝て待ちましょう。 

余談ですが、深夜帯の作業は、なるべく早く終わらせたい（作業スケジュールに余裕を持たせたい）ので、事前に可能であればレコードに設定されたTTLや有効期限を短くし、レコード更新の頻度を上げるなどの工夫も可能かと思われます。 ただし、TTLを短くするとそれだけ名前解決要求が増えてしまう恐れもあるため、移行環境のキャパシティやSAASを使っているならSAASの仕様も忘れずに考慮に含める必要があります。 

3.移行作業：平行運用とテスト

平行運用中に nslookup -type=ANY -timeout=5 「お使いのドメイン」 8.8.8.8　でレコードの状態を確認するとそのうち「 [お使いのドメイン名] nameserver = ns1-06.azure-dns.com. 」等の結果が得られるはずです。  

ここで必ず押さえるべきは、回答があった NS （Name Server） レコードのパラメータい移行先DNSのパラメータが記載されていることを確認します。 
今回はしっかり新しいDNSに切り替わっているのでOKです。

※ちなみに今まで気づかなかったんですが、digやnslookupを使ってもSRVレコードって表示されないんですね。不勉強でした。。。 

 

4.移行後作業：平行運用の終了を見極める。

さてやっとゴールです。 DNSキャッシュサーバに記載がある有効期間が 過ぎたころかつ、ユーザーからの不具合報告がないことが最低限の終了条件だと思います。 
これも環境によりけり、ほかのプロジェクト等が平行して進行している場合、ほかプロジェクトに影響が出る場合があるため、横展開というか運用上問題ないかを移行を計画するときに確認しましょう。今回の場合はユーザーは基本的には一人なので、バッサリとお名前.com上に記録されたレコードを削除してこの移行作業は終了です。 

まとめ。

AzureDNSへの移行は、AzurePortalやPowerShellを使うことで簡単にできることがわかりました。お金の面でもセルフサービスのオンプレサーバよりも安く運用できそうです。
DNSは名前解決というシステムの基盤となる機能の一つであることには変わりがないので、運用環境に手を加える際には 綿密な計画を立てて事故を起こさないように検証や運用環境の理解を深めましょう。 大事なのは関係者をしっかり洗い出して、合意形成を行いながら作業をすることです。 

今回はPowershellで移行を行いましたが、移行対象のレコードの数が少ない場合や単発のタスクの場合はAzure Portalで作業したほうが絶対にいいです。 運用に入って、反復的にレコードを追加する場合はぜひPowershell などで作業を自動化しましょう。

後半はマジ駆け足でしたが、以上となります。







コメント

コメントを投稿