さくらインターネットで管理しているドメインの NS レコードについて

わざわざ書くほどでもないかもしれませんが、一応自分用の備忘録として書いておきます。

先日、 Google Search Console から連絡があり、ドメインプロパティを設定したほうがよいよ、とありました。ドメインプロパティを設定することで、すべてのサブドメインのアクセス等を解析できるようになるとのことです。

その時に、ふと、思ったのが、サブドメインの一覧って取得することができるのだろうか？という疑問です。

調べてみた結論としては、サブドメインの一覧を得るにはゾーン転送を利用する必要があり、DNSサーバーがゾーン転送で使う axfr でのアクセスをセキュリティ上の理由で認めていないことが多いので、サブドメインの一覧も取得できないことが多い、というものでした。

それ自体はそれで納得なのですが、その際に、さくらインターネットでドメイン管理している mori-soft.com の DNS レコードを調べていたら、NS レコードは

mor@DESKTOP-JBLAC6U:~$ dig mori-soft.com ns

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> mori-soft.com ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9487
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mori-soft.com.                 IN      NS

;; ANSWER SECTION:
mori-soft.com.          3499    IN      NS      ns1.dns.ne.jp.
mori-soft.com.          3499    IN      NS      ns2.dns.ne.jp.

;; Query time: 12 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Thu Jan 28 16:59:19 JST 2021
;; MSG SIZE  rcvd: 87

mor@DESKTOP-JBLAC6U:~$

とあるのですが、 SOA レコードは

mor@DESKTOP-JBLAC6U:~$ dig mori-soft.com soa

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> mori-soft.com soa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12118
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mori-soft.com.                 IN      SOA

;; ANSWER SECTION:
mori-soft.com.          2557    IN      SOA     master.dns.ne.jp. tech.sakura.ad.jp. 2021012800 3600 900 3600000 3600

;; Query time: 12 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Thu Jan 28 17:15:44 JST 2021
;; MSG SIZE  rcvd: 109

mor@DESKTOP-JBLAC6U:~$

となっています。 SOA レコードの先頭にあるサーバー名は、プライマリ DNS サーバーだと思っていたのですが、これを見ると、どちらの NS レコードとも異なっています。

これはどういうことなんだろうか？というのが今回の疑問点でした。

推測した結論

ちょっと気になったので、ネットを調べてみると、似たような hidden master という DNS サーバーの構成の仕方が、 IIJ のブログにモダンな DNS の構成として紹介されていました。

モダンなDNSの構成：IIJ DNSプラットフォームサービスのスゴいところ(第1回) | IIJ Engineers Blog

なるほど。ゾーン情報を管理するサーバーと、問い合わせを受け付けるサーバーを分けて、 NS レコードには問い合わせを受けるサーバーだけを載せる、ということなんですね。

さくらインターネットのがこれとそっくりそのまま同じとは思いませんが、やってることは似ているような気がします。

普段、DNSの構成なんて気にしていませんが、こうやって日々進化してるんですね。

おまけ

最初の話題に戻ります。サブドメイン一覧を得ることができないはずなのですが、蛇の道は蛇（じゃのみちはへび）というか、世の中にはいろいろと抜け道があるようです。

こちらのブログで紹介されている DNSdumpster.com というサイトを使うと、サブドメインの一覧を見ることができるそうです。

自分のサイトで試してみると、確かに Ａ レコードなどの一覧をみることができました。いやー、恐ろしいですね。

冬の湯沸かしとUPSについて

朝、仕事場でコーヒーを淹れるのですが、お湯を沸かすのにティファールの電気ケトルのスイッチを入れると、時々 UPS が反応してバッテリー駆動になることがあります。

で、この UPS には QNAP の NAS をつないでいるんですが、いままでは、 UPS のエラーが飛んできても、NAS がシャットダウンすることはありませんでした。

ですが、 ここ数日 NAS のシャットダウンまで進んでしまいます。

これが、結構、頻繁に起きるようになってきて、このままではコーヒーを飲むのに躊躇してしまうので対応策を考えてみました。

原因調査

現象を整理しておきます。

UPS の仕様

この仕事場には、２種類の UPS があります。

