あきネット

フリーソフトウェアやオープンソースをはじめ、コンピューターやインターネットに関するTIPSや話題を扱います

北のまちから南のまちへと素敵な何かを届けます。
それは、六花かもしれないし、ナナカマドの実かもしれないし、雪の下キャベツかもしれません。

もうひとつのインターネットドメインの世界

冬支度やらなにやらかやら、というより抑鬱なのであまり書けず更新が滞っていますが。


ルートサーバは13個

世界のインターネットドメインを引けるようにしているおおもとのDNSサーバ(ルートサーバ)は、13個しかありませんでした。
そして現在も、IPアドレスで数えると13個しかありません。厳密に言えば、IPv4アドレス13個、IPv6アドレス13個です。


13個しかないのは、規格上の制約です。


そして、その多くが北アメリカに立地しているという既得権益に基づく差別があり、
そのため、カントリーリスク、災害リスクもはらんでいました。


また、ルートサーバのうち2件は米軍です。



それが現在は、IPアドレスが13個しかありませんが、実際の台数は多くなっています。
これは、IP anycast技術を用いて、同じIPアドレスでも実際には複数のマシンに振り分けられるようになったからです。


ちなみに、この IP anycast 技術があるから、 Google Public DNS (8.8.8.8) や Cloudflare (1.1.1.1)が、全世界のどこからでも、最寄りのDNSサーバ(cache / recursive server)に繋がるのだということもいえます。
また、IP anycast によって、ルートサーバを運用する組織が13団体以外に開放されたから、8.8.8.8 や 1.1.1.1 が(引くのが)速く、(更新の反映が)早くなったのだろうということも推察されます。つまりは、Google や Cloudflare などは、ルートサーバの運用におそらく関与しているのだろうということです。


以前は13台しかなかったので、攻撃を受けて全台停止したらインターネットが事実上使えなくなる危険がありました。
それが IP anycast 技術によって、実際のマシンが多数運用されているため、攻撃を受けても全台停止は避けられるだろうという、力技で運用されているのだといえます。


ルートサーバの制度運営は1団体独占


IP anycast でルートサーバが沢山になり全世界に分散はされました。
しかし、ルートサーバの運営の胴元は ICANN 1団体です。
つまりは、国家や企業の利益誘導などの独裁支配の問題、管理社会化、監視社会化の懸念はあります。


もうひとつのルートサーバ運営者


そこで、ICANN とは別に、
ルートサーバを自主的に運営する Open Root Server Network (ORSN) という団体があります。
ほとんどの人は知らないでしょうし、インターネットのマジョリティからは無視されているといえるでしょうが。


IP anycast 化以前は、ルートサーバが全台停止するという危険を回避するために ORSN はルートサーバを運営していました。(2002年-2008年)


そして、アメリカ NSA の無差別盗聴(監視)の発覚を期に、 2013 年にまた再開されました。


ORSN のルートサーバは、ICANN のルートサーバと互換性のあるもので、決して「裏社会」だというわけではありません。
実際に引けるドメインやIPアドレスなどは同じです。


ただ、 DNSSEC 非対応です。
これはわざとで、 DNSSEC に対応させることでかえって攻撃を受けやすく被害が拡大しやすくなるリスクがあるからのようです。
またそれはつまり、 ORSN のルートサーバは非力だ(実台数も少ない)ということの結果でもあるでしょうね。


ORSN を利用する方法


一般ユーザが ORSN を利用するには、 ORSN のパブリックDNSサーバを使えばよいです。


ただ、すべてヨーロッパです。


DNSサーバの管理者ならば、 ICANN の named.cache を用いずに、 ORSN の root.hint を用いればよいでしょう。
https://www.orsn.org/en/tech/
1台がインドで、あとの12台はヨーロッパです。それに、いくつかは止まっているようですが……😓


もうひとつのインターネットドメインの世界


ここまでは、ドメインを引く DNS の話でしたが、
そもそものドメイン名も ICANN が胴元で管理しています。


その管理自体にも楯突く OpenNIC という団体があります。


OpenNICは、独自の gTLD を管理しています。


ICANN の gTLD ではないので、ICANN 運営のルートサーバでは引けませんよね。


ですので、 OpenNIC の gTLD を使いたければ、所定の DNS サーバを利用しなければなりません。
要は、OpenNIC には パブリックDNSサーバがいくつもあるのですが、それは ICANN のドメイン空間と互換性をもちながら、OpenNIC のドメインも引けるようになっています。そのため、 OpenNIC が、Google や Cloudflare や Quad9 などと並べて パブリックDNSのひとつとして紹介されることもありますが。


また、OpenNIC は、いくつかの暗号通貨が運用しているgTLDや、非承認国家の ccTLD も運用しています。


