I.概要
「コンピュータネットワーク」とに基づいて、この記事で、「コンピュータネットワーク：トップダウンのアプローチからは」次のように、研究のために著者のノート、主な内容は以下のとおりです。
- DNSサービスが提供します
- インターネットのドメイン構造
- 分散DNSサーバ
- DNSの作品
- DNSレコードの挿入にDNSレコード＆
第二に、DNSサービスが提供しました
ドメインネームシステムDNS（ドメインネームシステム）サービスは、人々がマシン名を促進するために使用するIPアドレスに変換され、非常に単純な提供しています。
我々は、すべてのユーザーと、インターネット上のホスト通信局のIPアドレスを知っている必要があります知っています。ユーザーは、通常、入力を選択しますBaiduのページへの私たちのアクセスとして、ホスト名の特定の意味があるということです覚えておくためにIPを簡単にアドレスを覚えておくことは難しいと比較www.baidu.com代わりに183.232.231.172、しかし、ルータのために、それはより多くの固定長のようなものです、IPアドレスの階層。したがって、これらの異なる嗜好を妥協するために、我々はIPアドレス変換サービスへの可能なホスト名を必要とする、ドメインネームシステム（DNS）がされて入ってきました。
エンドシステム間サーバモード通信- HTTP、FTPおよびSMTPプロトコルは、のように、DNSプロトコルは、アプリケーション層のプロトコルであり、それはまた、クライアントを使用しています。DNSプロトコルは、ポート番号53が使用されている、UDP上で実行されます。：以下に示すように下でのWindows / Linuxのコマンドラインウィンドウ、我々は、対応するIPアドレスを照会するdslookupコマンドを入力することができ
、ここで我々はBaiduの検索ドメインのIPアドレスを確認するために結果を表示し、例えば、のリターン見ることができるwww.baidu.comドメイン名を対応する2つのIPアドレスの下で、それぞれ183.232.231.172、と183.232.231.174。
第三に、インターネットドメイン名の構造
インターネットは、つまり、ドメイン名（ドメイン名）を任意のホストまたはインターネットに接続されたルータ、階層の一意の名前があり、階層命名ツリー構造を使用しています。ドメインは、サブドメインとサブドメインは、このようにトップレベルドメイン、二つのフィールド、三つのフィールド、等を形成する、サブドメインに分割することを継続することができ、サブドメインに分割することができます。ここでの例を通じて説明する：
図は、ドメイン名シナメールサーバであり、それは文法から、各ドメインのそれぞれの参照番号の間の点で区切られた番号（ラベル）配列によって。前記符号comのトップレベルドメイン、ドメイン名が第2の基準シーナあり、符号メールドメインは3です。規定以下のDNSの数字：
- 右端に書かれたトップレベルドメインの最高レベルは、最低レベルドメインは左端をアンロードします。
- アルファベットと数字の文字によってドメイン名のラベル、63文字を超えない各ラベル。
- 英字は大文字、すなわち、メールやメールがドメイン名で同等の場合されていません。
- DNSドメイン名は、下位レベルのドメイン名の数を含める必要があり、ドメイン名が指定されていませんどちらを指定するものを各レベルの意味。
- より高いレベルの管理のすべてのレベルでドメイン名管理機関、最高のトップレベルドメインがICANNによって管理され、このアプローチは、ことを確認し、各ドメイン名はインターネット全体の範囲内で一意です。
ドメイン名とポイントのポイントのIPアドレスに任意の関係を持っていない、だけで簡単にドメイン名が人々にマップ、ということに注意してください文字列とメモリ、およびIPアドレスを使用します。セカンダリドメイン名に対応するポイントのトップレベルドメインのドメインのように、DNS分散および階層設計及び後述の素晴らしい関係を有しています。
第四に、DNSサーバの分布
理論的には、インターネットが唯一のDNSサーバに送信されたすべてのクエリに直接マップのすべてが含まれているDNSサーバ、顧客を使用することができ、およびDNSサーバが直接すべての顧客の問い合わせに応答します。それは、今日の巨大なインターネットには適用されません。しかし、この設計は、以下の不具合が含まれています。
- 単一障害点。DNSサーバーがクラッシュした場合は、インターネット全体が麻痺されます。
- コミュニケーション能力。単一のDNSサーバが輻輳を引き起こす可能性があるすべてのDNSクエリを処理しなければなりません。
- 远距离的集中式数据库。单个 DNS 服务器无法照顾到所有地区的用户，当用户距离 DNS 服务器非常遥远时，很容易造成严重的时延。
- 维护。单个 DNS 服务器为所有互联网主机保留记录，这将导致该数据库异常庞大，对该数据库进行的任何修改操作将变得异常困难，维护成本高昂。
正是基于以上总总缺陷，DNS 的服务器不会被设计成这种集中式的结构，而是采用了一种分布式的设计方案。
1. 分布式的DNS服务器
分布式 DNS 服务器的设计思路如下图所示：
可以看到，DNS 除了是分布式的系统之外，它还是一个具有层次的层次性系统，这么做是基于可扩展性的考虑。这些 DNS 服务器分布在全球各地，没有一台 DNS 服务器拥有互联网上所有主机的映射，相反，该映射分布于所有的 DNS 服务器上。DNS 服务器可大致分为如下三类：
- 根 DNS 服务器：位于最高层次的 DNS 服务器；所有的根 DNS 服务器都知道所有的顶级域名服务器的域名和 IP 地址；根 DNS 服务器是最重要的 DNS 服务器，大部分情况下它并不直接把待查询的域名转换成 IP 地址（根 DNS 服务器也没有存放这种信息），而是高速本地域名服务器下一步一个找哪一个顶级域（DNS）服务器进行查询。
- 顶级域（DNS）服务器：这些服务器负责顶级域名如 com、org、net、edu 和 gov，以及所有国家的顶级域名如 uk、fr 和 cn。
- 权威 DNS 服务器：在互联网上具有公共可访问主机的每个组织机构必须提供公共可访问的 DNS 记录。这些记录将这些主机名映射为 IP 地址。一个组织机构的权威 DNS 服务器收藏了这些 DNS 记录。一个组织机构能够选择实现它自己的权威 DNS 服务器以保存这些记录或支付一定费用让这些记录存储在某个服务提供商的一个权威 DNS 服务器中。
这三种类别的 DNS 服务器和上图的对应关系为：根 DNS 服务器位于最顶层；顶级域 DNS 服务器位于第二层，如 com DNS服务器、org DNS服务器等；而顶级域 DNS 服务器的下一层为权威 DNS 服务器，如 com DNS服务器下有 yahoo.com DNS服务器。
2. 本地DNS服务器
根、顶级域和权威 DNS 服务器都处在上图所示的 DNS 层次结构中，除此之外还有一类非常重要的 DNS，称为本地 DNS 服务器（local DNS server） 。一个本地 DNS 服务器严格来说并不属于该服务器的层次结构，但它对 DNS 层次结构是很重要的，因为当一台主机发出 DNS 查询请求时，这个请求的报文就发送给本地 DNS 服务器。每个 ISP（如一个大学或一家公司）都可以有一台本地 DNS 服务器（也叫默认 DNS 服务器）。本地 DNS服务器离用户较近，一般不超过几个路由器的距离。以笔者电脑为例，本地 DNS 服务器的设置如下所示：
上图中的首选 DNS 服务器和备用 DNS 服务器均表示本地 DNS 服务器的地址，这里笔者选择的是 Google 的公共 DNS 服务器进行域名解析。
而本地 DNS 服务器还有一个非常重要的功能是对局域网中的域名进行解析。例如一个大学的内部组建了一个只需要在校园网内互联的局域网时，由于局域网内部的域名并没有（也不需要）向公众公开，那么学校内部就需要维护一个本地 DNS 服务器，将学校内部的域名和对应的IP地址进行映射，从而实现校园网内部的域名解析。
那么这个学校自己维护的本地 DNS 服务器是否可以访问外网呢？答案是可以。每一个本地 DNS 服务器都会知道根服务器的 IP 地址，当本地 DNS 服务器中没有请求域名所对应的 IP 地址时，就会向根 DNS 服务器进行查询，有了根 DNS 服务器，就可以查到外网所对应的 IP 地址了，这在下面的篇幅会进行解释。
五、DNS的工作原理
上面介绍完了DNS服务器的分布式和层次式结构之后，接下来我们来介绍 DNS 服务器的工作原理。
1. 递归查询和迭代查询
DNS 的查询采用递归和迭代查询两种形式，其中主机向本地 DNS 服务器查询发起的为递归查询，而本地 DNS 服务器后续的查询一般为迭代查询，如下图所示：
这里以查询 www.google.com 的IP地址为例：
- 首先，主机先向本地 DNS 服务器发出请求报文进行查询，注意该查询为递归查询；
- 如果本地 DNS 服务器有相关记录，直接返回结果，否则的话会向根 DNS 服务器查询；
- 根 DNS 服务器会告知本地 DNS 服务器，下一次应当查询的顶级域名服务器为 com DNS服务器；
- 本地 DNS 服务器接着会向 com DNS服务器进行查询，com DNS服务器会告知本地 DNS服务器接下来应该向权威DNS服务器 google.com 查询；
- 本地 DNS 服务器继续向 google.com DNS 服务器查询，google.com DNS 服务器就会返回 www.google.com 的 IP 地址给本地 DNS 服务器。
- 本地 DNS 服务器最后把查询结果高速主机。
以上所示查询中，后面的三个查询均为迭代查询，而主机向本地服务器发起的查询为递归查询，这种情况总共需要使用 8 个 UDP 数据报。当然，本地 DNS 服务器也可以采用递归查询的方式，这取决于最初的查询请求报文的设置具体要求使用哪一种查询，递归查询的方式如下所示：
可以看到使用递归查询的方式我们依旧要使用 8 个 UDP 报文，但这种处理方式相对于前面的递归+迭代查询的组合会加大根 DNS 服务器的负荷，所以在实践中，查询通常采用递归（主机到本地 DNS）+迭代（本地 DNS 后续的查询）的方式。
2. DNS缓存
DNS 系统还有一个非常重要的特性：DNS缓存（DNS caching）。DNS缓存用来存放最近查询过的域名以及从何处会的域名映射信息的记录。DNS缓存的原理非常简单，在一个请求链中，当某 DNS 服务器接收一个 DNS 回答时，他能将该回答中的信息缓存在本地存储器中。例如上面查询 www.google.com 的 IP 地址的例子中，如果在不久前已经有用户查询过该域名了，那么本地 DNS 服务器就不必向根 DNS 服务器重新查询 www.google.com 的 IP 地址，而是直接把 DNS缓存中存放的上次查询结果（即 www.google.com 的IP地址）返回给用户。
通过这种方式，能够提高 DNS 查询效率并减轻根 DNS 服务器的符合和减少互联网上的 DNS 查询报文数量。但需要注意的是域名和 IP 地址的绑定并不是永久的（虽然并不经常改变），为了保持 DNS 缓存的正确性，DNS 服务器在一段时间后（通常设置为两天）将丢弃缓存的信息。
所以维护一个本地 DNS 服务器还有一个好处就是能够提高 DNS 查询效率。例如在一个大学中，当很多的 DNS 查询都指向同一个域名时，可以加快查询效率以及减轻流量负担。
六、DNS记录 & 往DNS插入记录
1. DNS 资源记录
在分布式数据库结构中的所有 DNS 服务器里面存储的内容是资源记录（Resource Record，RR），RR 提供了主机名到 IP 地址的映射，它是一个包含下列字段的四元组：
(Name, Value, Type, TTL)
其中，TTL 表示该记录的生存时间，它决定了资源记录应但从缓存中删除的时间。Name 和 Value 的值取决于 Type，如下表所示：
| Type | 含义 |
|---|---|
| A | Name为主机名，Value为该主机名对应的IP地址。该资源记录提供了标准的主机名到IP地址的映射 |
| NS | Name为域，Value为知道如何获得该域IP地址的权威DNS服务器的主机名。该资源记录用于沿着查询链来路由DNS查询 |
| CNAME | Name为别名，Value为规范主机名。该资源记录能够向查询的主机提供一个主机名对应的规范主机名 |
| MX | Name为别名，Value为邮箱服务器的规范主机名。该资源记录允许邮件服务器主机名具有简单的别名 |
下面举几个例子来说明上述表格的类型，注意下列例子均忽略了四元组中的 TTL。
- ( relay.bar.foo.com, 145.37.93.126, A )：类型为 A 的资源记录，表示主机名 relay.bar.foo.com 对应的 IP 地址为145.37.93.126。
- ( foo.com, dns.foo.com, NS )：类型为 NS 的资源记录，dns.foo.com 为知道 foo.com 这个域IP地址的权威地址的主机名。
- ( foo.com, reply.bar.foo.com, CNAME )：类型为 CNAME 的资源记录，foo.com 为 reply.bar.foo.com 的简单别名。
- ( foo.com, mail.bar.foo.com, MX )：类型为 MX 的资源记录，foo.com 为 mail.bar.foo.com 这个邮件服务器的简单别名。
2. 在DNS数据库中插入记录
到目前为止，我们所介绍的都是如何向 DNS 服务器查询域名的 IP 地址，现在我们就来了解一下如何往 DNS 数据库中插入记录以便我们自己的域名能够被他人访问到。
例如我们现在要创建一个域名 marck.com。首先我们就要先向注册登记机构注册域名 marck.com。注册登记机构（registrar）是一个商业实体，它验证该域名的唯一性，将该域名输入 DNS 数据库，对提供的服务收取一定的费用。在互联网初期唯一的注册登记机构是 Network Solution，它独家经营对于 com、net 和 org 域名的注册。现如今注册登记机构已有多家，例如国内较为出名的腾讯、阿里等均有此项业务。
当我们向某注册登记机构注册域名 marck.com 时，需要向该机构提供基本和辅助权威 DNS 服务器的名字和 IP 地址。假定该名字和 IP 地址是 dns1.marck.com 和 dns2.marck.com 以及 222.222.222.1 和 222.222.222.2。该注册登记机构将确保这两个权威 DNS 服务器的一个类型 NS 和一个类型 A 的记录输入 TLD com 服务器。例如对于 dns1.marck.com 的基本权威服务器，该注册登记机构将下列两条资源记录插入该 DNS 系统中：
( marck.com, dns1.marck.com, NS )
( dns1.marck.com, 222.222.222.1, A )
上記のリソースレコードはTTLを無視していることに注意してください。そして、例えば記録されている私たち自身の権威DNSサーバ、中www.marck.comまたはmail.marck.com私たち自身のメンテナンスによりマッピングされているIPアドレスを、対応するこれらのサブドメイン名を。
上記の手順が完了した後、人々は私たちのサイトAにアクセスすることができます。例えば、誰かがアクセスするwww.marck.comをこのWebサイト、および彼がブラウザにURLを入力するときに、ローカルDNSキャッシュがIPアドレスに関連していない場合、ブラウザは、ローカルのDNSサーバへのクエリ要求を送信し、その後、それが根に相当するであろうDNSサーバーがクエリを送信し、その後、ルートDNSサーバーは、ローカルのDNSサーバーがTLDのCOMサーバーを照会する通知します。それはローカルのDNSサーバTLDのCOMサーバーに通知しますので、TLD COMサーバーは、その後、これらすべてのリソースレコードのTLDのCOMサーバーを挿入された登録手段として、上記の2つのTLDのCOMサーバーのリソースレコードを備え、ローカルサーバーに連絡しますローカルDNSサーバーが正常に私たちの権威DNSサーバーを見つけることができるので、次は、222.222.222.1にDNSクエリを送信する必要があります。
VII参照
-
「コンピュータネットワーク」
- 第6章アプリケーション層
- 6.1ドメインネームシステム（DNS）
- 第6章アプリケーション層
-
「コンピュータネットワーク：トップダウンアプローチ。」
- 第2章アプリケーション層
- 2.5 DNS：インターネットディレクトリサービス
- 第2章アプリケーション層