DNS服务工作原理

本文涉及的产品
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
.cn 域名,1个 12个月
云解析 DNS,旗舰版 1个月
简介: 文章详细介绍了DNS服务的工作原理,包括FQDN的概念、名称解析过程、DNS域名分级策略、根服务器的作用、DNS解析流程中的递归查询和迭代查询,以及为何有时基于IP能访问而基于域名不能访问的原因。

作者:尹正杰
版权声明:原创作品,谢绝转载!否则将追究法律责任。

一.名称解析介绍

1>.FQDN

  Fully Qualified Domain Name的简称是"FQDN",表示全限定域名,即同时带有主机和域名使用点号(".")来分割。

  如下图所示,我在互联网购买了自己的域名:"yinzhengjie.com",我们可以为该域名添加对应的主机名,假设某主机名为"www",其域名为"yinzhengjie.com",那么FQDN就是:"www.yinzhengjie.com"

  FQDN有啥作用呢?
    身为IT人大家都知道无论是ISO七层模型还是TCP/IP协议族,均没有域名这个概念,网络层的数据报文中记录的原地址和目标地址都是IP地址。
    综上所述,那还要这个FQDN有啥用呢?我个人理解主要就是方便咱们人类记忆,比如让你记住百度的网站你肯能一口就能说出来,即"www.baidu.com",但是让你说百度的服务器IP地址你可能就蒙了。
    当然,它的功能可不仅仅是方便我们人类记忆哟~这里允许我先买个关子!  

  那什么是名称解析呢?  
    其实很简单,就是就是将我们上面提到的FQDN解析为对应的IP地址,因为大家都知道百度的网站地址为"www.baidu.com",而TCP/IP数据报文中仅有IP地址的信息,所以必须将FQDN解析为IP地址方能通信。  
    而将FQDN解析为IP地址的解析方式我们称为"正向解析",将IP地址解析成域名方式我们称为"反向解析"。可能你会问,正向解析能理解,那为什么要有反向解析呢?请允许我再卖个关子,连同上面的疑问,让我们带着疑问去学习会事半功倍!

2>.本地文件解析顺序

  如下图所示:  
    Linux的本地名称解析默认配置文件位置:   
      /etc/hosts  
    Windows的本地名称解析默认配置文件位置:   
      C:\Windows\System32\drivers\etc  

  温馨提示:  
    我们可以指定Linux的文件解析顺序,默认是先从本地文件进行解析,而后再通过DNS进行解析的哟~

3>.分散式解析,集中式解析和分布式解析

  分散式解析:
    就是我们上面提到的,每个节点都可以修改自己的hosts文件,从而自定义解析记录。
    优点:
      (1)无需部署服务,直接编辑本地文件即可,Windows和Linux均可。
      (2)配置起来比较简单;
    缺点:
      当服务器数量过多时,不利于维护解析记录的管理。
      比如:某互联网公司有300多万台服务器,其中有10万台用作大数据集群,你身为大数据运维工程师,需要对现有集群做域名解析,请思考你会如何做呢?

  集中式解析:
    就是找一台服务器,所有的客户端都去找这台服务器进行解析。
    优点:
      无需为每台服务器单独配置解析记录,仅需维护DNS服务器的解析记录即可;
    缺点:
      (1)需要单独部署一台专用于名称解析的服务器;
      (2)存在单点故障的风险,因此生产环境中需要引入高可用解决方案,或者部署一台备用的服务器;
  
  分布式解析:
    这种解析方式它是集合了分散式解析与集中式解析的优点于一身。典型代表就是我们今天要介绍的DNS服务器,互联网上各大公司有很多解决方案,但比较出名且开源的DNS方案,其中ISC公司的bind软件系列就是典型的代表。
    这个服务器的功能我们称之为Domain Name Service(检查"DNS")服务器,是应用层协议,基于C/S架构。默认的使用的端口和协议为: 53/tcp,53/udp。

  温馨提示:
    如下图所示,我们会使用Internetr Systems Consortium(简称"ISC")公司的Bekerley Internat Name Domain(简称"BIND")产品来搭建一台DNS服务器。
    官网地址:https://www.isc.org/

二.DNS服务工作原理

