おととしの記事以来、DNSとして長らくNextDNSを使ってきた。ドメイン単位でマルウェアや広告を拒むという簡潔なアプローチで、満足のいく効果を得ていたが、先日Control Dという類似のDNSサービスに移行した。日本語の記事も少ないようなので、移行の理由と使用例を書いておく。
移行の理由
more than DNS
NextDNSはDNSサーバの基本に忠実だった。ドメインを受け取り、IPアドレスを返す。受け取り、返す。たまにブロックする。以下同様。
一方で邪悪な1広告とマルウェアの手法は年々巧妙になっている。特に、コンテンツと同じドメインから・コンテンツと密結合して流れてくるような場合には、通常のDNSでは太刀打ちできない。唯一の解決策は、VPN等に手を出して、広告の出ない地域2、あるいは多少まともな広告が出る地域からのアクセスを装うことだった。
Control DもあくまでDNSサーバであり、その限りではNextDNSと同じ機能をもつ。ただ、あわせて提供されるトラフィック転送機能、なかでも位置偽装機能がこうした場面で役立つ。やっていることはVPNやプロキシと似ていて、世界各地のお好みのサーバを選んで通信を転送することで、当該地域からのアクセスを装うことができる。ただしVPNとは違い、指定したドメインごとに通信が処理される(ドメインごとに行き先を分けられる・他の通信は影響を受けない)、当局の検閲には対抗できない、などの特色がある。
要するに「アクセス元の地域を様々に変えたいが、VPNほど仰々しい匿名性は要らない」というのがこの機能の想定するユースケースである。これには先に述べた広告やマルウェアへの対処のほか、提供地域が限られた海外コンテンツ等を利用する場合も含まれる。
ルールのきめ細かな管理
特定のサービスの関連ドメインについて、そのDNS応答を一括で処理したい、という場合はしばしばある(例:「X / Twitterはすべて拒否」)。NextDNSでは、数十種類のサービスについて「拒否(とその時間制限)」のみを選択できた。他方、Control Dでは数百種類3について「許可・拒否・転送」を設定できる。また、自分で作成したカスタムルールもフォルダで管理できる。
iOSでDNS-over-HTTP/3が使いやすい
iOSでNextDNSを利用する際、公式にサポートされている方法は、直接プロファイルをダウンロードするか、公式アプリを利用するかのいずれかであった。これらはいずれもiOSのプロファイル機能を利用して暗号化DNSを設定する。この場合、DNS-over-HTTPSは利用できるが、HTTP/3が利用されるかは運任せとなる(ほぼ利用されない)。
他方、Control Dの場合、プロファイルによる設定に加えて「VPNとして動作させる」方法が用意されており、確実にHTTP/3を利用できる。
この方法は名前こそ「VPN」だが、実際にはローカルでctrld(公式のコマンドラインクライアント)を動作させ、そこに接続している(つまりWindows / Mac / Linux等での利用方法と同じ)。そのためこれらの場合と同様、TOML形式で設定を行える。設定ファイルはコントロールパネル(Endpoints
> エンドポイント > ctrld status
)から投入する。
開発が活発
NextDNSはそれなりに成熟している、というか保守的で、新機能の追加はあまりない。開発の活発さという点ではControl Dが勝る。
たまたま安かった
StackSocialにて、サブスク5年分の公式のバウチャー(約40ドル→クーポンで約32ドル)が売られていた4。これを買うと、二種類あるプランのうち下位(転送機能なし、定価年間20ドル)が有効になるが、じつは年間10ドルを追加で払うことで、上位のプラン(定価年間40ドル)に変更できる。総計すると5年で約82ドル(年間約16.4ドル、定価の4割ほど)となり、NextDNS(年間20ドル)よりも安い。
使用例
位置偽装
多国籍企業が都合よく国境を跨ぐとき、ユーザもまた都合よく国境を跨ぐ。国ごとにコンテンツや広告の出し分けをするサービスに対しては、ユーザ側も適度にVPNやプロキシを使うのが礼儀である。
このとき、広告のない国に繋いでメリットを享受するのもひとつの選択だが、より建設的なのは、通常と同じように広告を見てサービスに貢献しつつ、邪悪な広告が出る地域は避ける、という選択である。
実のところ、どうせクリックしないならどの地域の広告を見ても変わりはない(いずれにしてもサービス側に対価は支払われる)。広告を見ることに同意したからといって、その提供元も選べないというわけではないのだ。
IPv6化
ところで、Control Dのトラフィック転送機能には、上で述べた位置偽装だけではなく、純粋にドメインの宛先を変える(A / AAAA / CNAMEレコードを任意に書き換える)機能も含まれる。この機能を活用して、さまざまなサービスにIPv6を利用させる設定をしているので、紹介する。
Twitter / XのCDN
Twitter / Xのアセット配信(abs.twimg.com
, pbs.twimg.com
)には、複数社(Akamai, Edgecast, Fastly)のCDNがランダムに使われる。しかし各社の応答速度にはばらつきがあり、場合によってはIPv4しか対応していないこともある5。そこでCNAMEレコードを固定して、高速かつIPv4 / IPv6両対応のCDNを使うようにする。
体感では、三社のうち最も速いのはFastlyだった。FastlyのCDNは、ドメインの冒頭にdualstack.
を付けるとIPv4 / IPv6双方で応答してくれる。そこでabs.twimg.com
, pbs.twimg.com
がdualstack.twimg.twitter.map.fastly.net.
に向かうようCNAMEレコードを設定する。
耐障害性はやや下がるが、画像読み込みの体験が少し改善する。
iOSの通知
ある投稿を見て知った。曰く、iOSの通知は現時点ではIPv4のみで流れてくるが、背後にはIPv6対応のインフラが存在するため、CNAMEレコードをいじればIPv6で受け取れるらしい。
画像のように*-courier.push.apple.com
をapac-asia-courier-vs.push-apple.com.akadns.net.
に向ければ、当該ツイートと同じことが実現できる(Control Dではルールにワイルドカードを使える)。
Discord
ほとんどバグのような現象だが、実はCloudflareのCDNを使っているサイトは、たとえIPv6を有効化していなくてもIPv6でアクセスできることが知られている(参考:Redditの投稿)。
というのも、サイトに割り当てられる(はずだった)CDNのIPv6アドレスは、IPv4アドレスから機械的に算出できるからである。算出したアドレスを、ドメインのAAAAレコードとして応答するように設定すると、IPv6でアクセスが通るようになる6。
IPv4にしか対応していないDiscordも、CloudflareのCDNを使っているため、この方法で(ほぼ)IPv6化できる。詳細は省くが、いくつかのドメインについて適切なA / AAAAレコードを設定すれば動作するはずだ。
なお、ログイン時にgateway.discord.gg
宛てに飛ぶ通信、およびCloudflareを使っていない一部のサブドメインについてはIPv6を利用できない。これらは除外する必要がある。
おわりに
おそらくYouTubeとX / Twitterの広告が消せる唯一のDNSサービスである。5年分契約してしまったので、しばらくはこれでやっていく。