<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>DNSPod on 寧屏</title><link>https://www.nullprivate.com/ja-jp/tags/dnspod/</link><description>Recent content in DNSPod on 寧屏</description><generator>Hugo</generator><language>ja-jp</language><lastBuildDate>Thu, 02 Jul 2026 20:00:00 +0800</lastBuildDate><atom:link href="https://www.nullprivate.com/ja-jp/tags/dnspod/index.xml" rel="self" type="application/rss+xml"/><item><title>アリババクラウド DNS 無料版の速度制限：無料の終わりとDNS自主権の再考</title><link>https://www.nullprivate.com/ja-jp/blog/2026/07/02/aliyun-dns-free-tier-rate-limit/</link><pubDate>Thu, 02 Jul 2026 20:00:00 +0800</pubDate><guid>https://www.nullprivate.com/ja-jp/blog/2026/07/02/aliyun-dns-free-tier-rate-limit/</guid><description>&lt;p&gt;2026年5月14日、アリババクラウドは控えめだが影響の大きい製品告知を発表しました：6月24日より、クラウドDNS解決のパブリック権威解決無料版に、1ドメインあたり1日の解決量制限が新たに追加され、上限は10万回、超過すると動的速度制限が発動され、遅延やパケットロス、あるいはその両方が発生します&lt;sup id="fnref:1"&gt;&lt;a href="#fn:1" class="footnote-ref" role="doc-noteref"&gt;1&lt;/a&gt;&lt;/sup&gt;。告知の文言は抑制的で、「大多数の無料ユーザーの1日平均解決量はこの閾値をはるかに下回る」と述べ、何事もないかのような様子でした。&lt;/p&gt;
&lt;p&gt;しかし、この告知の真の重要性は技術的なパラメータ自体ではなく、それが示す転換点にあります：&lt;strong&gt;中国の主要クラウドベンダーの無料DNSサービスは、「デフォルトで十分」から「使用量を計算する必要がある」段階に移行しつつあります。&lt;/strong&gt; 無料DNSに依存する独立開発者、個人サイト運営者、中小チームにとって、これは単独の価格調整ではなく、DNSサービス全体の商業ロジックの再定義です。&lt;/p&gt;
&lt;h2 id="10万回で本当に十分か解決量の実態"&gt;10万回で本当に十分か：解決量の実態&lt;/h2&gt;
&lt;p&gt;公式には「大多数のユーザーは影響を受けない」と述べていますが、この発言は統計的に見て中央値だけを見れば成立する可能性があります。しかし問題は、正常に稼働しているサービスサイトのDNS解決量は複数の要因が重なることで決まり、1日10万回は安心できる閾値ではないということです。&lt;/p&gt;
&lt;p&gt;1ドメインあたりの解決量に影響する主要な変数は以下の通りです：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;サブドメインの数。&lt;/strong&gt; 制限の対象となる「単一ドメイン」とは、親ドメインとそのすべてのサブドメインの解決量の合計を指します&lt;sup id="fnref1:1"&gt;&lt;a href="#fn:1" class="footnote-ref" role="doc-noteref"&gt;1&lt;/a&gt;&lt;/sup&gt;。&lt;code&gt;www&lt;/code&gt;、&lt;code&gt;api&lt;/code&gt;、&lt;code&gt;cdn&lt;/code&gt;、&lt;code&gt;static&lt;/code&gt;など複数のサブドメインを使用するサイトの場合、各サブドメインの解決はすべて合計にカウントされます。中程度の複雑さのWebアプリケーションであれば、解決量は簡単に数倍になります。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;TTLと実際のキャッシュ動作。&lt;/strong&gt; 理論上、再帰的解決器はTTLに従って解決結果をキャッシュし、オリジンへの問い合わせを削減します。しかし現実には、国内の通信事業者級再帰的解決器はTTLを厳守しないケースが広く存在し、中にはTTLの期限切れ前に先にキャッシュを更新したり、長すぎるTTLを無視して独自に短くしたりするものもあります。これは、実際のオリジン問い合わせ回数が理論値をはるかに上回る可能性があることを意味します。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;クローラーとスキャナー。&lt;/strong&gt; 検索エンジンのクローラー、セキュリティスキャナー、SEOツールなどが継続的にDNS解決をトリガーします。これらのトラフィックはページアクセスを発生させませんが、同じく解決枠を消費します。&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;モバイル端末とIoTデバイス。&lt;/strong&gt; モバイルアプリのDNSキャッシュ動作はブラウザと異なり、実装によってはコールドスタート時に毎回再解決を行います。IoTデバイスのDNS実装は品質にばらつきが大きく、多くのデバイスはキャッシュを行わないか、キャッシュ時間が非常に短いです。&lt;/p&gt;
&lt;p&gt;実際の事例として参照できるものがあります：独立ブログyijile.comは告知後に自己点検したところ、1日平均解決量が30万回を超え、制限の300%に達していることがわかりました&lt;sup id="fnref:2"&gt;&lt;a href="#fn:2" class="footnote-ref" role="doc-noteref"&gt;2&lt;/a&gt;&lt;/sup&gt;。一方、このサイトのページアクセス量は同程度の水準には到底達していません。これは、DNS解決量とサイトのUV/PVの間に顕著な非線形な関係があることを示しており、「1日アクセス量」から「1日解決量」を推測することは信頼できないということです。&lt;/p&gt;
&lt;pre class="mermaid"&gt;flowchart TB
 A[ドメイン解決要求] e1@--&amp;gt; B{要求元}
 B e2@--&amp;gt;|ブラウザ| C[TTL内でキャッシュヒット、オリジンに問い合わせなし]
 B e3@--&amp;gt;|モバイルアプリ| D[コールドスタートで再解決、頻繁にオリジンへ問い合わせ]
 B e4@--&amp;gt;|クローラー/スキャナー| E[継続的にオリジンへ問い合わせ、大量消費]
 B e5@--&amp;gt;|IoTデバイス| F[キャッシュ動作が制御不能、頻繁にオリジンへ問い合わせ]
 B e6@--&amp;gt;|再帰的DNSがTTLを厳守しない| G[事前にキャッシュ更新、オリジン問い合わせ量が理論値をはるかに上回る]

 C e7@--&amp;gt; H[枠にカウント：少量]
 D e8@--&amp;gt; I[枠にカウント：大量]
 E e9@--&amp;gt; I
 F e10@--&amp;gt; I
 G e11@--&amp;gt; I

 H e12@--&amp;gt; J[総解決量 ≤ 10万/日]
 I e13@--&amp;gt; K[総解決量 &amp;gt;&amp;gt; 10万/日]

 J e14@--&amp;gt; L[影響なし]
 K e15@--&amp;gt; M[速度制限発動：遅延/パケットロス]

 classDef source fill:#E3F2FD,stroke:#1565C0,color:#0D47A1
 classDef good fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20
 classDef bad fill:#FFEBEE,stroke:#C62828,color:#B71C1C
 classDef animate stroke:#EF6C00,stroke-width:2px,stroke-dasharray: 9 5,stroke-dashoffset: 900,animation: dash 25s linear infinite

 class A,B source
 class C,H,J,L good
 class D,E,F,G,I,K,M bad
 class e1,e2,e3,e4,e5,e6,e7,e8,e9,e10,e11,e12,e13,e14,e15 animate&lt;/pre&gt;
&lt;h2 id="速度制限の背景にある商業ロジック無料の終点は速度制限"&gt;速度制限の背景にある商業ロジック：無料の終点は速度制限&lt;/h2&gt;
&lt;p&gt;アリババクラウドは無料DNSに制限を設けた最初のベンダーではなく、最後のベンダーでもありません。&lt;/p&gt;</description></item></channel></rss>