• APC ES-550M1 （いまはシュナイダーエレクトリックですね）
• OMRON BW55T

amazon のリンクも貼っておきます。

シュナイダーエレクトリック BE550M1-JP APC ES 550 9 Outlet 550VA 1 USB 100V

オムロン 無停電電源装置(常時商用給電/正弦波出力) 550VA/340W BW55T

今回問題になっている、コーヒー淹れるときにバッテリー駆動になり、NASがシャットダウンする UPS は APC のものになります。ちなみに、 OMRON の UPS はバッテリー駆動に移行しません。

何が違うのだろうか？と思い仕様書を調べてみると、

UPS	入力電圧（下限）	備考
APC	90V	初期設定値、変更可能
OMRON	86±3V

となっており、初期設定のままだと APC のほうが、バッテリーに切り替わる電圧が高い（電圧低下に対して厳しい）ようです。

（参考）仕様書は下記で確認できます。

• https://schneider-electric.app.box.com/s/t8fe620ns0l7ulxjefa1qgf28roqlcz8
• https://socialsolution.omron.com/jp/ja/products_service/ups/support/download/ups/bw_t/bw40t_120t_shiyo.pdf

お湯を沸かしたときの電圧

OMRON の UPS には液晶ディスプレイがあり、そこにいろいろな情報を表示できるのですが、普段は UPS からの出力電圧を表示しています。

これは、このブログを書いている当日のものですが、98V ですね。

先日、NAS が落ちた際にこの電圧を見ていたら、

• ティファールのスイッチを入れる前：94V
• 入れた後：84V

となっていました。ずいぶんと下がってますね。

表示値は出力電圧なので、どこまで入力電圧と連動しているかはわかりませんが、これだけ下がっていると入力電圧も下がっていて、そのため、APC の UPS がバッテリー動作に移行しているんじゃないかと思われます。

NAS の設定

次に、シャットダウンしてしまう NAS の設定も確認します。

QNAP の NAS (TS-251+) の UPS 接続時の動作はマニュアルを見たほうが良いのですが、ざっくりいうと

• UPS のバッテリー残量が１５％以上あるときは
• 指定した待機時間待って
• シャットダウンする（または自動保護モードに移行する）

というものです。

設定値は、

• 停電時にNASの電源を切る
• 待機時間は５分（デフォルト値）

となっていました。

普段から UPS には通電しているので、バッテリー残量が１５％を切っているというのはほぼないと思います。

一応、トラブル後、 UPS のバッテリー状態をみていますが、極端にバッテリーが弱っていて、バッテリー動作に切り替え後急激に残容量が減るというのもなさそうです。

お湯の沸くまでの時間

お湯が沸くまでの時間も計ってみます。満水（０．８リットル超）で約４分ってところでした。

ちなみに、ティファールの電気ケトルはこんな感じのやつです。

ティファール 電気ケトル アプレシア プラス シュガーピンク 0.8L BF8057JP

このリンク先の amazon のページにある宣伝文で、満水で約４分（水温・室温２３度）とあるので、まあ、こんなもんなんでしょう。秒数まで計ってなかったですが、冬場なので水温は２３度より低いでしょうから、５分未満ぐらいが実際かもしれません。

ということで、現在の NAS の待機時間設定は５分なので、シャットダウンすることは十分あり得ますね。

シャットダウンまでの流れ

いろいろ確認すると、こんな風になっているんじゃないかと推測できます。

1. お湯を沸かす際に電源電圧が低下して
2. それによりUPSがバッテリー動作になり
3. 待機時間程度バッテリー動作が続くため
4. NASがシャットダウンすることになる

という感じですね。

先日までこれが見られなかったのは、朝の水の温度（および外気温）が低くなかったため、お湯が沸くまでの時間が短くてすんでいた、ということじゃないかと思います。

対策

NAS がシャットダウンする原因がある程度推測できたので、お湯を沸かした際に NAS がシャットダウンしないようにする対策を検討してみます。

対策案１

APC の UPS のユーザーズマニュアルをよく読むと、この UPS は外部電源からバッテリーに切り替える際の入力電圧感度を変更できるようです。

