DNS服务工作原理

简介: 文章详细介绍了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的问题,也有可能是出口路由策略的问题,也有可能是公司内部配置的有上网行为管理等设备设定了策略,甚至还有可能是服务端的服务本身就出问题了,具体原因我们要根据实际情况来分析哟~
目录
相关文章
|
运维 持续交付 云计算
深入解析云计算中的微服务架构:原理、优势与实践
深入解析云计算中的微服务架构:原理、优势与实践
870 86
|
安全 算法 网络协议
解析:HTTPS通过SSL/TLS证书加密的原理与逻辑
HTTPS通过SSL/TLS证书加密,结合对称与非对称加密及数字证书验证实现安全通信。首先,服务器发送含公钥的数字证书,客户端验证其合法性后生成随机数并用公钥加密发送给服务器,双方据此生成相同的对称密钥。后续通信使用对称加密确保高效性和安全性。同时,数字证书验证服务器身份,防止中间人攻击;哈希算法和数字签名确保数据完整性,防止篡改。整个流程保障了身份认证、数据加密和完整性保护。
|
弹性计算 运维 安全
优化管理与服务:操作系统控制平台的订阅功能解析
本文介绍了如何通过操作系统控制平台提升系统效率,优化资源利用。首先,通过阿里云官方平台开通服务并安装SysOM组件,体验操作系统控制平台的功能。接着,详细讲解了订阅管理功能,包括创建订阅、查看和管理ECS实例的私有YUM仓库权限。订阅私有YUM仓库能够集中管理软件包版本、提升安全性,并提供灵活的配置选项。最后总结指出,使用阿里云的订阅和私有YUM仓库功能,可以提高系统可靠性和运维效率,确保业务顺畅运行。
|
存储 缓存 算法
HashMap深度解析:从原理到实战
HashMap,作为Java集合框架中的一个核心组件,以其高效的键值对存储和检索机制,在软件开发中扮演着举足轻重的角色。作为一名资深的AI工程师,深入理解HashMap的原理、历史、业务场景以及实战应用,对于提升数据处理和算法实现的效率至关重要。本文将通过手绘结构图、流程图,结合Java代码示例,全方位解析HashMap,帮助读者从理论到实践全面掌握这一关键技术。
509 14
|
网络协议 安全 Devops
Infoblox DDI (NIOS) 9.0 - DNS、DHCP 和 IPAM (DDI) 核心网络服务管理
Infoblox DDI (NIOS) 9.0 - DNS、DHCP 和 IPAM (DDI) 核心网络服务管理
540 4
|
机器学习/深度学习 算法 数据挖掘
解析静态代理IP改善游戏体验的原理
静态代理IP通过提高网络稳定性和降低延迟,优化游戏体验。具体表现在加快游戏网络速度、实时玩家数据分析、优化游戏设计、简化更新流程、维护网络稳定性、提高连接可靠性、支持地区特性及提升访问速度等方面,确保更流畅、高效的游戏体验。
350 22
解析静态代理IP改善游戏体验的原理
|
机器学习/深度学习 数据可视化 PyTorch
深入解析图神经网络注意力机制:数学原理与可视化实现
本文深入解析了图神经网络(GNNs)中自注意力机制的内部运作原理,通过可视化和数学推导揭示其工作机制。文章采用“位置-转移图”概念框架,并使用NumPy实现代码示例,逐步拆解自注意力层的计算过程。文中详细展示了从节点特征矩阵、邻接矩阵到生成注意力权重的具体步骤,并通过四个类(GAL1至GAL4)模拟了整个计算流程。最终,结合实际PyTorch Geometric库中的代码,对比分析了核心逻辑,为理解GNN自注意力机制提供了清晰的学习路径。
888 7
深入解析图神经网络注意力机制:数学原理与可视化实现
|
编解码 缓存 Prometheus
「ximagine」业余爱好者的非专业显示器测试流程规范,同时也是本账号输出内容的数据来源!如何测试显示器?荒岛整理总结出多种测试方法和注意事项,以及粗浅的原理解析!
本期内容为「ximagine」频道《显示器测试流程》的规范及标准,我们主要使用Calman、DisplayCAL、i1Profiler等软件及CA410、Spyder X、i1Pro 2等设备,是我们目前制作内容数据的重要来源,我们深知所做的仍是比较表面的活儿,和工程师、科研人员相比有着不小的差距,测试并不复杂,但是相当繁琐,收集整理测试无不花费大量时间精力,内容不完善或者有错误的地方,希望大佬指出我们好改进!
1226 16
「ximagine」业余爱好者的非专业显示器测试流程规范,同时也是本账号输出内容的数据来源!如何测试显示器?荒岛整理总结出多种测试方法和注意事项,以及粗浅的原理解析!
|
机器学习/深度学习 缓存 自然语言处理
深入解析Tiktokenizer:大语言模型中核心分词技术的原理与架构
Tiktokenizer 是一款现代分词工具,旨在高效、智能地将文本转换为机器可处理的离散单元(token)。它不仅超越了传统的空格分割和正则表达式匹配方法,还结合了上下文感知能力,适应复杂语言结构。Tiktokenizer 的核心特性包括自适应 token 分割、高效编码能力和出色的可扩展性,使其适用于从聊天机器人到大规模文本分析等多种应用场景。通过模块化设计,Tiktokenizer 确保了代码的可重用性和维护性,并在分词精度、处理效率和灵活性方面表现出色。此外,它支持多语言处理、表情符号识别和领域特定文本处理,能够应对各种复杂的文本输入需求。
1588 6
深入解析Tiktokenizer:大语言模型中核心分词技术的原理与架构
|
机器学习/深度学习 自然语言处理 搜索推荐
自注意力机制全解析:从原理到计算细节,一文尽览!
自注意力机制(Self-Attention)最早可追溯至20世纪70年代的神经网络研究,但直到2017年Google Brain团队提出Transformer架构后才广泛应用于深度学习。它通过计算序列内部元素间的相关性,捕捉复杂依赖关系,并支持并行化训练,显著提升了处理长文本和序列数据的能力。相比传统的RNN、LSTM和GRU,自注意力机制在自然语言处理(NLP)、计算机视觉、语音识别及推荐系统等领域展现出卓越性能。其核心步骤包括生成查询(Q)、键(K)和值(V)向量,计算缩放点积注意力得分,应用Softmax归一化,以及加权求和生成输出。自注意力机制提高了模型的表达能力,带来了更精准的服务。
13844 46

热门文章

最新文章

推荐镜像

更多
  • DNS