OpenNIC のgTLDは、世間マジョリティには一切見向きされておらず、
実際に運用しても、予め知らせなければ他人からアクセスされることはほぼないといえますが、
それがむしろ、知った人間だけで使えるという利点になる状況もあるのでしょう。


ドメインは無料でとれますが、一般の不特定多数には見向きされません。
自分で使うにも、 OpenNICのDNSサーバを利用する必要があるでしょう。


OpenNIC は、ドメインは別世界だとはいえ、IPアドレスは同じ世界です。
ですから、OpenNIC でさえも、「別のインターネット」だというわけではありません。


IBM が Red Hat を買収

いまさらながらの話ですが、
IBM が Red Hat を買収する件。



商用 GNU/Linux ディストリビューションでは、 Red Hat Enterprise Linux (RHEL) と、 SUSE Linux Enterprise が2大でしょう。


その RHEL を販売している Red Hat が、 IBM に買収されます。



かつては、Red Hat は個人向けに Red Hat Linux を提供していました。
この Red Hat Linux は、現在の Fedora です。
企業製ではなくてコミュニティ製に移行し、 Fedora にかわりました。
RHEL の無償、コミュニティ版は CentOS で、こちらもよく用いられていますね。


個人向け GNU/Linux ディストリビューションとしては、 Debian (とその系統)と、 Fedora が2大です。
その Fedora の母体が Red Hat です。


ですから、 IBM が Red Hat を買収するというのは、とても大きな事件です。


IBM は既にビジネスモデルを変えてかなり経ちますので、 IBM がフリーソフトウェア&オープンソース(FOSS)界に、大金を投資して参入するのは、それほど意外なことではありません。(マイクロソフトが、変節し、 GitHub を買収したりしたとと異なり。)
意外なのは、 Red Hat が(誰にかはともかく)買収される、ということでしょう。


思い返してみると、私としては、 Oracle が Sun Microsystems を買収したの以来の驚きかもしれません。
それで、(プロプライエタリのデータベースソフトウェアで稼ぐ) Oracle が、 MySQL や VirtualBox を手にしているという現象がいまも続いています。


それに比べれば、今回は IBM なので、それほどでもないかもしれません。
IBM は、顧客層に対してシステム、ネットワーク、「ソリューション」を提供するのに、フリーソフトウェアを活用してきたのでしょうから。
IBM のビジネスモデルの変節はもう、かなり以前のことで、 ThinkPad も Deskster や Travelster も、 IBM ではないのですから。
// OS/2 ... 😂


ただ、 Red Hat は上場企業(NYSE: ticker RHT) でやってきたこともあり、
これから IBM に所有されることになるというのは、少なからぬ人々があたふたしていそうです。独立自尊ではなくなりますからね。



TLS 1.3 は、旧バージョンをバッサリ切り捨てた

Lighttpd に Let's Encrypt の証明書をインストールしたら、 Lighttpd に Firefox で繋げないエラーが出てしまいました。
Lighttpd のバグなんですが。


安全な接続ができませんでした

・受信したデータの真正性を検証できなかったため、このページは表示できませんでした。

・この問題をウェブサイトの管理者に連絡してください。

意味不明だわ



TLS 1.2 以前の TLS や SSL では、新しいバージョンで接続不可なときは旧バージョンにフォールバック(ダウングレード)して再接続する機能がありました。


TLS 1.3 では、再接続をしません。


Lighttpd 1.4.51 だと、 TLS 1.3 で接続しようとしつつも、実際にはうまく繋げないバグがあります。

TLS 1.3 の規格では、TLS 1.3 で接続可能なはずなのにうまくいかなければ、フォールバックせずに切断しろと定められています。

Firefoxはこの規格に正しく準拠しているため、Lighttpd との接続をブツッと切ってしまいます 😥
ちなみにGoogle Chrome などの Chromium 系で試してみたら、 TLS 1.2 で繋がりました 😅

TLS 1.3 は、以前は TLS 2.0 にする気だったようです。互換性をバッサリ切り捨てた完全新規のものにしたかったようです。
しかし妥協の産物で、 TLS 1.3 という中途半端なものになりました。
その帰結ですね。
各者の思惑がぶつかり合っている感です。

Mozilla であれ、 Google であれ、 Facebook などであれ、既存の旧規格を改めたいとは思っているわけでしょうが、
いかに自分のアイデアを標準に盛り込もうかと駆け引きというか既成事実化をねらっているのですよね。
各者とも、セキュリティ向上や高速化は、したいのは同じなんですけどね。

TLS 1.3 は、提案段階からそれなりに長期間経ったはずなのですが、確実に実装されるのにはちょっとかかりそうですね。OpenSSL も 1.1.0 で TLS 1.3 を実装したのですが、それが充分に試されていなかったりしますし。
Lighttpd については次バージョンで直るはずです。