1>.DNS域名分级策略

  我们通常把域名分为三类,即组织域,国家域和反向域。

  域名是有分级策略的,从根域,一级域名,二级域名,三级域名,......,最多有127级域名。

  Internet Corporation for Assigned Names and Number(简称:"ICANN")是互联网名称与数字地址分配机构,负责在全球范围内对互联网通用顶级域名(gTLD)以及国家和地区域名(ccTLD)系统的管理,以及根服务器系统的管理。

  常见的一级域名如下所示:
    .COM
      注册于1985年1月1日,设计用于营利性机构,现通用。
    .NET
      注册于1985年1月1日,设计用于网络服务机构,现通用。
    .ORG
      注册于1985年1月1日,设计用于非营利性组织,现通用。
    .EDU
      注册于1985年1月1日,用于美国教育机构。
     .GOV
      注册于1985年1月1日,用于美国政府机构。
    .MIL
      注册于1985年1月1日,用于美国军事机构。
    .ARPA
      注册于1985年1月1日,用于DNS反向地址解析。

  常见的国家域名如下所示:
    .CN
      国家代码中国科学院计算机网络中心
    .US
      国家代码美国纽斯达公司劳顿技术中心
    .HK
      国家代码香港香港互联网注册有限公司
    .TW
      国家代码台湾网络信息中心(TWNIC)

  光看上面的定义可能有点蒙,接下来我们来看下面的3个案例来加深一些理解(建议搭配下图一起看,这样更容易理解):     
    (1)devops.yinzhengjie.com       
      首先,我们先把上面的根域补上,则写成:"devops.yinzhengjie.com.",你没有看错,就在上面的域名最后加了一个点号("."),只不过专业术语交根域。
      接下来我们就开始对号入座:
        根域:
          上述域名中最后一个".",就是我们上面手动添加的".",请不要和该域名的前两个点号(".")混淆,因为只有最后一个点号才是根域,其他的点号仅做域名或主机名的分隔符使用。
        一级域名:
          ".com"
        二级域名:
          ".yinzhengjie"
        主机名:
          "devops"

    (2)www.chsi.com.cn
      同上,我们先把上面的根域补上,则写成:"www.chsi.com.cn",你没有看错,就在上面的域名最后加了一个点号("."),只不过专业术语交根域。
      接下来我们就开始对号入座:
        根域:
          上述域名中最后一个".",就是我们上面手动添加的".",请不要和该域名的前两个点号(".")混淆,因为只有最后一个点号才是根域,其他的点号仅做域名或主机名的分隔符使用。
        一级域名:
          ".cn"
        二级域名:
          ".com"
        三级域名:
          ".chsi"
        主机名:
          "www"  
    (3)www.baidu.com       
      同上,我们先把上面的根域补上,则写成:"www.baidu.com.",你没有看错,就在上面的域名最后加了一个点号("."),只不过专业术语交根域。   
      接下来我们就开始对号入座:
        根域:
          上述域名中最后一个".",就是我们上面手动添加的".",请不要和该域名的前两个点号(".")混淆,因为只有最后一个点号才是根域,其他的点号仅做域名或主机名的分隔符使用。
        一级域名:
          ".com"
        二级域名:
          ".baidu"
        主机名:
          "www"

  参考链接:     
    https://baike.baidu.com/item/%E5%9F%9F%E5%90%8D%E4%BD%93%E7%B3%BB/6385147

2>.13个逻辑根域服务器(截止2020年12月29日晚上9:18,实际上由1367台服务器为咱们全球70亿用户来做域名解析,可能后续还会增加服务器实例数量)

  根服务器就是域名解析系统中最上层的服务器,对最终域名解析进行服务, 它记录了所有的一级域名所指向的DNS服务器。

  全球从逻辑上来讲有13个根域名服务器。13个根名称服务器由12个独立组织运营。
  
  如下图所示,截至2020年12月29日晚上9:18,根服务器系统由12个独立的根服务器操作员操作的1367个实例组成。

  温馨提示:
    全球有70亿用户,包括每个用户的电脑,笔记本,手机均可以访问互联网,但不是每次请求记录都得访问各地区的根域,运营商肯定会用到相应的缓存技术,比如典型的LRU算法。
    全球有13个根服务器指的是IPV4地址的DNS解析,而IPV6的根服务器有25台,其中中国和美国都有一台主服务器,中国有一主三辅,身为一个中华人民共和国的公民,我们心里都在默默说了一句:"真香~"  

  参考链接:
    https://root-servers.org/
    https://root-servers.org/faq/
    https://zhuanlan.zhihu.com/p/41975349

