IBM Cloud Docs
DNSの動作と解決ロジック

DNSの動作と解決ロジック

ドメイン・ネーム・システム(DNS)はウェブを支えるもので、バックグラウンドで透過的に働き、人間が読めるウェブサイト名をコンピュータが読める数値のIPアドレスに変換する。 これらのアドレスは、 インターネットのRFC1918ガイドライン( IPv4 )およびRFC4193ガイドライン( IPv6 )に従っています。 要するに、DNSサーバーは、 ibm.com のようなドメイン名と、それに対応するIPアドレスを一致させる。

この変換を行うために、DNSシステムはインターネット上で相互接続されたDNSサーバーのネットワークに問い合わせを行う。 このプロセスは、電話帳や地図を使って特定の場所を探すのと似ている。

ネーム・サーバー

ネームサーバーは、ディレクトリに対するクエリに応答するサービスを提供し、意味のあるテキストベースのウェブ名やホスト名をIPアドレスに変換する。

ネームサーバーの委任は、あるドメインのネームサーバーがサブドメインのレコードの要求を受け取り、要求者にそのサブドメインを担当する委任されたネームサーバーを紹介して応答するときに発生する。 これにより、 ibm.com のような大規模ドメインの分散管理が可能になる。

カスタム・ドメイン・ネーム・サーバーを使用すると、DNSプロバイダーのサーバーを、独自ドメインのカスタマイズされた参照名で使用することができます。 例えば、ネームサーバーをプロバイダーのデフォルトである ns1.acme.com の代わりに ns1.cloud.ibm.com と定義することができる。

DNS レコードとグローバル・ロード・バランサーのプロキシー接続

CIS は、グローバルロードバランサーとDNSレコードのプロキシをサポートしています。 レコードやロードバランサーがプロキシされると、そのトラフィックは CIS を直接経由する。

現在、AAAAA、または CNAME タイプの DNS レコードをプロキシー接続できます。

プロキシー・モードの設定

ロード・バランサーと DNS レコードは、DNS 専用モードと HTTP プロキシー・モードの両方をサポートしています。 同じ CIS インスタンスに HTTP プロキシとDNSのみのドメインを持つことができますが、トラフィックルーティングの動作は異なります。プロキシされるレコードのトラフィックは CIS を経由して流れますが、プロキシされないレコード(DNSのみのモード)のトラフィックはクライアントからオリジンに直接流れます。

HTTP プロキシー・モード

HTTP プロキシモードでは、 CIS は IBM のIPアドレスを外部にアナウンスしますが、オリジンサーバーのIPアドレスは保護(マスク)されます。 アナウンスされた IP アドレス・レコードでは、自動 TTL が使用されます。 トラフィックは CIS を経由して流れ、ファイアウォールルールやキャッシングなど、セキュリティ、パフォーマンス、信頼性のすべての機能が適用される。 また、"自動 "TTL(5分)は、 CIS に対して行われる権威クエリの数を減少させる。

DNS 専用モード

DNSのみのモードでは、レコードはオリジンIPに解決され、レコードのTTLをカスタマイズすることができます。 グローバルなロードバランサーの場合、 CIS、健康なオリジンサーバーのアドレスを直接提供するが、短いTTLを尊重するDNSリゾルバーが、健康なアドレスの更新リストを CIS DNSに問い合わせることに依存する。

DNSのみのモードでは、 CIS のセキュリティ、信頼性、パフォーマンス機能は一切適用されない。

ルート・レコードの CNAME フラット化

CNAMEフラット化」機能により、 CIS、ルートレコードがCNAMEである場合、そのドメインに対して他のレコードを持つことはできないというIETF RFCの制限を克服することができる。 CIS、権威サーバーはCNAMEそのものを返す代わりに、CNAMEターゲットに対応するAレコードを返すことで、この制限を克服し、CNAMEを効果的に隠すことができる。 このテクニックにより、ルートレコードがCNAMEであっても、MXレコードなどの他のレコードをドメインに追加することができる。

保護 DNS

DNSSECは、DNSデータにデジタルで「署名」する技術であり、DNSデータが有効であることを確信できます。 インターネットからの脆弱性を排除するためには、ルートゾーンから最終的なドメイン名(たとえば、 www.icann.org )に至るまで、検索プロセスの各段階でDNSSECを導入する必要があります。