ということで、設定を変更して、電圧感度の若干鈍感なほうに振ってみます。

1. まずは、 UPS に接続されている機器の電源を切っておきます。
2. 次に UPS をコンセントに接続したまま、 UPS の電源を切ります。
3. 次に電源ボタンを１０秒間押します。
4. ブザー音がなったら、電源ボタンから手を放すと、電源ボタンが点滅しています。たぶん、これがマニュアルでいうところのプログラミングモードに入った状態のはずです。
5. ここで、さらに電源ボタンを押すと、赤の点滅（デフォルトはこれ）→オレンジの点滅→緑の点滅→赤の点滅・・・と切り替わっていきます。
6. 今回は一番感度を低くしたいので、緑の点滅になったところで、操作をやめます。
7. しばらくすると、電源が切れて、プログラミングモードが終了します。
8. あとは、通常通り電源を入れればOKです。

と文章で書くと簡単なのですが、実際やってみるとプログラミングモードになったかどうかがよくわからず、また電源ボタンを押しても感度が切り替わらずに、何度も繰り返すことになりました。

なんとなくですが、ブザーがなったら即座に電源ボタンを押すと、切替ができるような印象です（でも、確証はないです）。

もう少しわかりやすくならないもんでしょうかね？ > APC さん

対策案２

仮に電圧低下があったとしても、待機時間が十分に長ければシャットダウンは回避できます。 NAS 上のモニターで UPS のバッテリー動作時間を見るとおおよそ１０分超になっています。

ということで、待機時間をデフォルトの５分より長くしておくのもありかと思います。

対策案３

対策案２とも関連するのですが、要はお湯が沸くまでの時間が短くなればいいわけです。先日まで起きていなかったですからね。

ということで、水道が仕事場から少し離れていることもあり、いままではティファール目いっぱい（０．８リットル超）にお湯を沸かしていたのですが、これをやめます。で、水差しを用意して、飲みたいときに、飲む分だけ沸かすことにしました。

マグカップ一杯分の水量は正確にはわかりませんが、ティファールのメモリから推測して０．２～０．３リットルぐらいかと思われます。

この水量だと、スイッチを入れてから沸くまでの時間を計ると、おおよそ２分３０秒前後です。

ということで、仮に UPS 動作になっても NAS がシャットダウンする前にバッテリー動作から復旧できそうです。

採用した対策案

今回は対策案１と対策案３を行うこととしました。NASのシャットダウン回避ということだけであれば、対策案２もあるかと思います。

ですが、

• 元々 UPS のバッテリーでの駆動時間がそんなに長いわけではないこと
• １台の UPS に２台の NAS が接続されていること（モニターに表示されているバッテリーの駆動時間の半分が実際に設定可能な時間になります）

などから、対策案２を用いた場合に、今回のティファール問題以外の時にきちんとシャットダウンできなくなる恐れがでてきます。そちらのほうが問題になりそうなので今回は採用しませんでした。

おわりに

これで、仕事前のコーヒーを快適に淹れることができるようになりそうです。うまくできているかは、寒い日がやってこないとわからないのが難点ですね。

もし、問題がありそうなら、また考えたいと思います。

ということで、お湯を沸かすと UPS が作動する方は、ご参考にしてください。

SpatialChat 使ってみました

少し前になりますが、２０２１年１月９日（土）に、第２２回伊勢IT交流会をオンラインで開催しました。

第２２回伊勢IT交流会（オンライン） - connpass

昨年はコロナの影響もあり一度も開催できませんでしたので、今回はオフラインでの開催をあきらめて、初めての試みとしてオンラインでの開催としました。

今回のオフラインイベントでは、 SpatialChat というものを使ったので、それについて思ったことを徒然なるままに書き留めておこうと思います。

SptialChat について

ご存じの方も多いと思いますが、伊勢IT交流会の少し前に知り合いから SpatialChat の存在を教えていただきました。

zoom とかの Web 会議システムと違うのは、ミーティングに参加すると、ある広さの仮想空間に自分が丸で囲われたアイコンで表示されて、その空間内を自由に動けるというスタイルである点です。で、その際に相手との距離に応じて、聞こえる声の大きさが変わるというものです。

