このセクションの複数ページ・印刷対応ビューです。印刷するにはここをクリック.

ブログ - 寧屏技術シェアと製品アップデート

寧屏技術ブログ、DNSサービス、プライバシー保護、ネットワークセキュリティなどの技術記事を共有。最新製品機能、業界動向、技術チュートリアルをご覧ください

寧屏アドブロック：DNSベースのスマート広告ブロックソリューション
DoH と DoT の技術比較分析
DNSプライバシー保護とユーザープロファイリング対策戦略
深掘り解説：寧屏DNSプロキシ機能、ネットワーク制限を突破してプライバシー保護を実現
AdGuardPrivateの名称変更のお知らせ
DDNS機能を追加しました
ECS をより良くサポート
寧屏 - AdGuard Homeをベースにした強化版DNSサービス
HTTP/3プロトコルの完全サポート
カスタムクライアント名機能のリリース
広告ブロックの必要性：デジタル時代の注意力とプライバシーを守る
サービスリソース最適化戦略説明
ベーシック版メモリ上限調整
いつでもご支援いたします
専用リンクの設定方法
フルアップグレード - 強化版広告ブロックルール
トライアル版サービス詳細

寧屏アドブロック：DNSベースのスマート広告ブロックソリューション

寧屏がDNSフィルタリング技術を通じて効率的な広告ブロックを実現し、快適なウェブ体験を提供し、デジタルプライバシーを保護する方法を深く掘り下げます。

2025 August 18

デジタル化が進む現代において、広告はインターネットエコシステムの重要な構成要素となっていますが、過度な広告はユーザーエクスペリエンスを損ない、プライバシーの漏洩リスクを引き起こす可能性もあります。寧屏（NullPrivate）は、プライバシー保護に特化したDNSサービスとして、AdGuard Homeと同様のDNSフィルタリング技術を採用し、ユーザーに効率的な広告ブロックソリューションを提供します。

寧屏アドブロックの仕組み

寧屏の広告ブロック機能はDNS（ドメインネームシステム）フィルタリング技術に基づいており、以下のようなワークフローで動作します：

flowchart TB
    A[ユーザーデバイス] --> B{DNSクエリリクエスト}
    B --> C[寧屏DNSサーバー]
    C --> D[ドメインデータベース照会]
    D --> E{広告またはトラッキングドメイン？}
    E -->|はい| F[空アドレスまたはループバックアドレスを返す]
    E -->|いいえ| G[正しいIPアドレスを返す]
    F --> H[広告の読み込みをブロック]
    G --> I[通常のウェブサイトアクセス]

DNSリクエスト監視

デバイスがウェブサイトにアクセスしようとすると、まずDNSサーバーにドメインに対応するIPアドレスを問い合わせます。寧屏は優先DNSサーバーとしてこれらのクエストを受信し、分析します。

スマートフィルタリングメカニズム

寧屏は、膨大な広告およびトラッキングドメインデータベースを維持しています。ユーザーがアクセスしようとするドメインが広告またはトラッキングに該当する場合、システムは即座にリクエストをインターセプトします。

高速レスポンス

ブロックされたリクエストに対して、寧屏は空アドレスまたはローカルループバックアドレス（例：127.0.0.1）を返すことで、広告コンテンツの読み込みを防ぎます。通常のウェブサイトアクセスリクエストに対しては、正しいIPアドレスを提供し、ユーザーが目的のサイトに正常にアクセスできるようにします。

技術的優位性

高効率

ネットワークレベルでのブロック：DNS解決段階で広告の読み込みを阻止し、ウェブコンテンツのダウンロードを待つ必要がありません
ミリ秒単位のレスポンス：ローカライズされたDNSレスポンスメカニズムにより、ウェブページの読み込み速度にほとんど影響しません
全デバイス保護：一度設定すれば、ネットワーク内のすべてのデバイスを保護

高精度

多層フィルタリング：正確なドメインマッチング、ワイルドカードルール、正規表現に対応
スマート分類：フィルタリングルールを広告、トラッカー、マルウェアなどに分類管理
動的アップデート：信頼できるソースから最新のフィルタリングルールを定期的に取得

プライバシー保護

トレースフリーブラウジング：ユーザーのアクセス履歴を記録せず、閲覧プライバシーを保護
データ漏洩の削減：広告主やトラッカーによるユーザーデータ収集を阻止
ローカル処理：大部分のフィルタリング処理をローカルで実行し、データ外部漏洩リスクを削減

AdGuard Homeとの類似点

寧屏は広告ブロックにおいて、AdGuard Homeと同じコア技術原理を採用しています：

DNSベースのフィルタリングメカニズム：両方ともDNSクエリをインターセプトすることで広告ドメインの解決を阻止
フィルタリングルール管理：カスタムフィルタリングルールとホワイト/ブラックリスト設定に対応
ネットワーク範囲保護：LAN全体に広告ブロックサービスを提供
オープンソースコミュニティサポート：オープンソースコミュニティが維持するフィルタリングルールリストの恩恵を受ける

ユーザーエクスペリエンスの最適化

寧屏は設計において特にユーザーエクスペリエンスに重点を置き、広告ブロック機能が効率的でありながら通常の使用に干渉しないことを保証しています：

透明性のある管理

詳細なブロック統計情報を提供し、ユーザーが保護効果を把握できる
柔軟なホワイトリスト設定に対応し、重要なサイトの誤ブロックを回避
リアルタイムで有効となるルールアップデート、デバイスの再起動不要

使いやすさの設計

設定プロセスを簡素化し、一般ユーザーでも簡単に利用可能
多言語サポートを提供し、様々なユーザーのニーズに対応
あらゆるネットワーク環境およびデバイスタイプと互換性あり
安全で信頼できるDNSサーバーサポートを備える

プライバシー保護

厳格なプライバシー保護措置により、ユーザープライバシーを保護
ユーザーの個人識別情報を収集しない
ユーザーデータのセキュリティを確保

使用に関する推奨事項

最適な広告ブロック効果を得るため、以下をお勧めします：

ルールの適切な設定：実際のニーズに応じて適切なフィルタリングルールリストを選択
定期的なアップデート確認：フィルタリングルールデータベースが最新の状態であることを確認
ブロック統計の確認：統計データを通じて広告ブロック効果を把握
ホワitelistのタイムリーな調整：誤ブロックされた正常なサイトをホワイトリストに追加

まとめ

寧屏は先進的なDNSフィルタリング技術を通じて、ユーザーに効率的で高精度かつプライバシーを重視した広告ブロックソリューションを提供します。私たちは、ユーザーが広告の煩わしさから守られると同時に、通常のネットワーク使用体験に影響を与えないように努めています。寧屏を選ぶことで、ネットワーク環境をよりクリーンで安全なものにできます。

デジタル時代において、誰もがクリーンでプライベートなサイバー空間を持つ権利があります。寧屏はまさにこの目標を実現するために設計され、ユーザーが自身のデジタルライフを再びコントロールできるよう支援します。

DoH と DoT の技術比較分析

ネットワークプロトコルレベルからDNS over HTTPSとDNS over TLSの技術実装、性能差、適用シナリオを深く分析

2026 February 11

DNS over HTTPS (DoH) と DNS over TLS (DoT) は、DNSクエリの安全な転送を実現する2つの一般的な暗号化DNS伝送方式です。DoTの標準はRFC 7858で定義され、DoHはDNS Queries over HTTPS (DoH)で標準化されています。これらの技術の本質的な違いを理解するには、ネットワークプロトコル階層構造から分析する必要があります。

ネットワークプロトコル階層構造

現代のネットワークプロトコルスタックは階層設計を採用しており、各層が異なる機能を提供します。DNSはアプリケーション層プロトコルとして、特定の伝送方式に依存せず、複数のベアラープロトコル上で動作できます。

アプリケーション層 (L7) にはHTTP/1.1、HTTP/2、HTTP/3、FTP、DNSなどのプロトコルが含まれます。注目すべきは、HTTP/3のセマンティクスは依然としてアプリケーション層にありますが、QUICが伝送ベアラーとして機能することです。セキュリティ層はアプリケーション層とトランスポート層の間に位置し、主にTLSとその変種で構成されます。TLSは通常TCP上で動作し、HTTPSやDoTがこれに該当します。DTLSはTLSのデータグラム版で、UDP上で動作できます。QUICプロトコルは特殊で、TLS 1.3のハンドシェイクと鍵導出をプロトコル内部に直接統合しています。

QUICはL4.5層プロトコルと見なすことができ、UDPを基盤に拡張され、従来のトランスポート層の機能を提供します。トランスポート層 (L4) にはTCP、UDP、QUICが含まれます。実装の観点ではQUICはUDPベースですが、信頼性、輻輳制御、多重化、暗号化ハンドシェイクなどの機能を備えているため、工学的には独立したトランスポート層プロトコルとして扱われます。ネットワーク層 (L3) はIPプロトコル（IPv4/IPv6）を使用し、データパケットの経路選択と転送を担当します。データリンク層 (L2) にはイーサネットやWi-Fi（802.11）などの技術が含まれます。

TLSは暗号化手段として、アプリケーション層とトランスポート層の間で機能します。もしTLS暗号化をDoTから分離すると、DoTは本質的にDNS over TCPになります。この階層設計により、暗号化はプロトコル自体の強制要件ではなく、オプション機能となります。

Plain DNSの特徴

