RH358管理DNS和DNS服务器--DNS服务概述

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: RH358管理DNS和DNS服务器--DNS服务概述

RH358管理DNS和DNS服务器–DNS服务概述

本章节开始,介绍DNS相关。DNS在日常工作中一定会接触到的技术,还是得有一定的了解。

专栏地址:https://blog.csdn.net/qq_41765918/category_11532281.html


DNS 是一个分布式数据库,命名系统采用层次的逻辑结构,如同一棵倒置的树,这个逻辑的树形结构称为域名空间,由于DNS 划分了域名空间,所以各机构可以使用自己的域名空间创建DNS信息,如图所示。

注:DNS 域名空间中,树的最大深度不得超过127 层,树中每个节点最长可以存储63 个字符。

image-20211217161732893

DNS树形结构示意图

1. 域和域名

DNS 树的每个节点代表一个域,通过这些节点,对整个域名空间进行划分,成为一个层次结构。域名空间的每个域的名字,通过域名进行表示。

域名:通常由一个完全合格域名(FQDN完全限定域名(Fully Qualified Domain Name))标识。FQDN能准确表示出其相对于DNS 域树根的位置,也就是节点到DNS 树根的完整表述方式,从节点到树根采用反向书写,并将每个节点用“.”分隔,对于DNS 域google 来说,其完全正式域名(FQDN)为google.com。

例如,google为com域的子域,其表示方法为google.com,而www为google域中的子域,可以使用www.google.com表示。

注意:通常,FQDN 有严格的命名限制,长度不能超过256 字节,只允许使用字符a-z,0-9,A-Z

和减号(-)。点号(.)只允许在域名标志之间(例如“google.com”)或者FQDN 的结尾使用。域名不区分大小,由最顶层到下层,可以分成:根域、顶级域、二级域、子域。

Internet 域名空间的最顶层是根域(root),其记录着Internet 的重要DNS 信息,由Internet域名注册授权机构管理,该机构把域名空间各部分的管理责任分配给连接到Internet 的各个组织,“.”全球有13个根(root)服务器。

DNS 根域下面是顶级域,也由Internet 域名注册授权机构管理。共有3 种类型的顶级域。

组织域:采用3个字符的代号,表示DNS 域中所包含的组织的主要功能或活动。比如com 为商业机构组织,edu 为教育机构组织,gov 为政府机构组织,mil 为军事机构组织,net 为网络机构组织,org 为非营利机构组织,int 为国际机构组织。

地址域:采用两个字符的国家或地区代号。如cn 为中国,kr 为韩国,us 为美国。

反向域:这是个特殊域,名字为in-addr.arpa,用于将IP 地址映射到名字(反向查询)。

对于顶级域的下级域,Internet 域名注册授权机构授权给 Internet 的各种组织。当一个组织获得了对域名空间某一部分的授权后,该组织就负责命名所分配的域及其子域,包括域中的计算机和其他设备,并管理分配的域中主机名与 IP 地址的映射信息。

  • 根域: 全球根服务器节点只有13个,10个在美国,1个荷兰,1个瑞典,1个日本

  • 一级域名:Top Level Domain: tld

    三类:组织域、国家域(.cn, .ca, .hk, .tw)、反向域com, edu, mil, gov, net, org, int,arpa

  • 二级域名:abc.com

  • 三级域名:study.abc.com

  • 最多可达到127级域名

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

2. 区(Zone)

区是DNS 名称空间的一部分,其包含了一组存储在 DNS 服务器上的资源记录。

使用区的概念,DNS 服务器回答关于自己区中主机的查询,每个区都有自己的授权服务器。

3. 主域名服务器与辅助域名服务器

当区的辅助服务器启动时,它与该区的主控服务器进行连接并启动一次区传输,区辅助服务器定期与区主控服务器通信,查看区数据是否改变。如果改变了,它就启动一次数据更新传输。

每个区必须有主服务器,另外每个区至少要有一台辅助服务器,否则如果该区的主服务器崩溃了,就无法解析该区的名称。

辅助服务器的优点:

(1) 容错能力

配置辅助服务器后,在该区主服务器崩溃的情况下,客户机仍能解析该区的名称。一般把区的主服务器和区的辅助服务器安装在不同子网上,这样如果到一个子网的连接中断,DNS 客户机还能直接查询另一个子网上的名称服务器。