離れすぎると声が聞こえなくなります！

まあ、文章で書いてもわかりにくいのですが、実際の画面を見ると一目瞭然と思います。こんな感じです。

こういう形なら、現実の交流会と同じようにグループごとに集まって雑談とかもできるのではないかと思い、今回使ってみました。

使い方

参加者がミーティング用のスペース（ルームとも呼ばれます）に参加するには、参加用のURLをクリックして、表示名を設定するだけなので、非常に簡単です。

一度、SpatialChat を試したいというのであれば、こちらの URL から参加することができます。この URL から入るルームは誰でも入れる公開ルームになります。

ルームを自分で開けば、参加者を限定して会議を行うことができます。ルームを開くにはメールアドレスを入力してルーム名を決定する必要があります。

ルームへ参加した参加後は、画像、動画、デスクトップの共有もできます（また、ルームの主催者はこれらの許可をコントロールできます）。

LTで使う資料を共有するような場合は、自分のPCのデスクトップに全画面表示して、それを共有する形になります。zoom とかと同じですね。

面白いのは、デスクトップの共有を複数人が同時に行うことができるので、ルームの両端で同時に２つの LT をするような使い方も不可能ではありません。

トラブル

新しいサービスなので、トラブルもありました。

LT をしている最中に、デスクトップ共有が半透明の黒い画面になってしまい、表示をみることができませんでした。参加した何名かの方で起きていたようです。

サービスが推奨しているブラウザ としては、 Chrome ですが Chrome でも問題が起きていました。自分の手元での環境だと Firefox で表示したほうがこの現象が軽減されている印象でした（Firefox でも起きてましたけどね）。

このあたりは今後の改善を期待したいところです。

一方、音声の品質は全然気になりませんでした。

まったくの自分の主観ですが、ある程度の人数が参加している場合、 zoom や Skype での音声のほうが、品質があまりよくない方がいたように見受けられるような気がします。まあ、たまたまかもしれませんけどね。

他のツールと比べて音質がどうなのかを客観的に比較できるものがあるといいんですが、どうなんでしょうかね？

所感

さて、上記で少し触れたように、今回 SpatialChat を選んだ理由である、オフラインでの交流会のようにグループごとに雑談をしてもらいたいというのは、実現できていたでしょうか？

残念ながら今回はあまりできていなかったかな？という印象です。

いくつか、気になった点を挙げると、

• 人数が多くなってきても、グループごとに分かれていかず、全体で一つのグループになってしまっているようだった
• ひとりぽつんといる方がちらほらと見受けられた
• もともと LT の件数が、それほど多くないことを想定していたのですが、予想外に LT 件数が増えて、そのため雑談の時間があまりとれなかった
• LT ベースだと、話すほうも、進行も、質問する人も、全体に向けて話す形になる

というあたりです。

２つめの点に関して、初めての人が孤立しがちになるのはオフラインでも同じで、本来であれば主催者である私がフォローするべき点です。 ですが、参加者が問題なく参加できているかなどが気になってしまい、そこまで手が回っておりませんでした。反省点です。

また、後者の２点のような傾向があるなら、 zoom のような１対多で使うことが想定されるサービスのほうが、何かとスムーズに進行できるのかもしれません。

そういう意味では、このサービスは、純粋な交流会（雑談？）とか、グループディスカッション（グループワーク）のようなで使うのが向いているのかもしれませんね。

このあたりはなかなか使い分けが難しい印象です。

ご参考

なお、後日、 SpatialChat のヘルプを検索したら、共有画面が黒くなる事例についてのヘルプが載ってました。

What if my screensharing is flicking or black? – SpatialChat Help Center

ブラウザのハードウェアアクセラレーション設定を変更するというもののようです。私のほうでは試せてないのでなんとも言えませんが、もし使う方がいらっしゃれば、ご参考にしてください。解決するといいのですが。

まとめ

いろいろ書きましたが、個人的には非常に面白いサービスだと思っています。 問題点は改善して、ぜひいいサービスになるといいなと思います。

また、伊勢IT交流会もオフラインで開催する機会がまだまだあると思いますので、今後もいろいろと試したいと思います。