IDCFクラウドDNS障害の影響と対策

isdはじめに

IDCFクラウドで、2020年2月下旬から何度か、DNS障害が発生しました。
DNSサーバーが外部からDDoS攻撃を受けていることが原因だそうで、影響としては、
「コンピュート(仮想マシン)など複数のサービスにおいて、名前解決が失敗する事象が発生している」
とのこと。

権威DNS(ゾーン管理)ではなく、キャッシュDNS(リゾルバー)のほうに影響が出ているということなんですね。

この障害による、IDCFクラウド上で稼働するサーバーへの影響と、ユーザー側で可能な対策について考えてみます。

isdDNS障害の影響

IDCFクラウド上で稼働するサーバーにおいて、
「名前解決が失敗する=ホスト名からIPアドレスへの変換ができない」
ことで、具体的にはどんな不具合が起きるのでしょうか?

サーバーから外部への外向きアクセスで、ホスト名(FQDN)を指定している場合は、すべてエラーとなります。

より具体的には、サーバーからのメール送信や、外部サービスとの連携が失敗します。
「Webサイト公開は外部からサーバーへの内向きアクセスだから問題ないはず!」
と思ってしまいますが、例えば、Google reCAPTHAは、サーバーからGoogle APIへの通信がありますから、エラーとなります。
案外、影響があるWebサービスも多いのではないでしょうか。

※外部へのアクセスの際に、ホスト名ではなく、IPアドレスを指定していれば、問題ありません。

isd対策

ユーザー側で対応可能な対策としては、サーバーのDNSリゾルバー設定に、IDCFクラウド以外のDNSサーバーを登録すること、が有効でしょう。

CentOSであれば、サーバーのDNSリゾルバー設定は /etc/resolv.conf です。
IDCFクラウドが提供するテンプレートOSを使用していれば、デフォルトでは、プライベートN/W内の仮想ルーターと、その上位の、IDCFクラウドのDNSサーバー2つの計3つが登録されています。

  # cat /etc/resolv.conf
# Generated by NetworkManager
search xxxxidcfcloud.internal
nameserver 10.31.0.1         // プライベートN/W内の仮想ルーター
nameserver 158.205.237.131   // IDCFクラウドのDNS
nameserver 158.205.229.244   // IDCFクラウドのDNS

 

※仮想ルーターのIPアドレスは、ゾーンによって異なります。

IDCFクラウド以外のDNSサーバーとしては、公開されているDNSサーバーであれば何でもよいのですが、Google Public DNSの 8.8.8.8 と 8.8.4.4 が有名ですので、これを使ってみます。

単純に /etc/resolv.confの末尾にこの2つを追加すればよいかと思いきや、
「resolv.confのnameserverエントリー最大値は3」
という仕様ですので、現状の3つのあとに、Google Public DNSの2つを追加しても、無視されてしまいます。

このため、サーバーからネットワーク的に近い順にひとつずつ、

プライベートN/W内の仮想ルーター
IDCFクラウドのDNSの1つ
Google Public DNSの1つ

の順に登録することにしました。

  # vim /etc/resolv.conf
# Generated by NetworkManager
search xxxxidcfcloud.internal
nameserver 10.31.0.1         // プライベートN/W内の仮想ルーター
nameserver 158.205.237.131   // IDCFクラウドのDNS
#nameserver 158.205.229.244  // IDCFクラウドのDNS
nameserver 8.8.8.8           // Google Public DNS

 

※IDCFクラウドのDNS 158.205.229.244 のエントリーは、障害が完全に解消されれば元に戻すため、コメントアウトで残しておきます。

名前解決を行うクライアントは、resolv.confに登録されたnameserverを上から順に参照しますので、この設定で、通常時はプライベートN/W内の仮想ルーターを使用し、IDCFクラウドのDNSに異常が発生したときのみ、Google Public DNSを使用することになります。

タイムアウトによる遅延が気になる場合は、

options timeout:

で、調整するとよいでしょう。
単位は秒、デフォルトは5です。

(2020.11.26追記)
CentOS では、/etc/resolv.conf の修正だけでは不十分でした。
このままでは、NetworkManagerやOSが再起動されたときは、/etc/resolv.conf が上書きされて、修正前の設定に戻されてしまいます。

(/etc/resolv.conf の先頭行が
 # Generated by NetworkManager
 と記述されている場合。)

対策としては、NetworkManager が /etc/resolv.conf を書き換えないようにします。

(参考)
・resolv.confが上書きされる事象について(CentOSの場合) – Voyage sentimental
https://metalman.hatenablog.com/entry/linux/resolv-conf

 # vim /etc/NetworkManager/NetworkManager.conf

--
[main]
...
dns=none
--

 

NetworkManager を再起動して、/etc/resolv.conf が勝手に書き換えられず、こちらで設定した Google Public DNS のエントリーが存在することを確認します。

 # systemctl restart NetworkManager
 # systemctl status NetworkManager

 # cat /etc/resolv.conf

--
# Generated by NetworkManager
search xxxxidcfcloud.internal
nameserver 10.31.0.1
nameserver 158.205.237.131
#nameserver 158.205.229.244
nameserver 8.8.8.8
--

 

なお、参考記事によると、/etc/resolv.conf の先頭行が
; generated by /sbin/dhclient-script
と記述されている場合は、ifcfg-* に 「PEERDNS=no」を追記するとよいそうです。
(2020.11.26追記ここまで)

isdまとめ

IDCFクラウドで発生しているDNS障害について、IDCFクラウド上で稼働するサーバーへの影響と対策を考えてみました。
IDCFクラウドでは、この障害への対策として緊急メンテナンスを実施したので、これで解決してくれるとよいですね。
当面は、上記のような設定で様子を見たいと思います。

(参考記事)
・Linuxのresolv.confのベストプラクティスを探す – Qiita
https://qiita.com/YamaguchiRei/items/d05aa23c57993803aa23

・/etc/resolv.confとタイムアウト秒 – Qiita
https://qiita.com/todanano/items/323fa282c552de76923b

・Man page of RESOLV.CONF – JM Project
http://linuxjm.osdn.jp/html/LDP_man-pages/man5/resolv.conf.5.html
 

Follow me!