(2) 减少广域链路的通信量

如果某个区在远程有大量客户机,用户就可以在远程添加该区的辅助服务器,并把远程的客户机配置成先查询这些服务器,这样就能防止远程客户机通过慢速链路通信来进行DNS 查询。

(3) 减轻主服务器的负载

辅助服务器能回答该区的查询,从而减少该区主服务器必须回答的查询数。

4. DNS 相关概念

(1)DNS 服务器

运行DNS 服务器程序的计算机,储存DNS 数据库信息。DNS 服务器会尝试解析客户机的查询请求。在解答查询时,如果DNS 服务器能提供所请求的信息,就直接回应解析结果,如果该DNS 服务器没有相应的域名信息,则为客户机提供另一个能帮助解析查询的服务器地址,如果以上两种方法均失败,则回应客户机没有所请求的信息或请求的信息不存在。

(2)DNS 缓存

DNS 服务器在解析客户机请求时,如果本地没有该DNS 信息,则可以会询问其他DNS 服务器,当其他域名服务器返回查询结果时,该DNS 服务器会将结果记录在本地的缓存中,成为DNS 缓存。当下一次客户机提交相同请求时,DNS 服务器能够直接使用缓存中的DNS 信息进行解析。

(3)DNS查询方式:递归查询和迭代查询

一个DNS查询过程,通过8个步骤的解析过程就使得客户端可以顺利访问www.163.com 这个域名,但实际应用中,通常这个过程是非常迅速的,如图所示。

DNS查询过程示意图

<1> 客户机提交域名解析请求,并将该请求发送给本地的域名服务器。

<2> 当本地的域名服务器收到请求后,就先查询本地的缓存。如果有查询的DNS 信息记录,则直接返回查询的结果。如果没有该记录,本地域名服务器就把请求发给根域名服务器。

<3> 根域名服务器再返回给本地域名服务器一个所查询域的顶级域名服务器的地址。

<4> 本地服务器再向返回的域名服务器发送请求。

<5> 接收到该查询请求的域名服务器查询其缓存和记录,如果有相关信息则返回客户机查询结果,否则通知客户机下级的域名服务器的地址。

<6> 本地域名服务器将查询请求发送给返回的DNS 服务器。

