一、域名的形式
域名是一个有层次的结构,是一串用.
分隔的多个单词,最右边的被称为顶级域名,然后是二级域名,层次关系向左依次降低
最左边的是主机名,通常用来表示主机的用途,比如www表示提供万维网服务、mail表示提供邮件服务
二、域名的解析
域名转换成IP地址的过程称为域名解析
DNS的核心系统是一个三层的树状、分布式服务,基本对应域名的结构:
1)根域名服务器(Root DNS Server):管理顶级域名服务器,返回com、net、cn等顶级域名服务器的IP地址
2)顶级域名服务器(Top-level DNS Server):管理各自域名下的权威域名服务器,比如com顶级域名服务器返回apple.com域名服务器的IP地址
3)权威域名服务器(Authoritative DNS Server):管理自己域名下主机的IP地址,比如apple.com权威域名服务器可以返回www.apple.com的IP地址
任何一个域名都可以在这个树形结构从顶至下进行查询,就好像是把域名从右到左顺序走了一遍,最终就获得了域名对应的IP地址
例如,要访问www.apple.com,就要进行下面的三次查询:
1)访问根域名服务器,得到com顶级域名服务器的地址
2)访问com顶级域名服务器,得到apple.com域名服务器的地址
3)最后访问apple.com域名服务器,就得到了www.apple.com的地址
在核心DNS系统之外,还有很多手段用来减轻域名解析的压力,并且能够更快地获取结果
首先,许多大公司、网络运行商都会建立自己的DNS服务器,作为用户DNS查询的代理,代替用户访问核心DNS系统。这些服务器被称为非权威域名服务器,可以缓存之前的查询结果,如果已经有了记录,就无需再向根服务器发起查询,直接返回对应的IP地址
其次,操作系统里也会对DNS解析结果做缓存,如果之前访问过www.apple.com,那么下一次在浏览器里再输入这个网址的时候就不会在跑到DNS那里去问了,直接在操作系统里就可以拿到IP地址
另外,操作系统里还有一个特殊的主机映射文件,通常是一个可编辑的文本,在Linux里是/etc/hsots
,在Windows里是C:\WINDOWS\system32\drivers\etc\hosts
,如果操作系统在缓存里找不到DNS记录,就会找这个文件
案例:
在浏览器地址栏输入一个不存在的域名,比如就叫www.不存在.com,试着解释一下它的DNS解析过程
1)检查浏览器缓存中是否存在解析www.不存在.com域名的IP
2)检查本地DNS缓存是否存在解析www.不存在.com域名的IP
3)如果没有找到继续查找本地hosts文件内是否有对应的固定记录
4)如果hosts中还是没有那就根据本地网卡被分配的DNS Server IP来进行解析,DNS Server IP一般是“非官方”的IP,比如谷歌的8.8.8.8
,本身它也会对查找的域名解析结果进行缓存,如果它没有缓存或者缓存失效,则先去顶级域名服务器com去查找不存在.com
的域名服务器IP,结果发现不存在,于是直接返回告诉浏览器域名解析错误(这两次查找过程是基于UDP协议)
三、DNS采用的协议
DNS同时占用UDP和TCP端口53
DNS在进行区域传输的时候使用TCP协议,其它时候则使用UDP协议
DNS的规范中规定了2种类型的DNS服务器,一个叫主DNS服务器,一个叫辅助DNS服务器。在一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息,而辅助DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息。当一个辅助DNS服务器启动时,它需要与主DNS服务器通信,并加载数据信息,这就叫做区传送(Zone Transfer)
为什么既使用TCP又使用UDP?
首先了解一下TCP与UDP传送字节的长度限制:
UDP报文的最大长度为512字节,而TCP则允许报文长度超过512字节。当DNS查询超过512字节时,协议的TC标志出现删除标志,这时则使用TCP发送。通常传统的UDP报文一般不会大于512字节
区域传送时使用TCP,主要有一下两点考虑:
1)辅域名服务器会定时(一般时3小时)向主域名服务器进行查询以便了解数据是否有变动。如有变动,则会执行一次区域传送,进行数据同步。区域传送将使用TCP而不是UDP,因为数据同步传送的数据量比一个请求和应答的数据量要多得多
2)TCP是一种可靠的连接,保证了数据的准确性
域名解析时使用UDP协议:
客户端向DNS服务器查询域名,一般返回的内容都不超过512字节,用UDP传输即可。不用经过TCP三次握手,这样DNS服务器负载更低,响应更快。虽然从理论上说,客户端也可以指定向DNS服务器查询的时候使用TCP,但事实上,很多DNS服务器进行配置的时候,仅支持UDP查询包
参考:http://benbenxiongyuan.iteye.com/blog/1088085