标签：style http io 使用 ar 文件 数据 div sp
主机名控制者： DNS 服务器地址：http://vbird.dic.ksu.edu.tw/linux_server/0350dns_1.php
整个分层查询的流程就是这样，总是得要先经过 . 来向下一层进行查询，最终总是能得到答案的。这样分层的好处是：
主机名修改的仅需自己的 DNS 更动即可，不需通知其他人：
当一个『合法』的 DNS 服务器里面的设定修改了之后，来自世界各地任何一个 DNS 的要求，都会正确无误的显示正确的主机名对应
IP 的信息，因为他们会一层一层的寻找下来。所以，要找你的主机名对应的 IP 就一定得要透过你的上层 DNS
服务器的纪录才行！因此，只要你的主机名字是经过上层『合法的
DNS』服务器设定的，那么就可以在 Internet 上面被查询到啦！呵呵！很简单维护吧，机动性也很高。
DNS 服务器对主机名解析结果的快取时间：
由于每次查询到的结果都会储存在 DNS 服务器的高速缓存中，以方便若下次有相同需求的解析时，能够快速的响应。
不过，查询结果已经被快取了，但是原始 DNS 的主机名与 IP 对应却修改了，此时若有人再次查询，
系统可能会回报旧的 IP 喔！所以，在快取内的答案是有时间性的！通常是数十分钟到三天之内。
这也是为什么我们常说当你修改了一个 domain name 之后，可能要 2 ~ 3 天后才能全面的启用的缘故啦！
可持续向下授权 (子领域名授权)：
每一部可以记录主机名与 IP 对应的 DNS 服务器都可以随意更动他自己的数据库对应，
因此主机名与域名在各个主机底下都不相同。举例来说， idv.tw 是仅有台湾才有这个 idv 的网域～
因为这个 idv 是由 .tw 所管理的，所以只要台湾 .tw 维护小组同意，就能够建立该网域喔！
例题：
答：
|
[root@www ~]# dig +trace www.ksu.edu.tw ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>>+trace www.ksu.edu.tw ;; global options: printcmd . 486278 IN NS a.root-servers.net. . 486278 IN NS b.root-servers.net. ....(底下省略).... # 上面的部分在追踪 . 的服务器，可从 a ~ m.root-servers.net. ;; Received 500 bytes from 168.95.1.1#53(168.95.1.1) in 22 ms tw. 172800 IN NS ns.twnic.net. tw. 172800 IN NS a.dns.tw. tw. 172800 IN NS b.dns.tw. ....(底下省略).... # 上面的部分在追踪 .tw. 的服务器，可从 a ~ h.dns.tw. 包括 ns.twnic.net. ;; Received 474 bytes from 192.33.4.12#53(c.root-servers.net) in 168 ms edu.tw. 86400 IN NS a.twnic.net.tw. edu.tw. 86400 IN NS b.twnic.net.tw. # 追踪 .edu.tw. 的则有 7 部服务器 ;; Received 395 bytes from 192.83.166.11#53(ns.twnic.net) in 22 ms ksu.edu.tw. 86400 IN NS dns2.ksu.edu.tw. ksu.edu.tw. 86400 IN NS dns3.twaren.net. ksu.edu.tw. 86400 IN NS dns1.ksu.edu.tw. ;; Received 131 bytes from 192.83.166.9#53(a.twnic.net.tw) in 22 ms www.ksu.edu.tw. 3600 IN A 120.114.100.101 ksu.edu.tw. 3600 IN NS dns2.ksu.edu.tw. ksu.edu.tw. 3600 IN NS dns1.ksu.edu.tw. ksu.edu.tw. 3600 IN NS dns3.twaren.net. ;; Received 147 bytes from 120.114.150.1#53(dns2.ksu.edu.tw) in 14 ms |
SOA：就是开始验证 (Start of Authority) 的缩写，相关资料本章后续小节说明；
NS：就是名称服务器 (NameServer) 的缩写，后面记录的数据是 DNS 服务器的意思；
A：就是地址 (Address) 的缩写，后面记录的是 IP 的对应 (最重要)；
那么 Master/Slave 的数据更新到底是如何动作的呢？请注意，Slave 是需要更新来自 Master 的数据啊！所以当然 Slave 在设定之初就需要存在 Master 才行喔！基本上，不论 Master 还是 Slave 的数据库，都会有一个代表该数据库新旧的『序号』，这个序号数值的大小，是会影响是否要更新的动作唷！ 至于更新的方式主要有两种：
由上面的说明来看，其实设计数据库的序号最重要的目的就是让 master/slave 数据的同步化。那我们也知道 slave 会向 master 提出数据库更新的需求，问题是，多久提出一次更新，如果该次更新时由于网络问题，所以没有查询到 master 的序号 (亦即更新失败)，那隔多久会重新更新一次？这个与 SOA 的标志有关，后续谈到正、反解数据库后， 再来详细说明吧！
如果你想要架设 Master/Slave 的 DNS 架构时，两部主机 (Master/Slave) 都需要你能够掌控才行！网络上很多的文件在这个地方都有点『闪失』，请特别的留意啊！因为鸟哥的 DNS 服务器常常会听到某些其他 DNS 的数据库同步化需求，真觉得烦吶！
标签：style http io 使用 ar 文件 数据 div sp
原文地址：http://www.cnblogs.com/521football/p/3990172.html