3>.DNS解析流程分析-递归查询和迭代查询

  接下来我们分析一个场景:
    假设你在家里玩手机,我们也假设你的手机可以正常连接到家里的路由器,并且是可以正常上网的,这个时候你访问"www.cnblog.com"这个域名时,它是访问的呢?
    
  前提说明:
    我们不会在家上网不会去搭建DNS服务器,而是使用网络上公开的DNS地址,通常情况下是运行时给我们指定的地址,比如你家拉的是移动,电信,联通的网络,那他们的工程师会给你配上对应运营商的DNS地址。

  综上所述,接下来我们分析一下访问"www.cnblog.com"这个域名,域名的解析流程如下所示:
    (1)首先访问的是域名,因此需要访问DNS进行请求,此时通过网关地址会路由到运营商的DNS服务器地址,并请求解析"www.cnblog.com."这个域名(此时,请先忽略运营商DNS服务器有缓存的情况);
    (2)运营商的DNS服务器本地假设是没有缓存的,因此它会请求访问根域服务器,请求"www.cnblog.com."这个域名对应的IP地址;
    (3)当根域"www.cnblog.com."这个域名时傻眼了,说这个域名我解析不了,但我知道你访问的域名的一级域名指向的DNS服务器,这个时候回返回".com"服务器所指向的DNS服务器的IP地址给运营商的DNS服务器;
    (4)运营商的DNS服务器拿到根域返回的".com"所指向的一级域名服务器,就继续向".com"所在的DNS服务器发送请求,询问"www.cnblog.com."的解析记录;
    (5)当".com"的DNS服务器拿到这个域名的时候也傻眼了,说这个域名我解析不了,但我这里有".cnblog"的DNS服务器记录,你可以询问一下它;
    (6)这个时候运营商的DNS服务器拿到".cnblog"所指向二级域名服务器,就继续向".cnblog"所在的DNS服务器发送请求,询问"www.cnblog.com."的解析记录;
    (7)当".cnblog"的DNS服务器拿到这个域名的时候,发现自己有"www"主机名对应的IP地址是"45.76.29.156",于是就将该IP地址返回给运营商的DNS服务器;
    (8)此时,DNS服务器终于拿到了你想要请求的"www.cnblog.com."的IP地址了,然后将该记录直接返回给你的手机端(注意哈,上述过程解析的IP地址解析记录基本上会在本地缓存一段时间哟~你猜猜这是为啥?);
    (9)拿到DNS解析的IP地址后,你手机的浏览器就开始访问"www.cnblog.com"对应所指向的服务器地址"45.76.29.156",这接下来就是建立TCP连接过程,此过程我就省略了哈,不是本篇博客的讨论重点;
    (10)当TCP建立好连接后,你可以可以基于HTTPS协议和博客的服务端进行通信了。

  通过上面的案例,存在两种查找类型,即递归查询和迭代查询:
    递归查询:
      对最终的查询结果负责到底。本案例指的是你想运营商的DNS发起的查询。当你的手机访问"www.cnblog.com"域名时,运营商的DNS会将最终的解析IP("45.76.29.156")地址返回给你。
    迭代查询:
      不对最终的结果负责。本案例指的是运营商的DNS向根域DNS服务器,".com"一级域名服务器,".blog"二级域名服务器发起的三次查询。

  反向解析:  
    我们想要将一个"www.yinzhengjie.com"解析IP地址为"172.200.1.201"时,可以这样写:"172.200.1.201 www.yinzhengjie.com",那如果我要将通过IP地址来解析一个域名该如何操作呢?这就得用到反向解析技术!  
    在根域下面还有一个反向解析的一级域名,即".ARPA",该域名下还有一个二级域名为".in-addr",而这个二级域名下面就是反向解析的IP地址。  
    举个例子,我们想把"172.200.1.201"这个IP地址反向解析为"www.yinzhengjie.com"时,其实它是一个反向查询的过程如下所示。  
      (1)根域;    
      (2)".ARPR";  
      (3)".in-addr";  
      (4)"201";  
      (5)"1";  
      (6)"200";  
      (7)"172";  
    注意哈,写反向解析的IP地址应该反着来,即: "www.yinzhengjie.com 172.200.1.201.in-addr.ARPR.",看起来貌似很别扭,但我们域名其实也是这样写的呀~  
  温馨提示:
    需要注意的是,我们在访问运营商的DNS服务器时,它并不会每次去都去像上面我那样访问哟,而是会先访问本地的缓存,若有对应的缓存记录就直接返回对应的缓存记录,无需在基于TCP/UDP的53端口进行访问了。
    当然,也不是说你访问一次后这个缓存就会一直存在,通常每个运营商的缓存策略可能有所不同,不过大多数运营商的DNS缓存策略应该在10分钟左右就会时效。具体还得视实际情况而定哟~

