DNSとあなたのCatoアカウントに関するベストプラクティス

異なる物理的な場所にあるサイトの場合、異なるサイトごとに異なる内部DNSサーバーを設定することで、より良いパフォーマンスを達成できます。 また、CatoのDNSサービスはCato Cloud内のグローバルPoPロケーションを利用して、ホストに迅速でグローバルなDNS解決を提供し、DNSのレイテンシーを大幅に削減できます。 PoPはキャッシュ内にDNS応答を保存し、将来のDNS要求が迅速に処理されるようにします。 Cato Cloudに接続してCatoのDNSサービスを使用するホストは、接続されているPoP（通常最も近いPoP）からDNS応答を取得します。 したがって、DNS応答時間は非常に速く、DNSレイテンシーを減少させます。

CatoのDNSサーバーを使用し、Cato Cloud内のグローバルPoPロケーションの利点を得ることをお勧めします。

ローカルDNSサーバーが必要な場合、サイトに物理的に近いローカルサーバーを設定できます。 例えば、ニューヨークに１つのサイト、シンガポールに１つのサイトがある場合、それぞれのサイトに異なるローカルDNSサーバーを使用できます。これにより、シンガポールのDNSサーバーは、接続されているクライアントからのDNSリクエストのみを解決します。 ニューヨークのサイトに接続しているクライアントはクエリを解決するためにシンガポールのサーバーにDNSリクエストを送る必要はありません。 これはより効率的で、ネットワークのパフォーマンスを向上させます。

サイトのためにカスタムDNSサーバーを定義する方法について、さらに詳しくはDNS設定の構成を参照してください。

Catoは冗長性のために２つの異なるDNSサーバーの設定を推奨します。 CatoのデフォルトDNSサーバー（内部DNSクエリの場合10.254.254.1またはx.y.z3）をプライマリとして設定し、信頼できるパブリックDNSサーバーをセカンダリDNSサーバーとして設定してください。 信頼できるDNSサーバーについての詳細は、信頼できるDNSサーバーの使用を参照してください。 プライマリDNSサーバーが利用できない場合、Catoはクエリを解決するためにセカンダリDNSサーバーを使用します。 内部DNSサーバーを使用している場合、内部ドメインを解決するためにDNSフォワーディングを設定してください。

macOSユーザーの場合、DoHまたはDoTをサポートしないプライマリ/セカンダリDNSサーバー (例えば、10.254.254.1や内部DNSサーバー) のみを定義することを推奨します。 macOS 13 Venturaから、オペレーティングシステムはDNSクエリを解決するためにDoHまたはDoT（Catoのインスペクションではサポートされていません）を優先し、これによりCato DNSフォワーディングが破損する可能性があります。 詳細については、Catoを介して内部リソースにアクセスできないmacOS Venturaユーザーを参照してください。

リモートユーザーはサイトを介さず、直接Cato Cloudのポップに接続します。 したがって、DNS設定が正しく構成されていない場合、リモートユーザーは接続の問題を経験したり、内部リソースにアクセスできなかったりする可能性があります。 例えば、リモートユーザーではなくサイト用にDNS設定を構成する場合、リモートユーザーはドメイン内のこれらの内部リソースにアクセスできません。 クライアントがサイトに接続されていないため、DNSサーバーはクライアントのDNSクエリを解決できません。 このため、この接続性を許可するためにクライアント用のDNS設定を構成する必要があります。

アカウントDNS設定はすべてのサイトとリモートユーザーに適用されます。 リモートユーザー用に特定のDNS要件がある場合は、DNSポリシーを有効化してください。

カトは、ベストプラクティスとして企業資産を保護し、内部DNSサーバーへのアクセスを制限することを推奨しています。 例えば、ゲストネットワークに接続する人々がDNSクエリを解決するためにパブリックDNSサーバーのみを使用するように定義します。 ゲストネットワーク用に別のVLANを作成し、このネットワークをゲストユーザーのグループに割り当てます。 その後、このグループのDNS設定をパブリックの信頼できないDNSサーバーのみで構成します。 信頼できるネットワークの詳細については、信頼できるDNSサーバーを使用を参照してください。

これを行うには：

CatoのDNS フォワーディング機能を使用すると、ネットワーク内のローカルドメインへの接続性を実現できます。

リモートユーザーは通常、サイトに接続するのではなく、直接Catoクラウドに接続します。 これは、ローカルドメインのDNSクエリを解決するDNSサーバーが存在しないことを意味します。 これらのクエリを関連する内部DNSサーバーに転送するためにDNS フォワーディングルールを使用することをお勧めします。 サーバーがクエリを解決し、SDPユーザーが企業の内部リソースに接続できるようにします。

DNS フォワーディングは、信頼されたDNSサーバー（アカウントに設定されたDNSサーバーは信頼と見なされます）に送られるDNSリクエストにのみ適用されます。

サイトまたはユーザー/ユーザーグループのためにカスタムDNS設定を設定できます。 カスタムDNS設定はアカウントレベルのDNS設定を優先します。DNSフォワードを含む。 しかし、DNS フォワーディングが信頼されたDNSサーバーまたはアカウント用に設定されたDNSサーバーへのリクエストを転送するように設定されている場合、アカウントレベルのDNS設定が使用されます。

注意：

DNSに基づくネットワークルールとファイアウォールルール（例: TLD、FQDN、アプリケーション）の場合、DNSトラフィックは信頼されているかアカウント用に定義されたDNSサーバーを使用する必要があります。 そうでない場合、これらのDNSに基づくルールはトラフィックに適用されません。

内部DNSサーバーがある場合、DNSクエリをCato信頼DNSサーバー（Cato DNSを含む）またはアカウント用に設定されたDNSサーバーに転送する必要があります。

オフクラウドトラフィック用のネットワークルールがある場合、DNSを含めないようにして、DNSクエリをCato信頼DNSサーバーに送信してください。