先日、Internet Week ショーケース in 奈良にて、Team Shirankedo のメンバーとして会場Wi-Fiを提供するNOCチームに参加しました。 主に以下の2点に携わりました。構成についてはNOCメンバーの発表資料に載っています。
大きな障害もなく無事安定稼働することができたました。懇親会では有識者の方から、より良いネットワークを提供するための知見を色々教えていただくことができました。 その中で、JPRSの方から教えていただいた「会場Wi-Fiで提供するDNSサーバーに、public DNSにforwardする設定を入れるのはあまり良くない」という内容について、共有したいと思います。
会場Wi-FiのDNS と public DNS
今回の会場Wi-Fiでは、来場者向けにDNSキャッシュサーバーを提供していました。 そして当初は、来場者が100人程度のため十分にキャッシュが温まらないだろうと考え、googleやcloudflareのpublic DNSにforwardする設定を入れていました。
しかし、この設定が適切ではなかったようです。
普段はとりあえず8.8.8.8に向けておくか、と気軽に使っていましたが、google などの public DNS は利用者が利用規約やプライバシーポリシーに同意した上で使うもの、ということになっています。
会場で提供するDNSサーバーにpublicDNSにforwardする設定を入れてしまうと、そのようなDNSを「googleのDNSを使おう」と思って接続はしているわけではない来場者に利用させることになってしまいます。
そのため、本来はpublic DNSへのforwardの設定は入れず、会場内のDNSサーバーがフルリゾルバとして動作するようにするべきです。
初日夜の懇親会で教えていただいたので、二日目はDNSサーバーからpublic DNS に forward していた設定を削除しました。 そして初日と二日目で、forwardの設定の有無による違いを比べてみました。
実際に使用した感覚として、二日目のWi-Fi構築が完了した直後は、名前解決が少し遅く感じるほどの時間がかかっていましたが、来場者が開場に入り、プログラムが開始する頃にはあまり気にならなくなっていました。 NOCメンバーや来場者のクエリによってキャッシュが温まった結果だろうと思います。 メトリクスを確認したところ時間がかかっているクエリが増えてはいましたが、多少遅くなる程度で気になるほどではなさそうです。 forwardの設定がなくても、ある程度使われればキャッシュが温まり、あまり気にならなくなるということが分かりました。
とはいえキャッシュの性能が名前解決の速度に直結するため、キャッシュの設定は適切にする必要があります。 今回は Knot Resolver 単体で動かしていましたが、dnsdistを用いて複数のキャッシュサーバーを使うような場合は特に注意が必要だと思います。
DNSを提供するということとDNSのキャッシュについて、考え直すきっかけになりました。 教えてくださったJPRSの方には改めて感謝いたします。
NOCに参加して
Internet Week ショーケース in 奈良のNOCチームに参加して、様々なことを学ぶことができました。
前述のようなDNSのように、会場Wi-Fiを題材に様々な知識を教えていただけたことはもちろん、
- 研究で解決しようとしているトラブル（DHCPリレーのようなネットワーク制御のための処理の複雑さに起因する、ACLなどのネットワーク機器における他の処理との不整合）に実際に遭遇したこと
- 構成・チームともに大きすぎないため、他のチームの人とも交流しながらネットワークの全体を見た構築ができたこと
- 研究室の先生が関わっている eduroam と OpenRoaming についての理解が深まったこと
など、多くの貴重な経験をすることができました。 今回のNOC活動では本当に多くの方々のお世話になりました。改めて、本当にありがとうございました！ 今回の経験を活かして、今後もより良いネットワーク提供に向けて頑張ります。