三.家里电脑可以基于IP地址访问,但不能基于域名访问什么原因?

  你是否遇到过类似的情况呢?你发现基于IP地址是可以访问某个公网的服务器,但就是不能基于域名访问。手动指定了一个自定义的DNS地址后,发现就好使了,这是为啥呀?

  如果出现上述情况的话,很有可能就是你运营商提供的DNS服务器暂时存在问题,手动指向公网的IP地址是就好啦,下面有一系列的公网DNS,你可以自行选择:
    (1)谷歌公司(不推荐使用,因为DNS服务器在美国)提供:
        8.8.4.4
        8.8.8.8
    (2)阿里公司提供:
        223.5.5.5
        223.6.6.6
    (3)腾讯公司提供:
        119.29.29.29
    (4)移动运营商提供:
      参考链接:
        https://zhidao.baidu.com/question/356944003.html
    (5)电信运营商提供:
      114.114.114.114(江苏南京)
      219.141.136.10(北京)
      219.141.140.10(北京)
      参考链接:
        https://zhidao.baidu.com/question/1732891267435593747.html
    (6)联通运营商提供的DNS地址:
      参考链接:
        https://zhidao.baidu.com/question/988846985917716979.html
  上面我写了很多有关公网的DNS地址,你们觉得运营商提供DNS情有可原,那谷歌,腾讯,阿里为啥要提供DNS呢?
    现在是大数据时代,如果这些商业公司利用用户查询的记录,来对现有用户进行用户画像,从中可以找到相应的商机。
    当然,这也是我瞎YY的哈,可能我以小人之心度君子之腹了,但也的确不能排除没有这样的可能性啊,毕竟现在的大数据技术相对来说在互联网已经落地了,技术也相对成熟了。比如典型"大数据杀熟"事件层出不穷,还好有国家管制这一块。  
  温馨提示:
    不一定网站打不开就是DNS的问题,也有可能是出口路由策略的问题,也有可能是公司内部配置的有上网行为管理等设备设定了策略,甚至还有可能是服务端的服务本身就出问题了,具体原因我们要根据实际情况来分析哟~
目录
相关文章
|
29天前
|
存储 算法 Java
解析HashSet的工作原理,揭示Set如何利用哈希算法和equals()方法确保元素唯一性,并通过示例代码展示了其“无重复”特性的具体应用
在Java中,Set接口以其独特的“无重复”特性脱颖而出。本文通过解析HashSet的工作原理,揭示Set如何利用哈希算法和equals()方法确保元素唯一性,并通过示例代码展示了其“无重复”特性的具体应用。
41 3
|
1月前
|
存储 缓存 算法
分布式锁服务深度解析:以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中,多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性,我们需要一种机制来协调这些进程或节点的访问,避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制,确保同一时间只有一个进程或节点能够访问和操作共享资源。
67 3
|
17天前
|
域名解析 缓存 网络协议
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
|
17天前
|
算法 Java 数据库连接
Java连接池技术,从基础概念出发,解析了连接池的工作原理及其重要性
本文详细介绍了Java连接池技术,从基础概念出发,解析了连接池的工作原理及其重要性。连接池通过复用数据库连接,显著提升了应用的性能和稳定性。文章还展示了使用HikariCP连接池的示例代码,帮助读者更好地理解和应用这一技术。
31 1
|
17天前
|
安全 测试技术 数据安全/隐私保护
原生鸿蒙应用市场开发者服务的技术解析:从集成到应用发布的完整体验
原生鸿蒙应用市场开发者服务的技术解析:从集成到应用发布的完整体验
|
22天前
|
数据采集 存储 编解码
一份简明的 Base64 原理解析
Base64 编码器的原理,其实很简单,花一点点时间学会它,你就又消除了一个知识盲点。
61 3
|
4天前
|
存储 供应链 物联网
深入解析区块链技术的核心原理与应用前景
深入解析区块链技术的核心原理与应用前景
|
4天前
|
存储 供应链 安全
深度解析区块链技术的核心原理与应用前景
深度解析区块链技术的核心原理与应用前景
11 0
|
1月前
|
前端开发 Java 应用服务中间件
21张图解析Tomcat运行原理与架构全貌
【10月更文挑战第2天】本文通过21张图详细解析了Tomcat的运行原理与架构。Tomcat作为Java Web开发中最流行的Web服务器之一,其架构设计精妙。文章首先介绍了Tomcat的基本组件:Connector(连接器)负责网络通信,Container(容器)处理业务逻辑。连接器内部包括EndPoint、Processor和Adapter等组件,分别处理通信、协议解析和请求封装。容器采用多级结构(Engine、Host、Context、Wrapper),并通过Mapper组件进行请求路由。文章还探讨了Tomcat的生命周期管理、启动与停止机制,并通过源码分析展示了请求处理流程。
|
1月前
|
开发框架 缓存 前端开发
electron-builder 解析:你了解其背后的构建原理吗?
本文首发于微信公众号“前端徐徐”,详细解析了 electron-builder 的工作原理。electron-builder 是一个专为整合前端项目与 Electron 应用的打包工具,负责管理依赖、生成配置文件及多平台构建。文章介绍了前端项目的构建流程、配置信息收集、依赖处理、asar 打包、附加资源准备、Electron 打包、代码签名、资源压缩、卸载程序生成、安装程序生成及最终安装包输出等环节。通过剖析 electron-builder 的原理,帮助开发者更好地理解和掌握跨端桌面应用的构建流程。
83 2

推荐镜像

更多