--- title: "DNSとCatoアカウントのベストプラクティス" slug: "best-practices-for-dns-and-your-cato-account" updated: 2026-07-30T01:20:12Z published: 2026-07-30T01:20:12Z canonical: "knowledge.catonetworks.com/best-practices-for-dns-and-your-cato-account" --- > ## Documentation Index > Fetch the complete documentation index at: https://knowledge.catonetworks.com/llms.txt > Use this file to discover all available pages before exploring further. # DNSとCatoアカウントのベストプラクティス この記事には、DNS設定とアカウントの構成に関するベストプラクティスと推奨事項が含まれています。 ## 内部DNSサーバーのネットワークパフォーマンス向上 異なる物理ロケーションにあるサイトでは、異なる内部DNSサーバーを構成することで、より良いパフォーマンスを達成することができます。 または、CatoのDNSサービスはCato Cloud内のグローバルPoPロケーションを使用して、ホストに迅速でグローバルなDNS解決を提供し、DNSレイテンシーを大幅に削減することができます。 PoPはDNS応答をキャッシュに保存し、将来のDNSリクエストがより迅速に処理されるようにします。 Cato Cloudへの接続し、CatoのDNSサービスを使用するホストは、通常最も近いPoPから**(**DNS応答を取得します。 したがって、DNS応答時間は非常に短縮され、DNSレイテンシーが軽減されます。 CatoのDNSサーバーを使用し、Cato Cloud内のグローバルPoPロケーションの利点を得ることをお勧めします。 ローカルDNSサーバーが必要な場合は、サイトに物理的に近いローカルDNSサーバーを構成します。 例えば、ニューヨークにサイトがあり、シンガポールにサイトがある場合、それぞれのサイトに異なるローカルDNSサーバーを使用して、シンガポールのサーバーがシンガポールサイトに接続しているクライアントからのDNSリクエストのみを解決するようにすることができます。 ニューヨークのサイトに接続しているクライアントは、DNSクエリを解決するためにシンガポールのサーバーに送信する必要はありません。 これによりより効率的になり、ネットワークのパフォーマンスが向上します。 サイトにカスタムDNSサーバーを定義する方法についての詳細は、[DNS設定の構成](/v1/docs/configuring-dns-settings)を参照してください。 ## フェイルオーバー用のプライマリおよびセカンダリDNSサーバーの設定 Catoは冗長性のために異なるDNSサーバーを2つ設定することを推奨しています。 プライマリとしてCatoのデフォルトDNSサーバー（10.254.254.1または内部DNSクエリのためのx.y.z3）を設定し、信頼できる公開DNSサーバーをセカンダリDNSサーバーとして設定します。 信頼できるDNSサーバーについての詳細は、[信頼できるDNSサーバーの使用](/v1/docs/using-trusted-dns-servers)を参照してください。 プライマリDNSサーバーが利用できない場合、CatoはセカンダリDNSサーバーを使用してクエリを解決します。 内部DNSサーバーを使用している場合は、DNSフォワーディングを設定して内部ドメインを解決します。 > [!NOTE] > 注： > > DoH （DNS over HTTPS）やDoT （DNS over TLS）はDNSフォワーディングをサポートしていません macOSユーザーにとって、10.254.254.1や内部DNSサーバーのようにDoHまたはDoTをサポートしないプライマリ/セカンダリDNSサーバーのみを定義することを推奨します。 macOS 13 VenturaからオペレーティングシステムはDNSクエリを解決する際にDoHまたはDoT（Catoによる検査でサポートされていません）を好むため、Cato DNSフォワーディングが壊れる可能性があります。 詳細については、[Cato経由で内部リソースにアクセスできないmacOS Venturaユーザー](/v1/docs/macos-ventura-and-ios-users-unable-to-reach-internal-resources-via-cato)を参照してください。 ## リモートユーザーにおけるDNSの操作 リモートユーザーは、サイトを介さずにCato Cloud内のPoPに直接接続します。 したがって、DNS設定が正しく構成されていない場合、リモートユーザーは接続の問題を経験したり、内部リソースにアクセスできなくなる可能性があります。 例えば、サイトのためにDNS設定を行いリモートユーザーのためでない場合、リモートユーザーはドメイン内のこれらの内部リソースにアクセスできません。 DNSサーバーは、クライアントがサイトに接続されていないため、DNSクエリを解決することができません。 このため、クライアントの接続性を許可するためにDNS設定を構成する必要があります。 アカウントDNS設定はすべてのサイトとリモートユーザーに適用されます。 リモートユーザー用の特定のDNS要件がある場合、[DNSポリシー](/v1/docs/centralized-management-of-sdp-user-dns-settings-with-the-dns-settings-policy)を有効にします。 ## 内部リソースをゲストのために保護する Catoは、コーポレート資産を保護し、ベストプラクティスとして内部DNSサーバーへのアクセスを制限することを推奨しています。 例えば、ゲストネットワークにアクセスする人には公開DNSサーバーのみを使用してDNSクエリを解決するように定義します。 ゲストネットワーク用に別のVLANを作成し、このネットワークをゲストユーザーのグループに割り当てます。 次に、このグループのDNS設定を公開の非信頼DNSサーバーのみで構成します。 信頼できるネットワークに関する詳細は、[信頼できるDNSサーバーの使用](/v1/docs/using-trusted-dns-servers)を参照してください。 これを行うには： 1. サイト用にゲストWiFiネットワークを作成 2. ゲストユーザーに対して[グループ](/v1/docs/working-with-cma-advanced-groups-and-groups)を作成し、このグループにゲストネットワークを割り当てます 3. グループのために非信頼サーバーを定義 ## DNSフォワーディングを使用したリモートユーザーの接続性 CatoのDNSフォワーディング機能により、ネットワーク内のローカルドメインへの接続性を確保できます。 リモートユーザーは通常サイトに接続せずに、Cato Cloudに直接接続します。 これは、ローカルドメインのDNSクエリを解決するためのDNSサーバーが存在しないことを意味します。 これらのクエリを関係するDNS内部サーバーに転送するためにDNSフォワーディングルールを使用することをお勧めします。 サーバーはクエリを解決し、SDPユーザーがコーポレートの内部リソースに接続できるようにします。 DNSフォワーディングは、信頼できるDNSサーバー（アカウントに構成されたDNSサーバーは信頼されていると見なされます）に送信されたDNSリクエストにのみ適用されます。 サイトまたは[ユーザー/ユーザーグループ](/v1/docs/centralized-management-of-sdp-user-dns-settings-with-the-dns-settings-policy)のためにカスタムDNS設定を構成できます。 カスタムDNS設定は、アカウントレベルのDNS設定よりも優先され、DNSフォワーディングを含みます。 ただし、DNSフォワーディングが信頼できるDNSサーバーまたはアカウントに構成されたDNSサーバーへのリクエストを転送するように構成されている場合、アカウントレベルのDNS設定が使用されます。 **注：** - Cato DNSサーバーを使用するアカウントでは、CatoはデフォルトのDNS設定でのみDNSクエリを転送できます - DNSフォワーディングは、UDPまたはTCPでDNSリクエストを処理できます - PoPはDNSフォワーディングリクエストをキャッシュに保存しません ## CatoへのDNSトラフィックのフォワーディング DNSベースのネットワークルールおよびファイアウォールルール（例えばTLD、FQDN、およびアプリケーション）のために、DNSトラフィックは信頼できるDNSサーバーまたはアカウントのために定義されたDNSサーバーを使用する必要があります。 それ以外の場合、これらのDNSベースのルールはトラフィックに適用されません。 内部DNSサーバーがある場合、Catoの信頼できるDNSサーバー（Cato DNSを含む）から内部DNSサーバーに[DNSクエリを転送](/v1/docs/defining-dns-forwarding-rules)する必要があります。 オフクラウドトラフィックのためのネットワークルールがある場合、それにDNSを含めないようにして、DNSクエリがCatoの信頼できるDNSサーバーに送信されるようにします。