最も一般的なDNSはPlain DNSと呼ばれ、UDPまたはTCP上で動作します。UDPは接続確立が簡単で初回クエリ速度が速いため、最も一般的なベアラー方式です。しかしUDPの弱点は信頼性がなく、ネットワークでパケットが失われやすいことです。TCPはハンドシェイク回数が多いため初回接続速度がUDPより約30%遅いですが、長い接続を確立した後の応答速度はUDPと同じです。

キャリアはネットワークが混雑すると、機器の負荷軽減のためにUDPパケットを破棄することがあります。一部のキャリアでUDPパケット損失が深刻な地域では、DNSクエリにTCPを使用する方が有利な場合があります。TCPには再送メカニズムがあり、パケットが失われてもデータを確実に到達させますが、UDPパケットを破棄しても小規模キャリア機器の負荷は軽減されず、再試行によってむしろ不確実性が増す可能性があります。

アプリケーション層のネスト

DNSとHTTPはどちらもアプリケーション層プロトコルであり、DoHは本質的に1つのアプリケーション層プロトコルが別のアプリケーション層プロトコルをネストしたものです。DoHは必ずしもDNS over HTTPSである必要はなく、通常のHTTPを使用することも可能ですが、暗号化されていないDoHは平文リクエストのため、Plain DNSと比べて何の利点もなく、ごく少数の特殊なニーズシナリオでのみ使用されます。

理論的には、任意のアプリケーション層プロトコル上でDNSを伝送できます。例えばDNS over FTPも実装可能で、対応するサーバーとクライアントを開発するだけで実現できます。この柔軟性はアプリケーション層プロトコルの組み合わせ可能性を示しています。