<7> 域名服务器返回本地服务器查询结果(如果该域名服务器不包含查询的DNS 信息,查询过程将重复<6>、<7>步骤,直到返回解析信息或解析失败的回应。

<8> 本地域名服务器将返回的结果保存到缓存,并且将结果返回给客户机。

5. 两种查询方式:

(1)递归查询

递归查询是一种DNS 服务器的查询模式,在该模式下DNS 服务器接收到客户机请求,必须使用一个准确的查询结果回复客户机。如果DNS 服务器本地没有存储查询DNS 信息,那么该服务器会询问其他服务器,并将返回的查询结果提交给客户机。

(2)迭代查询

DNS 服务器另外一种查询方式为迭代查询,当客户机发送查询请求时,DNS 服务器并不直接回复查询结果,而是告诉客户机另一台DNS 服务器地址,客户机再向这台DNS 服务器提交请求,依次循环直到返回查询的结果为止。

6. 正向解析与反向解析

正向解析:

正向解析是指域名到IP 地址的解析过程,如图所示。

image-20211217163030984

反向解析:

反向解析是从IP 地址到域名的解析过程。反向解析的作用为服务器的身份验证,如图所示。

http://dns.aizhan.com/

反向解析域名

7. DNS资源记录

区域解析库:由众多资源记录RR(Resource Record)组成

记录类型:A, AAAA, PTR, SOA, NS, CNAME, MX

  • SOA:Start Of Authority,起始授权记录;一个区域解析库有且仅能有一个SOA记录,必须位于解析库的第一条记录

  • A:internet Address,作用,FQDN --> IP

  • AAAA:FQDN --> IPv6

  • PTR:PoinTeR,IP --> FQDN

  • NS:Name Server,专用于标明当前区域的DNS服务器

  • CNAME : Canonical Name,别名记录

  • MX:Mail eXchanger,邮件交换器

  • TXT:对域名进行标识和说明的一种方式,一般做验证记录时会使用此项,如:SPF(反垃圾邮件)记录,https验证等,如下示例:

    _dnsauth TXT 2012011200000051qgs69bwoh4h6nht4n1h0lr038x
    

资源记录定义的格式

name      [TTL]    IN   rr_type   value

注意:

  1. TTL可从全局继承

  2. 使用 “@” 符号可用于引用当前区域的名字

  3. 同一个名字可以通过多条记录定义多个不同的值;此时DNS服务器会以轮询方式响应

  4. 同一个值也可能有多个不同的定义名字;通过多个不同的名字指向同一个值进行定义;此仅表示通过多个不同的名字可以找到同一个主机

1.SOA 资源记录

每个区在区的开始处都包含了一个起始授权记录(Start of Authority Record),简称SOA 记录。SOA 定义了域的全局参数,进行整个域的管理设置。一个区域文件只允许存在唯一的SOA 记录。

name: 当前区域的名字,例如“fish.org.”

value: 有多部分组成

注意:

  1. 当前区域的主DNS服务器的FQDN,也可以使用当前区域的名字

  2. 当前区域管理员的邮箱地址;但地址中不能使用@符号,一般用 . 替换,例如:admin.fish.org

  3. 主从服务区域传输相关定义以及否定的答案的统一的TTL

范例:

fish.org. 86400 IN SOA ns.fish.org. nsadmin.fish.org. (
         2015042201 ;  序列号
         2H ;           刷新时间
         10M ;         重试时间
         1W ;          过期时间
         1D ;           否定答案的TTL值
         )

2.NS 资源记录

NS(Name Server)记录是域名服务器记录,用来指定该域名由哪个DNS服务器来进行解析。每个区在区根处至少包含一个NS 记录。

name: 当前区域的名字

value: 当前区域的某DNS服务器的名字,例如ns.fish.org.

注意:

  1. 相邻的两个资源记录的name相同时,后续的可省略

  2. 对NS记录而言,任何一个ns记录后面的服务器名字,都应该在后续有一个A记录

  3. 一个区域可以有多个NS记录

范例:

fish.org.  IN  NS  ns1.fish.org.
fish.org.  IN  NS  ns2.fish.org.

3.A 资源记录

地址(A)资源记录把FQDN 映射到IP 地址。 因为有此记录,所以DNS服务器能解析FQDN域名对应的IP 地址。

name: 某主机的FQDN,例如:www.fish.org.

value: 主机名对应主机的IP地址

避免用户写错名称时给错误答案,可通过泛域名解析进行解析至某特定地址

范例:

www.fish.org.             IN     A   1.1.1.1
www.fish.org.             IN     A   2.2.2.2
mx1.fish.org.             IN     A   3.3.3.3
mx2.fish.org.             IN     A   4.4.4.4
$GENERATE 1-254 HOST$     IN     A   1.2.3.$
*.fish.org.               IN     A   5.5.5.5
fish.org.                 IN     A   6.6.6.6

例如在阿里云:

4.PTR 资源记录

相对于A 资源记录,指针(PTR)记录把IP地址映射到FQDN。 用于反向查询,通过IP地址,找到域名。

name: IP,有特定格式,把IP地址反过来写,1.2.3.4,要写作4.3.2.1;而有特定后缀:inaddr.arpa.,所以完整写法为:4.3.2.1.in-addr.arpa.

value: FQDN

注意:网络地址及后缀可省略;主机地址依然需要反着写

例如:

4.3.2.1.in-addr.arpa.  IN  PTR  www.fish.org.
#如1.2.3为网络地址,可简写成:
4  IN  PTR  www.fish.org.

5.CNAME 资源记录

别名记录(CNAME)资源记录创建特定FQDN 的别名。用户可以使用CNAME 记录来隐藏用户网络的实现细节,使连接的客户机无法知道真正的域名。

例:ping百度时,解析到了百度的别名服务器。百度cname=www.wshifen.com的别名,如图所示。

image-20211217164429098

name: 别名的FQDN

value: 真正名字的FQDN

例如:

www.fish.org.  IN  CNAME  websrv.fish.org.

6.MX 资源记录

邮件交换(MX)资源记录,为DNS 域名指定邮件交换服务器,邮件交换服务器是为DNS 域名处理或转发邮件的主机。处理邮件指把邮件投递到目的地或转交另一不同类型的邮件传送者。转发邮件指把邮件发送到最终目的服务器,用简单邮件传输协议SMTP 把邮件发送给离最终目的地最近的邮件交换服务器,或使邮件经过一定时间的排队。

name: 当前区域的名字

value: 当前区域的某邮件服务器(smtp服务器)的主机名

注意:

  1. 一个区域内,MX记录可有多个;但每个记录的value之前应该有一个数字(0-99),表示此服务器的优先级;数字越小优先级越高

  2. 对MX记录而言,任何一个MX记录后面的服务器名字,都应该在后续有一个A记录

范例:

fish.org.   IN   MX  10   mx1.fish.org.
            IN   MX  20   mx2.fish.org.

7.AAAA记录

将主机名(或域名)指向一个IPv6地址(例如:ff03:0:0:0:0:0:0:c1),需要添加AAAA记录。

DNS的模式: C/S 模式

NDS监听的端口号:

# vim /etc/services #查看services文件。

端口:

tcp/53   udp/53     # 用于客户端查询
tcp/953  udp/953    # 用于DNS主从同步

总结

  • 介绍DNS的相关概念和名词。
  • DNS两种查询方式:递归查询和迭代查询。
  • 介绍DNS的正向解析和反向解析。
  • 了解DNS常用资源记录。
  • 若喜欢金鱼哥的文章,顺手点个赞。也可点个关注,因为后续会不断上干货。

目录
相关文章
|
16天前
|
弹性计算 监控 负载均衡
|
1月前
|
存储 缓存 算法
分布式锁服务深度解析:以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中,多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性,我们需要一种机制来协调这些进程或节点的访问,避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制,确保同一时间只有一个进程或节点能够访问和操作共享资源。
68 3
|
1月前
|
Prometheus Kubernetes 监控
k8s部署针对外部服务器的prometheus服务
通过上述步骤,您不仅成功地在Kubernetes集群内部署了Prometheus,还实现了对集群外服务器的有效监控。理解并实施网络配置是关键,确保监控数据的准确无误传输。随着监控需求的增长,您还可以进一步探索Prometheus生态中的其他组件,如Alertmanager、Grafana等,以构建完整的监控与报警体系。
121 60
|
1月前
|
Prometheus Kubernetes 监控
k8s部署针对外部服务器的prometheus服务
通过上述步骤,您不仅成功地在Kubernetes集群内部署了Prometheus,还实现了对集群外服务器的有效监控。理解并实施网络配置是关键,确保监控数据的准确无误传输。随着监控需求的增长,您还可以进一步探索Prometheus生态中的其他组件,如Alertmanager、Grafana等,以构建完整的监控与报警体系。
210 62
|
14天前
|
弹性计算 人工智能 数据安全/隐私保护
【手把手教你】如何免费畅快使用阿里云ECS搭建私有Overleaf论文写作服务
本文详细介绍如何利用阿里云ECS免费搭建私有Overleaf论文写作服务,包括ECS服务器的部署、Overleaf服务的安装、TexLive包的更新、XeLaTeX修复、中文字体支持及账号管理等步骤。通过这些操作,你可以实现免费且高效的多人协作论文写作,避免付费版本的高昂费用。适合需要频繁合作撰写论文的团队使用。
50 1
【手把手教你】如何免费畅快使用阿里云ECS搭建私有Overleaf论文写作服务
|
18天前
|
域名解析 缓存 网络协议
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
|
20天前
|
Linux 数据库
Linux服务如何实现服务器重启后的服务延迟自启动?
【10月更文挑战第25天】Linux服务如何实现服务器重启后的服务延迟自启动?
87 3
|
19天前
|
安全 测试技术 数据安全/隐私保护
原生鸿蒙应用市场开发者服务的技术解析:从集成到应用发布的完整体验
原生鸿蒙应用市场开发者服务的技术解析:从集成到应用发布的完整体验
|
25天前
|
监控 网络协议 安全
DNS服务器故障不容小觑,从应急视角谈DNS架构
DNS服务器故障不容小觑,从应急视角谈DNS架构
46 4
|
1月前
|
网络安全 Docker 容器
【Bug修复】秒杀服务器异常,轻松恢复网站访问--从防火墙到Docker服务的全面解析
【Bug修复】秒杀服务器异常,轻松恢复网站访问--从防火墙到Docker服务的全面解析
26 0

相关产品

  • 云解析DNS
  • 推荐镜像

    更多