DNSの歴史
70 年代に戻ると、人々はアクセスしたいサーバーの IP アドレスを覚えることにうんざりしていました。同時に、数値のホスト アドレスの代わりに、よりシンプルで覚えやすい名前を使用するというアイデアが思いつきました。
スタンフォード研究所の職員は、ARPANET 上のコンピュータの文字列名とそれに対応する数値アドレスのリストを含むテキスト ファイルHOSTS.TXTを考案しました。
アドレスは手動で割り当てられました。ホスト名とアドレスを要求したり、マスター ファイルにコンピュータを追加したりするには、ユーザーは営業時間内にスタンフォード大学のネットワーク インフォメーション センターに電話で問い合わせました。
1980 年代初頭までに、単一の集中ホスト テーブルの維持は遅くて煩雑になり、成長するネットワークには技術的および人的問題に対処するための自動命名システムが必要でした。
1984 年、カリフォルニア大学バークレー校の 4 人の学生が階層型ドメイン名システムの最初のバージョンを作成しました。これは現在、特に Unix システムで広く使用されており、依然としてインターネット上で最も広く使用されている DNS ソフトウェアです。
DNS の概要
ドメイン ネーム システム (DNS) は、ドメインに関する情報を保存および取得するための分散システムです。最も一般的には、ホスト名 (コンピューターまたはデバイス) から IP アドレスを取得したり、メール ルーティング情報を取得したり、ドメイン内のプロトコルのホストにサービスを提供したりするために使用されます。
システムは、特定のプロトコルに従って対話する DNS サーバーの特定の階層の形式で編成されています。DNS を理解するための基礎は、名前とゾーンの階層構造を理解することです。
ドメイン ゾーンを担当する各サーバーは、ドメインのさらなる部分に対する責任を別のサーバーに移すことができます。これにより、情報の関連性に対する責任を、ドメインの「自分たちの」部分のみを担当するさまざまな組織のサーバーに割り当てることが可能になります。ドメイン名。
DNS システムには、ゾーン階層に対応するDNS サーバーの階層が含まれています。各ゾーンは、ドメインに関する情報をホストする少なくとも 1 つの権威 DNS サーバーによってサポートされます。
重要!名前とIPアドレスは必ずしも1対1で対応するとは限りません。1 つの IP アドレスに多数のドメイン名を含めることができるため、1 台のコンピュータ上で多数の Web サイトをサポートできます (これは共有ホスティングと呼ばれます)。
その逆も可能です。多くの IP アドレスを 1 つのドメイン名に関連付けることができます。これにより、負荷分散を作成でき、CDN ネットワークで積極的に使用されます。
システムの安定性を高めるために、同一の情報を含む多数のサーバーが使用され、プロトコルには、異なるサーバーにある情報の同期を維持する手段が備えられています。ルート サーバーは 13 台あり、それらのアドレスは実質的に変わりません。
面白い!DNS プロトコルは、TCP または UDP ポート 53 を使用してクエリに応答します。従来、リクエストとレスポンスは単一の UDP データグラムとして送信されます。応答データサイズが512バイトを超える場合はTCPが使用されます。
DNSレコード
DNS サーバーは、ドメイン名ごとに一連のパラメータを保存します。これらは、ドメイン名、その IP アドレス、およびさまざまなサービス情報に関する記録です。
このようなエントリは合計で数十あるため、その中で最も人気のあるものだけを取り上げます。
あ | 住所 | IPアドレス |
ああああ | アドレスIPv6 | IPv6形式のアドレス |
CNAME | 正規名 | エイリアスの正規名 |
MX | メールエクスチェンジャー | ドメインのメールゲートウェイアドレス |
NS | ネームサーバー | ドメインゾーンを担当するノードのアドレス |
SOA | 権限の開始 | 情報の権威の表示 |
SRV | サーバーの選択 | サービスのサーバーの場所の指定 |
PTR | ポインタ | アドレス名の一致 - A と AAAA の逆一致 |
TXT | テキスト文字列 | 最大 255 バイトの任意のバイナリ データを書き込みます |
ここで最も興味深いのは次のとおりです。
- Aレコードを使用すると、ドメインに対応する IP アドレスを指定できます。
- CNAME を使用すると、名前の同義語を設定できます (例: www.codegym.cc == codegym.cc)。
- MXレコードには、メール サーバーに関する情報 (手紙が xxx@codegym.cc に届いた場合にどうするか) が含まれています。
- NS - このドメインに関する情報が含まれる DNS サーバーのアドレスを示します。レコードがキャッシュされ、非ネイティブ ノードに保存される場合に便利です。
IPアドレス検索
DNS システムがどのように機能するかを見てみましょう。
ブラウザに「api.codegym.cc」と入力したとします。ブラウザはローカル DNS サービスに接続し、api.codegym.cc ドメインの IP アドレスを与えるように求めます。次に何が起こるか...
まず、DNS サービスは、このドメインがコンピュータ上のローカル ホスト ファイルに存在するかどうかを確認します。存在する場合は、そこから IP アドレスを取得します。そうでない場合は、既知の DNS サーバーに「api.codegym.cc の IP アドレスは何ですか?」というリクエストを送信します。
ただし、DNS サーバーは、要求された名前だけでなく、codegym.cc ドメイン全体についても何も知らない可能性があります。この場合、サーバーはルート サーバー (たとえば、198.41.0.4) に接続します。このサーバーは、「このアドレスに関する情報はありませんが、204.74.112.1 が ru ゾーンを担当していることはわかっています。」と述べています。
次に、DNS サーバーはそのリクエストを 204.74.112.1 に送信しますが、「このサーバーに関する情報はありませんが、207.142.131.234 が codegym.cc ゾーンを担当していることはわかっています。」と応答します。最後に、同じ要求が 3 番目の DNS サーバーに送信され、応答 (IP アドレス) を受け取り、それがクライアント、つまりブラウザーに送信されます。
この場合、名前で IP を検索するプロセスで、次のルールが機能しました。
- ブラウザは既知の DNS サーバーに再帰リクエストを送信しました (このタイプのリクエストに応答して、サーバーは IP アドレス、または空の応答と NXDOMAIN エラー コードを返す必要があります)。
- ブラウザからリクエストを受信した DNS サーバーは、リクエストされたゾーンを担当するサーバーからの応答を受信するまで、非再帰リクエストを連続して送信し、他の DNS サーバーからの応答を受け取ります。
- 言及されている残りの DNS サーバーは、リクエストを非再帰的に処理していました (そして、リクエストにそのような要件があったとしても、リクエストを再帰的に処理しなかった可能性が最も高いです)。
要求されたサーバーが「アップストリーム」DNS サーバーに再帰クエリを送信し、準備ができた応答を待つことができる場合があります。
重要!再帰的なクエリ処理では、すべての応答が DNS サーバーを通過し、キャッシュされる機会が得られます。同じドメイン名に対する繰り返しのリクエストは通常、サーバーのキャッシュを超えることはなく、他のサーバーへの呼び出しはまったく発生しません。
応答の許容キャッシュ時間は応答に付属しています (リソース レコードの TTL フィールド)。
ホストファイル
最初の検索がローカル ホスト ファイル内であることがわかりました。これは、ARPANET の時代に発明された HOSTS.TXT ファイルの後継です。はい、まだ存在しており、使用されています。
道沿いにあります。
- Linux の/etc/hosts 。
- Windows の%SystemRoot%\system32\drivers\etc\hosts。
- Androidの場合は/system/etc/hosts。
通常、ファイルにはローカルホスト ノードの場所の定義が含まれています。
127.0.0.1 localhost
その構造は非常に単純です。最初に IP アドレスが来て、次にドメイン名が来ます。
使える
hosts ファイルを使用すると、バナーのドメイン アドレスをアドレス 127.0.0.0、127.0.0.1、または 0.0.0.0 にリダイレクトすることで広告をフィルタリングできます。
127.0.0.1 の使用は、サーバーが存在しないか構成が間違っている場合に応答タイムアウトとそれに伴う遅延が発生するため、通常は推奨されません。また、広告ドメインを IP アドレス 0.0.0.0 にマップすると、そのドメインへのすべてのリクエストは直ちに無効になります)。
パブリックDNSサーバー
通常、インターネット サービスに接続すると、DNS サーバーが一緒に取得されます。ただし、このような無料の DNS サーバーが常に最良の選択肢であるとは限りません。さらに、サイトにアクセスするたびにドメイン名を含むクエリを ISP の DNS サーバーに送信したくない場合もあります。
したがって、多くの人はパブリックの無料 DNS サーバーに切り替えることを好みます。まず、非常に高速で、ドメイン名のキャッシュが大量にあります。技術的な問題が発生する可能性を最小限に抑えながら、サイトの読み込みと稼働時間が短縮されます。
第二に、安全性です。一部の DNS サービスは、フィッシング サイトや悪意のあるサイトへのアクセスをブロックし、子供たちをオンラインの不適切なコンテンツから保護するコンテンツ フィルタリングを提供します。
このような DNS サーバーは詐欺師と戦うこともできます。たとえば、偽の銀行 Web サイトにアクセスすると、DNS サーバーは詐欺師の IP アドレスではなく、そのセキュリティ サービスを提供します。
そのようなサーバーのリスト
クラウドフレア | 1.1.1.1 1.0.0.1 |
Cloudflareは、広告を配信するために訪問者のデータを使用しないこと、またリクエストの送信元IPアドレスをディスクに書き込むことは決してないと約束します。 |
GoogleパブリックDNS | 8.8.8.8 8.8.4.4 |
トラブルシューティングと診断のために、要求元デバイスの IP アドレスに関する完全な情報を約 24 ~ 48 時間保存します。 |
Comodo セキュア DNS | 8.26.56.26 8.20.247.20 |
フィッシング サイトをブロックしますが、マルウェアやスパイウェアが含まれるサイトにアクセスしようとしている場合にも警告します |
Yandex.DNS | 77.88.8.8 77.88.8.1 |
ロシアの人気検索エンジンによる無料の DNS サービス |
GO TO FULL VERSION