flowchart TD
    subgraph L7["アプリケーション層"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["セキュリティ層"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["トランスポート層"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["ネットワーク層"]
        I[IP]
    end
    
    subgraph L2["データリンク層"]
        J[Ethernet]
        K[WiFi]
    end
    
    A --> D
    B --> D
    C --> D
    D --> F
    E --> G
    H --> G
    F --> I
    G --> I
    H --> I
    I --> J
    I --> K
    
    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#fff4e1
    style F fill:#ffe1e1
    style G fill:#ffe1e1
    style H fill:#e1ffe1

トランスポート層のネスト

QUICプロトコルはUDPを基盤とし、同時にトランスポート層でコネクション指向サービスを提供します。QUICはTCPが持つコネクション指向、輻輳制御、再送、フロー制御、フラグメンテーションとアセンブリなどのトランスポート層機能を実装しています。TCPと比較してQUICは遅延が低く、UDPと比較してより先進的で信頼性が高いです。

プロトコル組み合わせ関係

アプリケーション層とトランスポート層の間に必然的な制限関係はなく、暗号化は追加することも追加しないこともできます。HTTPはTCP上で動作することも、QUIC上で動作することもできます。DNSはTCP上で動作することも、UDP上で動作することも、QUIC上で動作することもできます。

これらの可能性に基づいて、以下の組み合わせ関係をまとめることができます。Plain DNSはUDPまたはTCPにDNSプロトコルを加えたものです。HTTP/2はTCPにTLS 1.2またはTLS 1.3を加え、さらにHTTPプロトコルを加えたものです。HTTP/3はQUICにTLS 1.3を加え、さらにHTTPプロトコルを加えたものです。

DoH (DNS over HTTPS) はHTTP/2またはHTTP/3にDNSプロトコルを加えたものです。DoT (DNS over TLS) はTCPにTLS 1.2またはTLS 1.3を加え、さらにDNSプロトコルを加えたものです。DoQ (DNS over QUIC) はQUICにTLS 1.3を加え、さらにDNSプロトコルを加えたものです。

flowchart LR
    subgraph DoT["DoT DNS over TLS"]
        direction LR
        T1[TCP] --> T2[TLS]
        T2 --> T3[DNS]
    end
    
    subgraph DoH2["DoH over HTTP/2"]
        direction LR
        H1[TCP] --> H2[TLS]
        H2 --> H3[HTTP/2]
        H3 --> H4[DNS]
    end
    
    subgraph DoH3["DoH over HTTP/3"]
        direction LR
        Q1[QUIC] --> Q2[TLS 1.3]
        Q2 --> Q3[HTTP/3]
        Q3 --> Q4[DNS]
    end
    
    subgraph DoQ["DoQ DNS over QUIC"]
        direction LR
        D1[QUIC] --> D2[TLS 1.3]
        D2 --> D3[DNS]
    end
    
    style T1 fill:#e3f2fd
    style T2 fill:#fff3e0
    style H1 fill:#e3f2fd
    style H2 fill:#fff3e0
    style Q1 fill:#e8f5e9
    style Q2 fill:#fff3e0
    style D1 fill:#e8f5e9
    style D2 fill:#fff3e0

性能と互換性分析

プロトコル階層構造を理解した後、DoHとDoTの長所と短所を分析できます。

TCPとQUICの比較は、キャリアの実際のネットワーク環境を考慮して議論する必要があります。QUICは比較的新しいプロトコルで、古いネットワーク問題を解決していますが、UDPベースであることに変わりはありません。ネットワーク遅延の観点では、QUICベースのプロトコルの遅延はTCPより約35%低いため、理論的にはDNS over HTTP/3とDoQ (DNS over QUIC) はDNS over HTTP/2とDoTより性能が優れています。

しかし実際のネットワーク環境では、パケット損失による再送遅延の問題が存在します。キャリアはネットワークが混雑するとUDPパケットを破棄する傾向があり、QUICはUDPとして識別されて破棄される可能性があります。QUICは再送をサポートしていますが、再送によって導入される遅延により、QUICの実際の遅延がTCPより高くなる可能性があります。

プライバシーとセキュリティの面では、DoHとDoTはどちらも暗号化トラフィックであり、盗聴や改ざんの対象になりません。DoTが識別されてブロックされる問題については、主にAndroidシステムの暗号化DNS設定がデフォルトで853ポートを使用するため、853ポートがセンシティブポートになっていることが原因です。DoT自体は一般的な普通の暗号化トラフィックであり、DNS専用トラフィックとして識別されることはありません。実際には任意のポートでDoTサービスを提供でき、Androidではサードパーティアプリが必要ですが、iOSでは任意ポートのDoT使用をネイティブサポートしています。

拡張性はDoHの重要な利点です。HTTPでカプセル化されたDNSとPlain DNSと比較して、HTTPは明らかに優れた拡張性を持っています。サービスプロバイダーは443ポート上でDoHを含む無数のサービスを提供でき、機能拡張も容易です。DoTとDoQは一般的に専用ポートを必要とし、拡張能力は完全にPlain DNSベースです。これはサービスプロバイダー視点の違いであり、一般ユーザーには現時点で明確な認識はありません。

DNSリクエストの処理速度に関しては、HTTPの処理速度がPlain DNSより数クロックサイクル遅い可能性がありますが、この差は実際の使用では無視できます。互換性の面では、DoHの方が主流になる可能性があります。なぜならサービスプロバイダーにとってDoHの拡張性が優れているからです。

現在の主要プラットフォームの暗号化DNSサポート状況は様々です。ChromiumカーネルのブラウザはDoHをサポートしています。Windows 11システムはネイティブでDoHをサポートしています。Android 8以降のシステムはネイティブでDoTをサポートしています。Android 11以降のシステムはネイティブでDoTとDoHをサポートしています。macOSシステムはネイティブでDoTとDoHをサポートしています。iOSシステムはネイティブでDoTとDoHをサポートしています。

実際の選択アドバイス

一般ユーザーにとっては、DoHを使用する方がDoTより手間がかかりません。DoHはDoTと比較して、多くの場合より優れた遅延を提供し、一部の場合で同程度の遅延を提供します。DoHはDoQと比較して、多くの場合同程度の遅延を提供し、一部の場合でより優れた遅延を提供します。

この結論の前提は、サービスプロバイダーがDNS over HTTP/3サービスを提供していることです。サービスプロバイダーがHTTP/3を提供しない場合、DoHとDoTに明確な違いはありません。DoHはネットワーク品質が良い場合、自動的にDoH/3を使用して低遅延を実現し、ネットワーク品質が悪い場合、自動的にHTTP/2にダウングレードします。この適応能力はサービスプロバイダーの実装が必要ですが、主要サービスプロバイダーは一般的に実装しています。

寧屏の試用をお勧めします。DoTとDoH/3をサポートし、ネイティブで広告ブロックとDNS分流機能を備えています。自己デプロイが必要な場合は、そのオープンソースライブラリを使用できます。

ネットワークプロトコルの選択には、キャリアのネットワーク品質、サービスプロバイダーのサポート状況、デバイスの互換性など、複数の要素を総合的に考慮する必要があります。大多数のユーザーにとって、DoHは性能、互換性、プライバシー保護のバランスが取れた優れた選択肢です。

DNSプライバシー保護とユーザープロファイリング対策戦略

DNSクエリとユーザープロファイリング構築を中心に、原理とリスクから出発し、公開標準と資料に基づいて実現可能なプライバシー保護戦略と注意事項を説明し、憶測的な評価や実践を避ける。

2025 October 09

DNSプライバシー保護とユーザープロファイリング対策戦略

読者：ネットワークプライバシーとデータガバナンスに関心を持つエンジニア/運用/セキュリティ従事者
キーワード：ローカルリゾルバ、再帰的解決、権威サーバー、QNAME最小化、ECS、DNSSEC、DoT/DoH/DoQ

背景と問題概要

デジタル時代において、ユーザーのネットワーク行動データは企業がユーザープロファイリングを構築する重要な情報源となっています。インターネットインフラのコアコンポーネントであるドメインネームシステム（DNS）は、日常的なネットワーク活動において人間が読めるドメイン名を機械が読めるIPアドレスに変換する重要な役割を担っています。しかし、従来のDNSクエリは通常UDPポート53で平文で送信されるため、ユーザーの閲覧履歴、アプリケーション使用習慣などの機密情報がネットワーク事業者、インターネットサービスプロバイダ、および様々な中間者によって容易に取得・分析される可能性があります。

ユーザープロファイリングは、ユーザーの様々な行動データを収集・分析して構築されるユーザー特性モデルであり、企業はこれらのモデルを活用してターゲティング広告、コンテンツ推薦、リスク評価などの商業活動を行っています。これらのサービスはある程度ユーザーエクスペリエンスを向上させますが、プライバシー漏洩、データ乱用、潜在的な差別的価格設定などの問題も引き起こします。DNSレベルの技術的手段を通じてユーザープロファイリングの精度を低下させる方法を理解することは、個人のプライバシー保護において重要なアプローチとなります。

本稿ではDNSの基本原理から出発し、ユーザープロファイリング構築プロセスにおけるデータ収集ポイントを分析し、DNSベースのプライバシー保護戦略を探求し、異なるシナリオにおける実装の考え方と注意事項を説明します。

基礎と用語整理

DNSプライバシー保護を理解するには、まずDNSクエリの基本プロセスと関連用語を把握する必要があります。DNSクエリは通常複数の関係者を巻き込み、各段階がプライバシー漏洩のポイントとなる可能性があります。

flowchart LR
    A[クライアントデバイス] e1@--> B[ローカルリゾルバ]
    B e2@--> C[再帰的リゾルバ]
    C e3@--> D[ルートサーバー]
    D e4@--> E[TLDサーバー]
    E e5@--> F[権威サーバー]
    F e6@--> C
    C e7@--> B
    B e8@--> A
    C --> G[キャッシュストレージ]
    
    e1@{ animation: fast }
    e2@{ animation: slow }
    e3@{ animation: medium }
    e4@{ animation: fast }
    e5@{ animation: medium }
    e6@{ animation: fast }
    e7@{ animation: fast }
    e8@{ animation: slow }
    
    style A fill:#e1f5fe
    style B fill:#f3e5f5
    style C fill:#fff3e0
    style D fill:#f1f8e9
    style E fill:#f1f8e9
    style F fill:#f1f8e9
    style G fill:#fce4ec

ローカルリゾルバ（Stub Resolver）はオペレーティングシステムまたはアプリケーション内のDNSクライアントコンポーネントで、アプリケーションからのDNSクエリ要求を受け取り、再帰的リゾルバに転送する役割を担います。再帰的リゾルバ（Recursive Resolver）は通常ISPまたはサードパーティDNSサービスが提供し、ルートサーバー、トップレベルドメイン（TLD）サーバー、権威サーバーへのクエリを含む完全なドメイン解決プロセスを実行し、最終結果をクライアントに返します。

権威サーバー（Authoritative Server）は特定ドメインのDNSレコードを保存し、ドメイン情報の最終的な情報源です。キャッシュメカニズムはDNSシステムの重要な構成要素であり、再帰的リゾルバはクエリ結果をキャッシュして重複クエリを減らし、解決効率を向上させます。TTL（Time To Live）値はDNSレコードがキャッシュに保存される時間を決定します。

EDNS Client Subnet（ECS）は拡張メカニズムで、再帰的リゾルバが権威サーバーにクライアントのサブネット情報を渡すことを可能にし、CDNや地理的位置サービスの精度向上を目的としています。しかし、ECSはユーザーの地理的位置情報を暴露し、プライバシー漏洩リスクを増加させる可能性もあります。

プライバシー脅威と動機

平文DNSクエリはユーザープロファイリング構築に豊富なデータソースを提供します。DNSクエリ記録を分析することで、攻撃者またはデータ収集者はユーザーの閲覧習慣、アプリケーション使用状況、地理的位置情報などの機密データを取得し、詳細なユーザープロファイリングを構築することができます。

flowchart TD
    A[ユーザーインターネット行動] e1@--> B[平文DNSクエリ]
    B e2@--> C[ISPリゾルバ]
    B e3@--> D[パブリックDNSサービス]
    C e4@--> E[ユーザーアクセス記録]
    D e5@--> F[クエリログ]
    E e6@--> G[行動分析]
    F e7@--> G
    G e8@--> H[ユーザープロファイリング]
    H e9@--> I[ターゲティング広告]
    H e10@--> J[コンテンツ推薦]
    H e11@--> K[価格差別]
    
    L[サードパーティトラッカー] e12@--> M[クロスサイト関連付け]
    M e13@--> G
    
    N[デバイスフィンガープリント] e14@--> O[一意識別]
    O e15@--> G
    
    e1@{ animation: fast }
    e2@{ animation: medium }
    e3@{ animation: medium }
    e4@{ animation: slow }
    e5@{ animation: slow }
    e6@{ animation: fast }
    e7@{ animation: fast }
    e8@{ animation: medium }
    e9@{ animation: fast }
    e10@{ animation: fast }
    e11@{ animation: fast }
    e12@{ animation: medium }
    e13@{ animation: fast }
    e14@{ animation: medium }
    e15@{ animation: fast }
    
    style A fill:#e1f5fe
    style B fill:#fff3e0
    style C fill:#ffebee
    style D fill:#ffebee
    style E fill:#fce4ec
    style F fill:#fce4ec
    style G fill:#f3e5f5
    style H fill:#e8eaf6
    style I fill:#fff9c4
    style J fill:#fff9c4
    style K fill:#ffcdd2
    style L fill:#ffebee
    style M fill:#fce4ec
    style N fill:#ffebee
    style O fill:#fce4ec

DNSクエリデータがユーザープロファイリング構築に持つ価値は主にいくつかの側面に現れます。まず、クエリ頻度と時間パターンはユーザーの日常の生活リズムを明らかにし、例えば平日と週末のインターネット利用習慣の違い、夜間の活動パターンなどが分かります。次に、クエリするドメインの種類はユーザーの興味・関心を反映し、ニュースサイト、ソーシャルメディア、動画プラットフォーム、ショッピングサイトなどのアクセス傾向が分かります。さらに、サブドメインのアクセスパターンはより詳細な行動分析を提供し、例えばユーザーが特定のソーシャルプラットフォームのサブ機能ページを頻繁に訪問しているかどうかなどが分かります。

地理的位置情報はユーザープロファイリングの重要な構成要素です。ECSメカニズムと再帰的リゾルバの位置分析を通じて、ユーザーの物理的位置または移動軌跡を推測できます。時系列分析と組み合わせることで、ユーザーのよく行く場所や活動範囲を識別することも可能です。

クロスデバイスのID関連付けはユーザープロファイリング構築のもう一つの重要な環です。DNSクエリ内の特定のパターン（例えば異なるデバイスでの同じドメインへのクエリ時間分布）を分析することで、同一ユーザーの複数デバイスを関連付け、より包括的なユーザープロファイリングを構築できる可能性があります。

商業的動機がユーザープロファイリング構築を推進しています。ターゲティング広告配信が主要な応用シナリオで、企業はユーザーの閲覧興味を分析して関連性の高い広告を表示し、コンバージョン率を向上させます。コンテンツ推薦システムはユーザープロファイリングを活用してパーソナライズされたニュース、動画、製品推薦を提供し、ユーザーエンゲージメントを強化します。リスク評価は金融、保険などの分野で応用され、ユーザーの行動パターンに基づいて信用リスクや詐欺の可能性を評価します。

保護戦略と原理

DNSプライバシー漏洩リスクに対し、業界では暗号化伝送、クエリ難読化、ソース制御の3方向を中心に様々な保護戦略が発展してきました。これらの戦略はそれぞれ特徴があり、異なるシナリオやニーズに適しています。

flowchart TD
    A[DNSプライバシー保護戦略] --> B[暗号化伝送]
    A --> C[クエリ難読化]
    A --> D[ソース制御]
    
    B --> B1[DoT - DNS over TLS]
    B --> B2[DoH - DNS over HTTPS]
    B --> B3[DoQ - DNS over QUIC]
    
    C --> C1[QNAME最小化]
    C --> C2[バッチクエリ]
    C --> C3[タイミングランダム化]
    
    C1 --> C1A[段階的送信]
    C1 --> C1B[露出削減]
    
    D --> D1[ローカルhosts]
    D --> D2[信頼できる再帰的リゾルバ]
    D --> D3[DNSフィルタリング]
    
    D2 --> D2A[プライバシーポリシー]
    D2 --> D2B[ログ非記録]
    D2 --> D2C[サードパーティ監査]
    
    style A fill:#e1f5fe
    style B fill:#e8f5e8
    style C fill:#fff3e0
    style D fill:#f3e5f5
    style B1 fill:#e8f5e8
    style B2 fill:#e8f5e8
    style B3 fill:#e8f5e8
    style C1 fill:#fff3e0
    style C2 fill:#fff3e0
    style C3 fill:#fff3e0
    style D1 fill:#f3e5f5
    style D2 fill:#f3e5f5
    style D3 fill:#f3e5f5

暗号化伝送はDNSプライバシー保護の基本的な手段で、主に3つの技術が含まれます：DNS over TLS（DoT）、DNS over HTTPS（DoH）、DNS over QUIC（DoQ）。DoTはTCPポート853を使用して暗号化されたDNSクエリを伝送し、TLSプロトコルを通じてエンドツーエンドの暗号化保護を提供します。DoHはDNSクエリをHTTPSトラフィック内にカプセル化し、標準の443ポートを使用するため、既存のネットワーク環境に溶け込みやすく、ファイアウォールやネットワーク管理デバイスによる識別・ブロックを回避しやすくなっています。DoQはQUICプロトコルに基づく新興のソリューションで、UDPの低遅延とTLSのセキュリティを組み合わせ、接続マイグレーションなどの高度な機能をサポートします。

QNAME最小化（RFC7816）はクエリ難読化技術の一つで、再帰的リゾルバが上流サーバーにクエリを送信する際、完全なドメイン名ではなく段階的にドメイン名を送信します。例えば、“www.example.com"をクエリする場合、まず"com"をクエリし、次に"example.com”、最後に"www.example.com"をクエリします。この方法は上流サーバーが取得する完全なドメイン名情報を減らしますが、クエリ遅延が増加する可能性があります。

バッチクエリとタイミングランダム化は追加のクエリ難読化手段です。バッチクエリは複数のDNSリクエストを異なる時間に分散して送信し、クエリパターンを通じたユーザー行動の関連付けを回避します。タイミングランダム化はクエリ間隔にランダムな遅延を導入し、時間パターン分析の可能性を打破します。

ソース制御戦略はDNSクエリの発信段階に注目します。ローカルhostsファイルはDNSクエリをバイパスして一般的なドメイン名を直接解決し、クエリ記録の生成を減らします。信頼できる再帰的リゾルバは厳格なプライバシーポリシーを持つDNSサービスプロバイダを選択します。例えば、クエリログを記録しない、サードパーティトラッキングを受け入れないサービスなどです。DNSフィルタリングは既知のトラッカーや悪意のあるドメインをブロックし、不必要なデータ露出を減らします。

実装パスと注意事項

DNSプライバシー保護の実装には技術的実現可能性、パフォーマンスへの影響、導入の複雑さを考慮する必要があります。具体的な方案を選択・実施する際には、プライバシー保護効果と実際の可用性のバランスを取る必要があります。

暗号化DNSの導入には複数の方法があります。OSレベルでのサポートが最も理想的で、Android 9+、iOS 14+、Windows 11はいずれもDoHまたはDoTをネイティブサポートしています。アプリケーションレベルでの実装は特定のソフトウェアに適しており、ブラウザに組み込まれた暗号化DNS機能などが該当します。ネットワーク機器レベルでの導入はルーターやファイアウォールで暗号化DNSを設定し、ネットワーク全体に保護を提供します。

QNAME最小化の実装は主に再帰的リゾルバが担当し、ユーザーはこの機能をサポートするDNSサービスを選択する必要があります。QNAME最小化は完全なドメイン名情報に依存するプリフェッチや負荷分散などのパフォーマンス最適化に影響を与える可能性があることに注意が必要です。

信頼できる再帰的リゾルバの選択には複数の要素を考慮します。プライバシーポリシーが最優先で、クエリログの記録有無、ログ保存期間、データ共有ポリシーなどが含まれます。サービスパフォーマンスはユーザーエクスペリエンスに影響し、解決遅延、可用性、グローバル分散などが含まれます。サービスの透明性も重要な要素で、運営ポリシーの公開やサードパーティ監査の受入れなどが挙げられます。

DNSフィルタリングは誤検知と見逃しの問題に注意が必要です。過度に厳格なフィルタリングは正常なウェブサイトへのアクセスを妨げる可能性があり、緩すぎるフィルタリングはプライバシー保護を効果的に行えません。フィルタリングルールの定期的な更新とカスタムホワイトリストの提供が必要なバランス措置です。

混合戦略はより良いプライバシー保護効果を提供できます。例えば、暗号化DNSとQNAME最小化を組み合わせ、同時にDNSフィルタリングでトラッカーをブロックします。ただし、過剰なプライバシー保護措置はネットワークパフォーマンスと互換性に影響を与える可能性があるため、実際のニーズに基づいて調整する必要があります。

リスクと移行

DNSプライバシー保護措置の導入には様々なリスクと課題が伴う可能性があり、対応する移行戦略と緊急対応計画を策定する必要があります。

互換性リスクが主な考慮要素の一つです。暗号化DNSは一部のネットワーク環境でブロックされる可能性があり、特に企業ネットワークや制限の厳しい地域では注意が必要です。フォールバックメカニズムが極めて重要で、暗号化DNSが利用できない場合、システムは優雅に従来のDNSにフォールバックできる必要があり、同時にプライバシー漏洩を可能な限り抑える必要があります。

パフォーマンスへの影響を慎重に評価する必要があります。暗号化DNSはクエリ遅延を増加させる可能性があり、特に初回接続時のハンドシェイクオーバーヘッドが顕著です。キャッシュ最適化と接続再利用により一部のパフォーマンス問題を緩和できます。暗号化DNSサービスを選択する際は、ネットワーク遅延と応答時間を考慮し、地理的に遠すぎるサーバーを避けるべきです。

コンプライアンス要件は企業が導入時に考慮しなければならない要素です。一部の地域ではデータ保存や監視の要件があり、プライバシー保護措置と矛盾する可能性があります。導入前に現地の規制要件を理解し、プライバシー保護とコンプライアンスのバランスを見つける必要があります。

段階的なグレーリリース導入はリスク低減の有効な戦略です。まずテスト環境で方案の実現可能性を検証し、次に小規模ユーザーグループに段階的に拡大し、最後に全面導入します。クエリ成功率、遅延変化、エラー率などの主要指標を監視し、設定を適宜調整します。

ユーザー教育とトレーニングも見逃せません。多くのユーザーはDNSプライバシーの重要性を理解していない可能性があるため、明確な説明と設定ガイドを提供する必要があります。特に企業環境では、IT部門が従業員にプライバシー保護措置の目的と使用方法を説明すべきです。

シナリオ別推奨事項

異なる使用シナリオではDNSプライバシー保護のニーズと実施戦略がそれぞれ特徴があり、具体的な環境に応じた方案を策定する必要があります。

家庭ネットワークシナリオでは、ルーターレベルでの導入が良い選択です。暗号化DNSをサポートするルーターはIoTデバイスやスマートホーム製品を含む家庭ネットワーク全体に保護を提供できます。ペアレンタルコントロールや悪意のあるウェブサイトフィルタリングをサポートするなど、家庭向けのDNSサービスを選択することで、プライバシー保護と追加のセキュリティ機能を両立できます。

モバイルワークシナリオでは、ネットワーク切り替えとバッテリー消費に特に注意が必要です。接続マイグレーションをサポートするDoQサービスを選択することで、モバイルネットワーク切り替え時の安定性を向上させます。同時に、頻繁なDNSクエリと暗号化操作による過度のバッテリー消費を避けるため、バッテリー最適化戦略を考慮します。

企業環境ではプライバシー保護とネットワーク管理のバランスを見つける必要があります。一般従業員のトラフィックにはプライバシー保護を提供し、特定の業務トラフィックには管理要件を満たすため可視性を維持する混合方案が必要になる場合があります。DNSフィルタリングは企業のセキュリティポリシーと組み合わせ、悪意のあるドメインとデータ漏洩リスクを阻止できます。

高いプライバシーが必要なシナリオ（ジャーナリスト、弁護士、医療従事者など）では、複数の保護措置を組み合わせる必要があるかもしれません。暗号化DNS、VPN、Torなどのツールを組み合わせ、多層的なプライバシー保護を実現します。同時に、クエリログを一切記録しない匿名再帰的リゾルバの使用を検討できます。

クロスボーダーネットワークシナリオでは、ネットワーク検閲と地域制限に特に注意が必要です。一部の暗号化DNSサービスは特定地域で利用できない可能性があるため、複数の代替方案を準備する必要があります。現地のネットワーク環境の特徴を理解し、現地条件に最も適したプライバシー保護戦略を選択します。

開発テスト環境では最新のプライバシー保護技術を試すことができます。実験的なDoQ実装やカスタム難読化方案などです。これらの環境は比較的制御しやすく、新技術の影響と互換性をテストするのに適しており、本番環境導入のための経験を蓄積できます。

FAQと参考資料

よくある質問

Q: 暗号化DNSはユーザープロファイリング構築を完全に防止しますか？
A: 暗号化DNSはネットワークレイヤーでの中間者によるDNSクエリ内容の盗聴を防止できますが、再帰的リゾルバは依然として完全なクエリ記録を確認できます。ログを記録しないと約束する信頼できるサービスプロバイダを選択することが重要です。同時に、ブラウザのトラッキング防止機能などの他のプライバシー保護措置と組み合わせることで、より包括的な保護を提供できます。

Q: QNAME最小化はDNS解決パフォーマンスに影響しますか？
A: QNAME最小化はクエリ遅延を増加させる可能性があります。上流サーバーへの複数回のクエリ送信が必要なためです。現代の再帰的リゾルバは通常、インテリジェントなキャッシュと並列クエリによってパフォーマンスを最適化しており、実際の影響は予想より小さいことが多いです。ほとんどのユーザーにとって、プライバシー上の利益はわずかなパフォーマンス低下をはるかに上回ります。

Q: DNSプライバシー保護が有効かどうかをどう確認しますか？
A: dnsleaktest.comやdnsprivacy.orgが提供する検出サービスなどの専用テストツールを使用し、DNSクエリが暗号化チャネルを介して送信されているかどうかを検証できます。ネットワークパケットキャプチャツールを使用してDNSトラフィックが暗号化されているかどうかを確認することもできます。ただし、これらのテストは技術的な実装のみを検証でき、サービスプロバイダの実際のプライバシーポリシー遵守状況は評価できないことに注意が必要です。

Q: 企業ネットワークでプライバシー保護と管理ニーズをどうバランスさせますか？
A: 企業は階層化戦略を採用できます。一般的なインターネットアクセスにはプライバシー保護を提供し、内部業務トラフィックには必要な監視能力を維持します。ドメイン名やユーザーグループに基づいて異なるDNSポリシーを適用する分流技術をサポートするソリューションを使用します。明確なプライバシーポリシーと従業員とのコミュニケーションも重要です。

Q: 暗号化DNSはネットワーク事業者によってブロックされますか？
A: 一部のネットワーク環境では暗号化DNSトラフィックを制限またはブロックする可能性があり、特に非標準ポートを使用するDoTが該当します。DoHは標準のHTTPSポート443を使用するため、通常識別・ブロックされにくくなっています。このような状況では、複数の暗号化DNS方案の組み合わせを検討するか、VPNなどの他のプライバシーツールと組み合わせることができます。

参考資料

RFC文書:

RFC7858: Specification for DNS over Transport Layer Security (TLS)
RFC8484: DNS Queries over HTTPS (DoH)
RFC7816: DNS Query Name Minimisation to Improve Privacy
RFC9250: DNS over Dedicated QUIC Connections

ツールとサービス:

Cloudflare DNS: 1.1.1.1（DoH/DoTをサポート、プライバシー保護を約束）
Quad9: 9.9.9.9（DoH/DoTをサポート、悪意のあるドメインをブロック）
NextDNS: カスタマイズ可能なプライバシーDNSサービス
Stubby: オープンソースのDoTクライアント

テストと検証:

dnsleaktest.com: DNS漏洩テスト
dnsprivacy.org: DNSプライバシーテストツール
browserleaks.com/dns: ブラウザDNS設定検出

さらなる読書:

本稿はDNSの基本原理から出発し、ユーザープロファイリング構築プロセスにおけるプライバシーリスクを分析し、暗号化伝送、クエリ難読化、ソース制御などの保護戦略を体系的に紹介しました。実際の導入では、具体的なシナリオとニーズに基づいて適切な方案を選択し、プライバシー保護、パフォーマンス影響、互換性要件のバランスを取る必要があります。DNSプライバシー保護は継続的に発展する分野であり、技術の進化と規制の変化に伴い、保護戦略も絶えず調整・改善する必要があります。

深掘り解説：寧屏DNSプロキシ機能、ネットワーク制限を突破してプライバシー保護を実現

寧屏DNSプロキシ機能を詳細に紹介し、アップストリームDNSアクセス制限の問題を解決し、より安全なネットワークプライバシー保護を実現。完全な設定ガイドとベストプラクティスを含む。

2025 August 25

🌐 DNSプロキシ機能の深掘り解説

今日の複雑なネットワーク環境では、従来のDNSサービスは多くの制限に直面しています。寧屏DNSサービスは、アップストリームDNSプロキシ機能を完全サポートし、ユーザーにより柔軟で安全なネットワークアクセス体験を提供します。

なぜDNSプロキシが必要なのか？

特定のネットワーク環境（企業ネットワーク、キャンパスネットワーク、または特定地域のネットワーク）では、アップストリームDNSサーバーへの直接アクセスは次のような問題が発生する可能性があります。

ネットワーク制限：一部のDNSサーバー（1.1.1.1、8.8.8.8など）がファイアウォールによってブロックされる
ISPによる干渉：プロバイダーがDNSクエリをリダイレクトまたは汚染する可能性がある
地理的制限：特定地域のDNSサービスへのアクセスが制限される
プライバシー保護：プロキシを通じて実IPアドレスを隠す必要がある

🚀 コア機能の特徴

DoHおよびDoTプロキシのサポート

寧屏DNSサービスは、AdGuard Homeをベースに深くカスタマイズし、次の重要な機能を新たに追加しました。

スマートDNSスプリット
- ネットワーク環境を自動検出
- ルールに基づいて直結またはプロキシ経路をスマートに選択
- カスタムスプリット設定ファイルをサポート
プロキシプロトコルの包括的サポート
- HTTPプロキシ (http_proxy)
- HTTPSプロキシ (https_proxy)
- SOCKS5プロキシ (socks5)
安全な暗号化転送
- DoH（DNS over HTTPS）プロキシサポート
- DoT（DNS over TLS）プロキシサポート
- エンドツーエンドの暗号化によるプライバシー保護

📋 詳細設定ガイド

環境変数の設定

DNSプロキシ機能の設定は非常に簡単で、システム環境に対応するプロキシ変数を設定するだけです。

Linux/macOSの設定

# 一時的な設定（現在のセッション）
export http_proxy="http://proxy.example.com:8080"
export https_proxy="http://proxy.example.com:8080"
export ALL_PROXY="socks5://[username:password@]proxyhost:port"

# 永続的な設定（~/.bashrc または ~/.zshrcに追加）
echo 'export http_proxy="http://proxy.example.com:8080"' >> ~/.bashrc
echo 'export https_proxy="http://proxy.example.com:8080"' >> ~/.bashrc
echo 'export ALL_PROXY="socks5://[username:password@]proxyhost:port"' >> ~/.bashrc
source ~/.bashrc

Windowsの設定

# コマンドプロンプト
set http_proxy=http://proxy.example.com:8080
set https_proxy=http://proxy.example.com:8080

# PowerShell
$env:http_proxy="http://proxy.example.com:8080"
$env:https_proxy="http://proxy.example.com:8080"

Dockerコンテナの設定

version: '3.8'
services:
  nullprivate-dns:
    image: nullprivate/nullprivate:latest
    environment:
      - http_proxy=http://proxy.example.com:8080
      - https_proxy=http://proxy.example.com:8080
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
      - "443:443/tcp"

高度な設定オプション

認証プロキシの設定

プロキシサーバーが認証を必要とする場合、次の形式を使用できます。

export http_proxy="http://username:password@proxy.example.com:8080"
export https_proxy="https://username:password@proxy.example.com:8080"

特定ドメインの除外

一部のドメインはプロキシ経由でアクセスする必要がない場合、no_proxy変数を設定できます。

export no_proxy="localhost,127.0.0.1,.local"

🔧 実際のアプリケーションシナリオ

企業ネットワーク環境

企業ネットワークでは、外部DNSサーバーはしばしばファイアウォールによって制限されます。プロキシを設定することで、次のことが可能です。

企業ファイアウォールの制限を突破
ブロックされたDNSサービスにアクセス
安全な外部ネットワークアクセスを実現

キャンパスネットワークの最適化

キャンパスネットワークは通常DNSに対して厳格な制御を行っており、プロキシを設定することで、次のことが可能です。

DNS汚染およびハイジャックを回避
より高速なDNS解決速度を提供
学生のプライバシーと学習データを保護

家庭ネットワークの保護

家庭ユーザーはプロキシを通じて、次のことが可能です。

家庭の実IPアドレスを隠す
ISPによるインターネット行動の追跡を防止
より安全な子供のインターネット保護を実現

⚡ 技術的な優位性の比較

特徴	AdGuard Home	従来のDNS	寧屏DNSプロキシ
DoHプロキシサポート	❌	❌	✅
DoTプロキシサポート	❌	❌	✅
スマートスプリット	❌	❌	✅
設定の複雑さ	中程度	簡単	簡単
ネットワーク適応性	普通	普通	優秀
プライバシー保護	良好	普通	優秀

🛠️ トラブルシューティングガイド

よくある問題と解決策

Q: プロキシ設定後にDNS解決が失敗する

考えられる原因：

プロキシサーバーにアクセスできない
プロキシサーバーがHTTPSをサポートしていない
ネットワーク接続の問題

解決策：

プロキシサーバーの状態を確認：curl -x http://proxy.example.com:8080 https://www.google.com
プロキシ設定を検証：env | grep proxy
寧屏サービスを再起動

Q: プロキシ接続がタイムアウトする

考えられる原因：

プロキシサーバーの応答が遅い
ネットワーク遅延が高い
プロキシサーバーの負荷が高い

解決策：

プロキシサーバーを変更
DNSタイムアウト設定を調整
複数のプロキシサーバーを設定して負荷分散を実現

Q: 特定ドメインの解決が異常

考えられる原因：

ドメインがプロキシサーバーのブラックリストに含まれている
DNSキャッシュの問題
プロキシサーバーのDNS設定の問題

解決策：

DNSキャッシュをクリア
プロキシサーバーの設定を確認
直結モードを試す

📊 パフォーマンス監視

プロキシを設定した後、次の方法でパフォーマンスを監視できます。

DNSクエリ遅延：DNS解決速度が改善されているかを観察
成功率統計：プロキシ接続の成功率を監視
トラフィック分析：プロキシトラフィックの使用状況を確認
エラーログ：定期的にシステムログ内のエラー情報を確認

🔒 セキュリティに関する注意事項

信頼できるプロキシを選択：信頼できるプロキシサービスプロバイダーを使用
暗号化を有効にする：HTTPSプロキシを優先的に使用
定期的な交換：セキュリティを向上させるために定期的にプロキシサーバーを変更
トラフィックの監視：定期的にプロキシトラフィックの使用状況を確認
設定の更新：ネットワークの変化に対応してタイムリーにプロキシ設定を更新

🎯 まとめと展望

寧屏DNSプロキシ機能の登場により、ユーザーは複雑なネットワーク環境でDNSサービスをより柔軟かつ安全に使用できるようになりました。簡単な設定だけで、ネットワーク制限を突破し、より優れたDNS解決サービスとプライバシー保護を実現できます。

将来の計画

SOCKS5プロトコルのサポート
スマートプロキシ選択アルゴリズムの追加
グラフィカル設定インターフェースの提供
マルチプロキシ負荷分散のサポート

🚀 今すぐ体験

寧屏DNSプロキシ機能を体験したいユーザーは、次の手順で行えます。

GitHubリポジトリにアクセス
ドキュメントに従ってデプロイ
プロキシ環境変数を設定
より安全で自由なネットワーク体験を楽しむ

AdGuardPrivateの名称変更のお知らせ

商標使用許諾の問題により、当サービスは正式に「NullPrivate」へと名称を変更いたします。既存ユーザーのサービスには影響はなく、ウェブサイトおよび連絡先のみ移行いたします。

2025 August 11

このたび、AdGuard公式より「AdGuard」は登録商標であり、許可なく当該名称を使用することはできない、プレフィックスやサフィックスを付加する場合でも侵害にあたる可能性がある旨の通知を受領いたしました。法的リスクを回避するため、当サービスは正式に「NullPrivate」へと名称を変更いたしました。

既存のユーザー様におかれましては、サービスに一切の影響はございません。引き続きadguardprivate.comドメインにてサービスを提供いたしますが、公式ウェブサイトおよび連絡先のみ移行いたします。

新規ユーザー様にNullPrivateがAdGuardと関係あると誤解されることを防ぐため、ご説明いたします。当社のソフトウェア製品はAdGuardHomeをforkし、新機能を追加して開発されました。すべてのコードはオープンソース化されており、同じGPLv3ライセンスに準拠しています。

コードリポジトリ：https://github.com/nullprivate/nullprivate

ユーザー様はコードをご自身で確認し、セルフホスティングを実現できます。同時に、当社が提供するSaaS版は、よりお求めやすい価格とより安定したサービスを継続して提供してまいります。

これまでのご支援に心より感謝申し上げます。当サービスが今後も皆様に価値をお届けできることを願っております！

DDNS機能を追加しました

本記事では新規追加されたDDNS機能について、使用方法・機能特徴・従来型DDNSとの違いを詳細に解説します。NullPrivateまたはAdGuardHomeを利用することで、ユーザーはドメイン購入不要で簡単にプライベート動的DNS（DDNS）を設定可能。マルチプラットフォーム対応と複数認証方式をサポートしています。

2025 July 21

NullPrivateサービスをお持ちの場合、DDNS機能がご利用いただけます。

概要

NullPrivateがDDNSスクリプトをオープンソース化しました。この動的DNS（DDNS）は、ドメインを購入することなくプライベート動的DNSを迅速に設定するシンプルな方法を提供します。本DDNSスクリプトはnullprivate.com向けに特別開発され、NullPrivateのコア機能を活用することでシームレスな実装が可能です。

使用方法

nullprivate-ddns

NullPrivateがデプロイ済みで稼働中であることを確認
DNS書き換え設定に移動し、DDNSスクリプトをダウンロード
スクリプトを実行

Windows

Set-ExecutionPolicy Bypass -Scope Process
./ddns-script.ps1

Linux/macOS

chmod +x ddns-script.sh
./ddns-script.sh

機能特徴

迅速で簡単な設定: 数ステップで構成完了
NullPrivateを活用したDDNS機能: コア機能を介してDDNSを実現
マルチプラットフォーム対応: WindowsおよびUnix系システムをサポート
複数認証オプション: Cookie認証（安全性高・有効期限あり）またはユーザー名/パスワード認証（持続性高・安全性低）をサポート

従来型DDNSとの違い

従来型DDNSと比較し、このプライベートDDNSには以下の優位性があります：

キャッシュ時間なし: 変更が即時反映（DNSキャッシュ待機不要）
DNS伝播遅延なし: 更新が即時利用可能
ドメイン購入不要: 疑似ドメインでアクセス可能
プライバシー保護: プライベートDNSサービスに接続したユーザーのみDNS解決可能

クイックスタートガイド

NullPrivateがデプロイ済みで稼働中であることを確認
Windows用（win/ddns.ps1）またはUnix系システム用（unix/ddns.sh）スクリプトの指示に従いプライベートDDNSを設定

オープンソースリポジトリ: https://github.com/NullPrivate/nullprivate-ddns

ECS をより良くサポート

本記事では、AdGuard Home で推奨される DNS 設定、特に EDNS クライアント・サブネット (ECS) の役割・仕組み・プライバシーへの影響・代替案を詳しく解説し、DNS 解決体験を最適化するための手助けをします。

2025 March 10

最適な DNS 解決体験を得るため、いくつかの推奨設定をプリセットしていますが、ユーザーが注意すべき設定がまだ残っています。それは「EDNS クライアント・サブネット」です。

EDNS クライアント・サブネット (ECS) を有効にする

より良い体験を得るために、DNS サーバーが地理的に最も近いサーバー IP を返してほしい場合があります。EDNS クライアント・サブネット (ECS) はそれを実現します。ECS を使うと、クライアントの地理的位置情報を含む IP サブネットを DNS サーバーへ送信でき、サーバーは最適な DNS 解決結果を返せます。

仕組み:

ECS を有効にすると、DNS リゾルバー（例：AdGuard Home）はクライアント IP アドレスの一部（通常は上位 24 ビットでクライアントのサブネットを示す）を DNS クエリに含め、上流 DNS サーバーへ送信します。上流 DNS サーバーはこのサブネット情報に基づき、その地域に最適なサーバー IP アドレスを返します。

sequenceDiagram
    participant Client
    participant DNS Resolver
    participant Upstream DNS Server

    Client->>DNS Resolver: DNS Query
    DNS Resolver->>Upstream DNS Server: DNS Query with ECS (Client Subnet)
    Upstream DNS Server->>DNS Resolver: DNS Response (Geo-localized IP)
    DNS Resolver->>Client: DNS Response (Geo-localized IP)

プライバシーに関する注意:

ECS を有効にすると、DNS 解決の精度と速度は向上しますが、同時に一定のプライバシー影響が生じる可能性があります。クライアント IP アドレスのサブネットを共有することで、おおよその地理的位置情報が上流 DNS サーバーに記録されることがあります。ご自身の状況に応じて、この機能を有効にするかどうかをご判断ください。

どう判断するか:

ECS を有効にすると、アクセス速度と精度のバランスを取れます。プライバシー保護を重視する場合は ECS を無効にすることもできますが、アクセス速度が低下する可能性があります。最適なアクセス体験を求める場合は ECS を有効にできますが、潜在的なプライバシー影響をご承知おきください。このプライバシー情報は DNS 上流側で収集されるものであり、本サービスはプライバシーポリシーに従い、一切の情報を収集・利用しません。

寧屏 - AdGuard Homeをベースにした強化版DNSサービス

寧屏はすぐ使えるプライバシー保護DNSサービスを提供し、広告フィルタリング、DoT、DoHなどの機能に対応。オリジナルのAdGuard Homeに加え、SSL証明書管理、セキュリティ機能の最適化、プロキシ機能などのエンタープライズ機能を追加

作成者 寧屏チーム | 2025 January 20

寧屏: プライバシー保護に特化したDNSサービス

公式サイトで詳細を確認: 寧屏

このプロジェクトはAdGuard Homeをベースにした二次開発であり、GPL 3.0オープンソースライセンスに準拠しています。

ソースコードはこちらで公開: GitHub - 寧屏/寧屏

機能強化

オリジナルのAdGuard Homeと比較して、以下の機能を追加しました：

📜 自動化SSL証明書管理
- 証明書の自動取得と更新
- ワイルドカード証明書設定に対応
🛡️ 強化されたセキュリティ機能
- スマートレート制限保護
- 中国本土向けアクセス体験の最適化
⚙️ 最適化されたシステム設定
- DHCPサービスを無効化し、DNS機能に特化
🔄 DDNSに対応
🌉 プロキシ機能に対応
- プロキシ経由での設定ファイルダウンロード
- DoH/DoTプロキシに対応
🚦 DNSルーティング機能に対応
🚫 アプリ依存防止リストに対応

ホスティングサービスの利点

私たちはプロフェッショナルなDNSホスティングサービスを提供し、以下の特徴を持っています：

🏢 Alibaba Cloud杭州ノードにデプロイ
🌐 包括的なプロトコルサポート
- IPv6サポート、主要IPv6上流への直接接続
- DoT (DNS over TLS)
- DoH (DNS over HTTPS)
- HTTP/3サポート、レイテンシーの大幅削減
📊 強力なルール管理
- サードパーティのホワイト/ブラックリストインポートに対応
- 100万ルールの容量
📝 充実したログと統計
- 72時間のクエリ履歴保持
- 24時間の詳細統計分析
⚖️ ロードバランシング
- マルチサーバー分散デプロイ
- スマートな負荷分散
💰 競争力のある価格

パフォーマンスと効果評価

DNSレベルの広告ブロックは独自の利点を持っています：

💪 利点
- 追加の電力消費ゼロ
- 全デバイスカバー
- デバイスのネットワークウェイクアップ頻度の削減
- 無効データ読み込みの削減
⚠️ 限界
- ブラウザプラグインと比較してブロック精度が低い
- MITMソリューションのフィルタリング効果には達しない

特にモバイルデバイスの使用シーンに適しており、プライバシーを保護しながらデバイスのバッテリー寿命も考慮できます。

HTTP/3プロトコルの完全サポート

NullPrivateはHTTP/3プロトコルを完全サポートし、ユーザーにより高速で安全なネットワーク体験を提供します

2025 January 15

NullPrivateはHTTP/3プロトコルを完全サポートしました。すべての既存ユーザーは追加設定なしで自動的にHTTP/3のパフォーマンス向上を享受できます。

重要な更新説明

iOSユーザー: DoHプロトコル経由で直接HTTP/3を使用可能になり、ネットワーク遅延がさらに低減
Androidユーザー: システム制限のため、現在はDoTプロトコルを継続使用。Googleの今後のバージョンアップで対応予定
パフォーマンス向上: 初回応答速度がHTTP/2と比較して顕著に向上、接続確立がより迅速に
インテリジェント切り替え: HTTP/3をサポートしないネットワーク環境では、システムが自動的にHTTP/2に切り替え、サービスの安定性を確保

h3のアクセス

HTTP/3技術詳細解説

HTTP/3はHTTPプロトコルの最新バージョンとして、Googleが開発したQUIC伝送プロトコルを基盤とし、多くの革新的な技術的優位性をもたらします：

コア特性

UDPベースのQUICプロトコル
- 接続確立時間の大幅短縮
- 改良された多重化機能
- よりスマートなパケットロス処理メカニズム
最適化されたパフォーマンス
- ゼロハンドシェイク遅延（0-RTT）
- 改良された輻輳制御
- 接続移行サポート
強化されたセキュリティ
- TLS 1.3の統合
- 暗号化されたハンドシェイクプロセス
- 中間者攻撃リスクの低減

接続確立プロセスの比較

応答時間比較

接続確立プロセス比較

使用上の推奨事項

クライアントがHTTP/3プロトコルをサポートしていることを確認
クライアントバージョンを最新に保つ
ネットワーク環境が制限されている場合、システムは自動的にHTTP/2を使用するようにダウングレード

注意事項

一部地域のネットワークではUDPトラフィックが制限され、HTTP/3のパフォーマンスに影響する可能性
異なるネットワーク環境ではパフォーマンスに差異が生じる場合あり
システムはネットワーク状況に基づき最適なプロトコルを自動選択

参考資料

カスタムクライアント名機能のリリース

NullPrivateがカスタムクライアント名機能をリリース。ユーザーが異なるデバイスのDNS設定を直感的に識別・管理できるようになり、管理体験が大幅に向上します。

2024 December 29

機能紹介

ユーザー体験向上のため、NullPrivateではカスタムクライアント名機能をサポートしました。この機能により、異なるデバイスに独自の識別名を設定でき、デバイス管理がより直感的で便利になります。

クライアント管理画面

設定ガイド

デバイスタイプによって設定方法が若干異なります：

Androidデバイス

ドメイン名の前にカスタムプレフィックスを追加するだけです。形式は以下の通り：

{デバイス名}.{元のドメイン名}

例：xiaomi-15pro.xxxxxxxx.nullprivate.com

iOSデバイス

「設定ガイド」ページに移動
「クライアントID」入力欄にカスタム名を入力
新しい設定ファイルをダウンロードして適用

iOS設定画面

ブラウザ設定（DoH）

既存のDoHアドレスの後にカスタム識別子を追加：

元の形式：

https://xxxxxxxx.nullprivate.com/dns-query

新しい形式：

https://xxxxxxxx.nullprivate.com/dns-query/{デバイス識別子}

例：https://xxxxxxxx.nullprivate.com/dns-query/pc1-browser

ブラウザ設定例

使用上の推奨事項

デバイス名は意味のある識別子（デバイスモデル、場所、用途など）を使用することを推奨
特殊文字の使用を避け、英数字とハイフンの使用を推奨
後続の管理のために命名規則を統一

注意事項

カスタム名は表示にのみ影響し、サービス性能には影響しません
名前変更後は設定を再適用する必要があります
将来の参照のために各デバイスの設定情報を保存することを推奨

広告ブロックの必要性：デジタル時代の注意力とプライバシーを守る

現代の広告エコシステムの仕組みを深く分析し、ユーザーのプライバシーと注意力を守るために広告ブロックがいかに重要であるかを考察

2024 December 04

現代の広告エコシステムを解き明かす

広告主の収益モデル

現代の広告システムは、複雑な利益の連鎖の上に構築されています：

広告主はメディアプラットフォームを通じて広告主とユーザーをつなぐ
収入源は広告主の広告費であり、ユーザーではない
目標は「コンバージョン率」を最大化すること——広告視聴者を有料顧客に変換すること

コンバージョン率の戦い

この注意力の争奪戦では：

高いコンバージョン率はより高い広告単価を意味する
広告配信の効率は収益に直接影響する
「パーソナライズ配信」はコンバージョン向上の中核戦略となる

パーソナライズ広告の真実

データ収集の深さ

現代の広告システムは複数のチャネルを通じてユーザー情報を収集します：

デバイス識別情報とOSデータ
クロスプラットフォームの行動追跡
ソーシャル関係ネットワーク分析
消費習慣プロファイリング

精度の高い配信の罠

便利そうなパーソナライズ配信は、実はリスクを秘めています：

認知バイアスを利用して需要を創造する
ユーザーの潜在的な不安を増幅させる
偽の緊急性を生み出す

広告による注意力の侵食

注意力経済の代償

頻繁な中断は作業効率を破壊する
意思決定判断能力を妨げる
認知的負担を増加させる
真のニーズの境界を曖昧にする

広告戦略の進化

現代の広告は、単なる情報伝達から進化し：

強制的な記憶への植え付け
情緒的刺激
不安マーケティング
社会的プレッシャー

自己を守るための戦略

中核となる保護策

プライバシー保護を最優先に
- アプリの権限を制限する
- データ共有を制御する
- プライバシー保護ツールを使用する
注意力管理
- 集中時間を設定する
- 情報フィルタリングメカニズムを構築する
- 能動的に情報を得る習慣を身につける
消費意思決定の制御
- ニーズ評価システムを構築する
- 購入意思決定を遅延させる
- 理性的な判断を保つ

技術的サポート：サイバー城府

このデータドリブンの時代において、「サイバー城府」——すなわちデジタル世界における慎重さと知恵——を保つことは極めて重要です。これには以下が含まれます：

デジタルフットプリントの管理
個人プライバシーの保護
情報フローの制御

ソリューション

「寧屏」は包括的な保護ソリューションとして、広告ブロックを提供するだけでなく、より重要なのはユーザーに以下を支援することです：

個人プライバシーの保護
ブラウジング体験の最適化
注意力分散の削減
制御可能な情報環境の提供

私たち自身のデジタルライフを再びコントロールし、広告の嫌がらせを拒否することから始めましょう。

サービスリソース最適化戦略説明

NullPrivate サービスのリソース最適化戦略を詳細に説明し、フィルター更新メカニズムの改善、並列リクエスト最適化の提案、およびサードパーティリストの使用規範を含むことで、より安定した信頼できるサービス体験を提供します。

2024 December 02

背景説明

ユーザー数の増加と機能要件の向上に伴い、一部の高リソース消費設定オプションがサービスの不安定化を招く可能性があることを観察しました。サービス品質を確保するため、詳細な分析を行い、対応する最適化プランを策定しました。

リソース最適化戦略

1. フィルター更新メカニズムの最適化

現状分析

一部のユーザーは毎時更新フィルターを設定
毎回、完全なダウンロード-解析-重複除去プロセスが必要
国際帯域幅の制限により更新に時間がかかる
サーバーリソースが持続的に高負荷

最適化案

更新間隔を最短72時間に調整します。理由は以下の通りです：

ほとんどのフィルターリストの更新周期は24-72時間
無効なリソース消費を削減
サービスの安定性を確保
帯域幅の使用効率を最適化

影響評価

ポジティブな影響
- サービス応答がより安定
- リソース使用がより合理的
- システム負荷の軽減
最小限の影響
- ルール更新は依然として合理的な周期で維持
- 保護効果に影響なし

2. 並列リクエスト戦略

現状

現在、ほとんどのユーザーは並列リクエスト機能を有効にしていますが、既存のアーキテクチャでは恩恵は限定的です：

アリババクラウズ上流サービスの遅延差は通常5ms以内
アリババクラウズパブリックサービスのリクエスト頻度制限をトリガーする可能性
不要なシステムオーバーヘッドの増加

使用推奨

ロードバランシングモードの使用を推奨
並列リクエストは以下のシナリオに適しています：
- 上流サービスの遅延差が顕著（>200ms）
- サービス品質が不安定な状況
- 国際アクセスシナリオ

注：現在のところ、並列リクエストによるレート制限の問題は確認されていないため、この機能は当面開放されたままです。

3. サードパーティリスト管理

セキュリティ考慮事項

システムの安定性を確保するため、一部のサードパーティリストサポートを一時的に無効化しています：

外部リストの規模は予測困難
リソース超過を引き起こす可能性
サービスの安定性を保証できない

今後の計画

より安全なサードパーティリスト管理ソリューションを研究中であり、将来的にこの機能を再開できるよう努めています。

ベーシック版メモリ上限調整

2024 November 29

一部のユーザー環境で頻繁な再起動が発生しており、ログを確認したところ、メモリ使用量が上限の300MBに達したため強制終了されていることが判明しました。

単一コンテナの上限を500MBに引き上げ、再起動問題を緩和します。

環境にログインや再起動の問題が発生した場合は、遠慮なくお問い合わせください。お客様の問題解決は私たちの責任です。

ヘルプが必要な場合

WeChat で連絡 private6688
またはメールを送信 service1@nullprivate.com
ご質問・問題を詳しく教えてください。できるだけ早くご返信いたします。

いつでもご支援いたします

NullPrivateは高品質なカスタマーサポートを提供し、すべてのユーザーの皆様が当社の製品を簡単にご利用いただけるよう努めています。どんな問題にお困りでも、どんなときでもお力になります。

2024 November 20

クイックスタートガイド

お客様がスムーズにサービスをご利用いただけるよう、詳細な利用ガイドをご用意しています。

きめ細やかなサポート

専属サポート

初期利用で困難を感じる新規ユーザーの方がいらっしゃることを把握しています。そのため：

製品ドキュメントの構造を継続的に改善
明確な設定ガイドをご提供
よくある質問をご用意

迅速なレスポンス

ユーザー・プライバシーを守るための登録不要制度を採用していますが、サービスの質に一切影響はありません。下記の方法でお問い合わせいただけます：

ヘルプが必要な場合

WeChat で連絡 private6688
またはメールを送信 service1@nullprivate.com
ご質問・問題を詳しく教えてください。できるだけ早くご返信いたします。

専用リンクの設定方法

寧屏プライベートサービス設定ガイド：専用リンクの設定方法を詳しく解説し、Nginxリバースプロキシ設定も含む。プライベートサービスによりフルバックグラウンド管理権限を得て、パーソナライズされた広告ブロックとプライバシー保護を実現する。

2024 October 29

一部の有料AdGuardHomeサービスでは、専用リンクを提供するが、ユーザーはバックグラウンド管理にアクセスできず、管理者がルールを代行管理する。

これは、プライベートバックグラウンド管理機能が提供されていないことを示しており、ドメインのリバースプロキシによってサービスを実現しているだけで、コストは比較的低い。

サーバーを1台レンタルし、AdGuardHomeサービスを実行し、Nginxリバースプロキシを設定して、この機能を実現する必要がある。

サービスリンク5r69hxdx9onl70hp.example.comを例に、Nginxの主要な設定は以下の通り：

http {
  server {
    listen 1080;
    server_name 5r69hxdx9onl70hp.example.com;
    location / {
      proxy_pass http://worker.example.com:5002;
      proxy_set_header Host $http_host;
    }
  }
  server {
    listen 1443 ssl;
    server_name 5r69hxdx9onl70hp.example.com;
    ssl_certificate /app/data/certs/5r69hxdx9onl70hp/fullchain.pem;
    ssl_certificate_key /app/data/certs/5r69hxdx9onl70hp/privkey.pem;
    location / {
      proxy_pass https://worker.example.com:5003;
      proxy_set_header Host $http_host;
    }
  }
}
stream {
  ssl_protocols TLSv1.2 TLSv1.3 SSLv3;
  map $ssl_preread_server_name $targetBackend {
    5r69hxdx9onl70hp.example.com worker.internal.com:5004;
  }
  server {
    listen 1853;
    proxy_pass $targetBackend;
    ssl_preread on;
  }
}

各有料ユーザーは、同様のNginx設定を1つ追加するだけで、ドメイン解決でサーバーを指す。ユーザーが多く、単一アプリケーションサービスの負荷が高くなった場合、異なるバックエンドにプロキシすることができる。

このようなサービスでは、真のパーソナライゼーションは実現できない。ユーザーはバックグラウンドにアクセスして初めて自分のインターネットデータを完全に把握できる。これこそが私たちのプライベートサービスの利点であり、1人のユーザーがサービスを真に占有し、NullPrivateの全機能を使用できる。

フルアップグレード - 強化版広告ブロックルール

NullPrivate 新版ブロックルールを紹介。より包括的な広告フィルタリングとセキュリティ保護機能を提供しながら、優れた互換性も維持します

2024 October 28

ルール更新説明

より強力な広告ブロックをご要望のユーザー様に応え、フィルタリングルール戦略を全面的に最適化しました。新版ルールは、低誤ブロック率を維持しながら、広告フィルタリング効果を大幅に向上させています。このアップデートはユーザーフィードバックに基づいており、ウェブサイトへの正常なアクセスを確保した上で、より正確なブロックルールを追加しました。

ルールリスト概要

以下の専門ルールリストを整理しましたので、ご要望に応じてご選択ください。

基本保護ルール

カテゴリー	AdGuard	機能説明
広告ブロック	Link	各種広告サーバーおよび広告サイトを全面的にフィルタリング
トラッキング保護	Link	ユーザーの行動トラッキングや個人情報収集をブロック
リダイレクト保護	Link	悪意あるURLリダイレクトを防止

コンテンツフィルタリングルール

カテゴリー	AdGuard	説明
詐欺サイト	Link	ユーザーを欺く目的のサイトリスト
広告	Link	広告サーバーおよび広告サイト
暗号通貨	Link	暗号通貨およびマイニング関連サイト ^{正常な暗号通貨サイトに影響を与える可能性があります}
薬物	Link	違法薬物関連サイト _{アメリカにおいて違法に所持されている処方薬を含む}
全ルール	Link	すべての非テスト版リストのドメインを含む
Facebook	Link	Facebookおよび関連サービスをブロック
詐欺	Link	詐欺サイト
ギャンブル	Link	すべてのギャンブル関連サイト（合法・違法を問わず）
マルウェア	Link	既知のマルウェアホスティングサイト
フィッシング	Link	フィッシングに使用されるサイト
違法DL	Link	既知の違法ダウンロードサイト
ポルノ	Link	ポルノまたはポルノを宣伝するサイト
ランサムウェア	Link	既知のランサムウェアをホスティングまたは含むサイト
リダイレクト	Link	意図したサイトから他のサイトへリダイレクトするサイト
スキャム	Link	ユーザーを詐欺しようとするサイト
TikTok	Link	デバイスにコピー＆ペースト用
トレント	Link	トレントディレクトリ _{合法ソフトウェアDLに使用される合法トレントサイトをブロックする可能性があります}
トラッキング	Link	訪問者の情報をトラッキングおよび収集することを目的としたサイト

使用に関する推奨事項

段階的導入
- 基本保護ルールから開始することを推奨
- 実際のニーズに応じて他のルールを段階的に追加
- 定期的にルールリストをチェック・アップデート
パフォーマンス最適化
- 同時に多くのルールを有効にしないことを推奨
- 要件に最も関連性の高いルールを優先選択
- 未使用のルールは定期的に削除
トラブルシューティング
- 誤ブロックが発生した場合は、必ず記録しフィードバック
- 特定のルールを一時的に無効にしてテスト可能
- 必要に応じてカスタムホワイトリストを使用

注意事項

一部のルールは特定サイトへの正常なアクセスに影響を与える可能性があります
ルールアップデートは定期的にチェックすることを推奨
頻繁な誤ブロックが発生する場合は、お手数ですがご連絡ください

より柔軟な制御が必要なユーザー様には、プロフェッショナル版サービスをご用意しており、完全なカスタムルール設定をサポートしています。ご不明な点がございましたら、お気軽にお問い合わせください。

ヘルプが必要な場合

WeChat で連絡 private6688
またはメールを送信 service1@nullprivate.com
ご質問・問題を詳しく教えてください。できるだけ早くご返信いたします。

トライアル版サービス詳細

寧屏トライアル版サービス：広告ブロック、依存防止、プライバシー保護のフル機能をゼロリスクで体験。カスタムルール、デバイス管理に対応し、全機能のトライアルでサービス価値をご評価いただけます。

2024 October 28

カスタム広告フィルタリングルールに特化したサービスプロバイダーとして、私たちはユーザーがサービスを選択する際のご検討を深く理解しています。サービスコストは高いものの、私たちは常にユーザーに最大限のカスタマイズ柔軟性を提供することを堅持しています。

私たちのサービスの価値を十分にご理解いただけるよう、特別なトライアルプランをご用意しました。このバージョンにはすべての高機能が含まれており、正式サービスと完全に同等で、カスタマイズフィルタリングの独自の優位性をゼロリスクで体験できます。

トライアル説明：

特別価格は初回ご利用の場合のみ適用されます
継続ご利用の場合は正式サービスプランをご選択ください
アカウントレス設計のため、トライアル版を繰り返しご購入いただけます
新規ご購入のたびに新しいサービスインスタンスが生成されます
継続ご利用時は元のインスタンスのすべての設定を保持できます

この優れたサービスをぜひご体験ください。ご利用中に何かご不明な点がございましたら、カスタマーサポートチームがいつでも専門的なサポートをご提供いたします。

ヘルプが必要な場合

WeChat で連絡 private6688
またはメールを送信 service1@nullprivate.com
ご質問・問題を詳しく教えてください。できるだけ早くご返信いたします。