搜 索

DNS 协议报文格式解析

  • 240阅读
  • 2021年11月17日
  • 0评论
首页 / 🦚TCP/IP / 正文

一、DNS 报文基础

DNS报文可以分为查询和应答,他们的总体结构是相同的。DNS的顶层格式分成5个部分:

1、首部(Header)
2、问题(Question)
3、回答(Answer)
4、权威(Authority)
5、附加(Additional)

image-20211117202404754.png

二、DNS 首部

每一类DNS报文都有一个首部部分。首部包括一些字段,用于规定其余部分是否存在,也是规定是查询还是响应,是标准查询还是其他类型的操作。

image-20211117210720834.png

(1)、Transaction ID 标识 (16bit)

(2)、Flags 标志 (16bit)

  • Response (QR) (1bit)

    • 查询/响应的标志位,0为查询 ,1为响应。
  • Opcode (4bit)

    • 操作码,定义查询或响应的类型,0则是标准的,1则是反向的,2是服务器状态请求。
  • Authoritative (AA) (1bit)

    • 授权应答,该字段在响应报文中有效。值为 1 时,表示名称服务器是权威服务器;值为 0 时,表示不是权威服务器。
  • Truncated (TC) (1bit)

    • 截断标志位。值为 1 时,表示响应已超过 512 字节并已被截断,只返回前 512 个字节。
  • Recursion desired (RD) (1bit)

    • 期望递归。该字段能在一个查询中设置,并在响应中返回。该标志告诉名称服务器必须处理这个查询,这种方式被称为一个递归查询。如果该位为 0,且被请求的名称服务器没有一个授权回答,它将返回一个能解答该查询的其他名称服务器列表。这种方式被称为迭代查询。
  • Recursion available (RA) (1bit)

    • 可用递归。该字段只出现在响应报文中。当值为 1 时,表示服务器支持递归查询。
  • Z (zero) (1bit)

    • 保留字段,在所有的请求和应答报文中,它的值必须为 0。
  • answer authenticated (AD) (1bit)

    • 应答认证:应答/权限部分未由服务器进行认证。0 为应答服务器未验证了该查询相关的 DNSSEC 数字签名。1 为应答服务器已经验证了该查询相关的 DNSSEC 数字签名。
  • Non-authenticated data (CD) (1bit)

    • 未经认证的数据:不可接受。0 为服务器已经进行了相关 DNSSEC 数字签名的验证。1为服务器并未进行相关 DNSSEC 数字签名的验证
  • Reply code (rcode) (4bit)

    • 返回码字段,表示响应的差错状态。常见返回码字段如下:

image-20211117220210437.png

(3)、Questions 问题数

(4)、Answer RRs 回答资源记录数

(5)、Authority RRs 权威资源记录数

(6)、Additional 附加资源记录数

RRs 即 Resource Records,资源记录。分别对应下面的查询问题、回答、授权和附加信息部分的数量。

在 DNS 查询请求中,一般 Questions (问题数)都为1,回答记录数、授权资源记录数和附加资源记录数都为0。

三、请求区域

image-20211117211623604.png

(1)、查询名

查询名部分长度不定,一般为要查询的域名(也会有IP的时候,即反向查询)。 此部分由一个或者多个标示符序列组成,每个标示符以首字节数的计数值来说明该标示符长度,每个名字以0结束。计数字节数必须是0~63之间。该字段无需填充字节。

(2)、查询类型

代码号码定义的 RFC描述功能
A1RFC 1035IP 地址记录传回一个 32 比特的 IPv4 地址,最常用于映射主机名称IP地址,但也用于DNSBLRFC 1101)等。
AAAA28RFC 3596IPv6 IP 地址记录传回一个 128 比特的 IPv6 地址,最常用于映射主机名称到 IP 地址。
AFSDB18RFC 1183AFS文件系统(Andrew File System)数据库核心的位置,于域名以外的 AFS 客户端常用来联系 AFS 核心。这个记录的子类型是被过时的的 DCE/DFS(DCE Distributed File System)所使用。
APL42RFC 3123地址前缀列表指定地址列表的范围,例如:CIDR 格式为各个类型的地址(试验性)。
CAA257RFC 6844权威认证授权DNS认证机构授权,限制主机/域的可接受的CA
CDNSKEY60RFC 7344子关键记录关键记录记录的子版本,用于转移到父级
CDS59RFC 7344子委托签发者委托签发者记录的子版本,用于转移到父级
CERT37RFC 4398证书记录存储 PKIXSPKIPGP等。
CNAME5RFC 1035规范名称记录一个主机名字的别名:域名系统将会继续尝试查找新的名字。
DHCID49RFC 4701DHCP(动态主机设置协议)识别码用于将 FQDN 选项结合至 DHCP
DLV32769RFC 4431DNSSEC(域名系统安全扩展)来源验证记录为不在DNS委托者内发布DNSSEC的信任锚点,与 DS 记录使用相同的格式,RFC 5074 介绍了如何使用这些记录。
DNAME39RFC 2672代表名称DNAME 会为名称和其子名称产生别名,与 CNAME 不同,在其标签别名不会重复。但与 CNAME 记录相同的是,DNS将会继续尝试查找新的名字。
DNSKEY48RFC 4034DNS 关键记录于DNSSEC内使用的关键记录,与 KEY 使用相同格式。
DS43RFC 4034委托签发者此记录用于鉴定DNSSEC已授权区域的签名密钥。
HIP55RFC 5205主机鉴定协议将端点标识符及IP 地址定位的分开的方法。
IPSECKEY45RFC 4025IPSEC 密钥IPSEC 同时使用的密钥记录。
KEY25RFC 2535[1]RFC 2930[2]关键记录只用于 SIG(0)(RFC 2931)及 TKEY(RFC 2930)。[3]RFC 3455 否定其作为应用程序键及限制DNSSEC的使用。[4]RFC 3755 指定了 DNSKEY 作为DNSSEC的代替。[5]
LOC记录(LOC record)29RFC 1876位置记录将一个域名指定地理位置。
MX记录(MX record)15RFC 1035电邮交互记录引导域名到该域名的邮件传输代理(MTA, Message Transfer Agents)列表。
NAPTR记录(NAPTR record)35RFC 3403命名管理指针允许基于正则表达式的域名重写使其能够作为 URI、进一步域名查找等。
NS2RFC 1035名称服务器记录委托DNS区域(DNS zone)使用已提供的权威域名服务器。
NSEC47RFC 4034下一代安全记录DNSSEC 的一部分 — 用来验证一个未存在的服务器,使用与 NXT(已过时)记录的格式。
NSEC350RFC 5155NSEC 记录第三版用作允许未经允许的区域行走以证明名称不存在性的 DNSSEC 扩展。
NSEC3PARAM51RFC 5155NSEC3 参数与 NSEC3 同时使用的参数记录。
OPENPGPKEY61RFC 7929OpenPGP公钥记录基于DNS的域名实体认证方法,用于使用OPENPGPKEY DNS资源记录在特定电子邮件地址的DNS中发布和定位OpenPGP公钥。
PTR12RFC 1035指针记录引导至一个规范名称(Canonical Name)。与 CNAME 记录不同,DNS“不会”进行进程,只会传回名称。最常用来运行反向 DNS 查找,其他用途包括引作 DNS-SD
RRSIG46RFC 4034DNSSEC 证书DNSSEC 安全记录集证书,与 SIG 记录使用相同的格式。
RP17RFC 1183负责人有关域名负责人的信息,电邮地址的 @ 通常写为 a
SIG24RFC 2535证书SIG(0)(RFC 2931)及 TKEY(RFC 2930)使用的证书。[5]RFC 3755 designated RRSIG as the replacement for SIG for use within DNSSEC.[5]
SOA6RFC 1035权威记录的起始指定有关DNS区域的权威性信息,包含主要名称服务器、域名管理员的电邮地址、域名的流水式编号、和几个有关刷新区域的定时器。
SPF99RFC 4408SPF 记录作为 SPF 协议的一部分,优先作为先前在 TXT 存储 SPF 数据的临时做法,使用与先前在 TXT 存储的格式。
SRV记录(SRV record)33RFC 2782服务定位器广义为服务定位记录,被新式协议使用而避免产生特定协议的记录,例如:MX 记录。
SSHFP44RFC 4255SSH 公共密钥指纹DNS 系统用来发布 SSH 公共密钥指纹的资源记录,以用作辅助验证服务器的真实性。
TA32768DNSSEC 信任当局DNSSEC 一部分无签订 DNS 根目录的部署提案,,使用与 DS 记录相同的格式[6][7]
TKEY记录(TKEY record)249RFC 2930秘密密钥记录TSIG提供密钥材料的其中一类方法,that is 在公共密钥下加密的 accompanying KEY RR。[8]
TSIG250RFC 2845交易证书用以认证动态更新(Dynamic DNS)是来自合法的客户端,或与 DNSSEC 一样是验证回应是否来自合法的递归名称服务器。[9]
TXT16RFC 1035文本记录最初是为任意可读的文本 DNS 记录。自1990年起,些记录更经常地带有机读数据,以 RFC 1464 指定:机会性加密(opportunistic encryption)、Sender Policy Framework(虽然这个临时使用的 TXT 记录在 SPF 记录推出后不被推荐)、DomainKeys、DNS-SD等。
URI256RFC 7553统一资源标识符可用于发布从主机名到URI的映射。

其他类型及伪资源记录

其他类型的资源记录简单地提供一些类型的消息(如:HINFO 记录提供电脑或操作系统的类型),或传回实验中之功能的数据。“type”字段也使用于其他协议作各种操作。

代码号码定义的 RFC描述功能
*255RFC 1035所有缓存的记录传回所有服务器已知类型的记录。如果服务器未有任何关于名称的记录,该请求将被转发。而传回的记录未必完全完成,例如:当一个名称有 A 及 MX 类型的记录时,但服务器已缓存了 A 记录,就只有 A 记录会被传回。
AXFR252RFC 1035全域转移由主域名服务器转移整个区域文件至二级域名服务器。
IXFR251RFC 1995增量区域转移请求只有与先前流水式编号不同的特定区域的区域转移。此请求有机会被拒绝,如果权威服务器由于配置或缺乏必要的数据而无法履行请求,一个完整的(AXFR)会被发送以作回应。
OPT41RFC 2671选项这是一个“伪 DNS记录类型”以支持 EDNS

(3)、查询类

一般为IN ,即 Internet数据.

四、资源记录(RR)区域

image-20211117212551579.png

该区域有三个,但格式都是一样的。这三个区域分别是:回答区域,授权区域和附加区域。

(1) 域名NAME(2字节或不定长):它的格式和Queries区域的查询名字字段是一样的。有一点不同就是,当报文中域名重复出现的时候,该字段使用2个字节的偏移指针来表示。比如,在资源记录中,域名通常是查询问题部分的域名的重复,因此用2字节的指针来表示,具体格式是最前面的两个高位是 11,用于识别指针。其余的14位从DNS报文的开始处计数(从0开始),指出该报文中的相应字节数。

(2) 查询类型TYPE :表明资源纪录的类型,指出RDATA数据的含义。

(3)查询类CLASS :对于Internet信息,总是1,代表IN。表示RDATA的类。

(4)生存时间(TTL):4字节无符号整数表示资源记录可以缓存的时间。以秒为单位,表示的是资源记录的生命周期,一般用于当地址解析程序取出资源记录后决定保存及使用缓存数据的时间,它同时也可以表明该资源记录的稳定程度,极为稳定的信息会被分配一个很大的值(比如86400,这是一天的秒数)。0代表只能被传输,但是不能被缓存。TTL 是 DNS 记录中的一个值,可决定对该记录所做的后续更改需要多少秒才会生效。网域的每条 DNS 记录(如 MX 记录、CNAME 记录等)都有一个 TTL 值。一条记录目前所设的 TTL 决定了您现在所做的任何更改需要多久才会生效。例如,如果一条记录的 TTL 为 86400 秒,则对该记录的更改最多需要 24 小时才会生效。请注意,更改记录的 TTL 会影响之后的所有更改需要多久才会生效。我们建议将 TTL 值设置为 3600,即让整个互联网中的服务器每小时检查一次该记录的更新情况。较短的 TTL 在之前的有效期到期后才会生效。这意味着,下次更新该记录时,您的更改最多要一个小时才会生效。要使后续的更改更快生效(例如,如果您想快速还原一项更改),则可以设置较短的 TTL 值,如 300 秒(5 分钟)。正确配置记录后,我们建议将 TTL 值设置为 86400,即让整个互联网中的服务器每 24 小时检查一次记录的更新情况。

(5) 资源数据长度LENGTH:2个字节无符号整数表示RDATA的长度

(6)资源数据 RDATA : 该字段是一个可变长字段,不定长字符串来表示记录,格式与TYPE和CLASS有关。比如,TYPE是A,CLASS 是 IN,那么RDATA就是一个4个字节的ARPA网络地址。表示按照查询段的要求返回的相关资源记录的数据。可以是Address(表明查询报文想要的回应是一个IP地址)或者CNAME(表明查询报文想要的回应是一个规范主机名)等。

五、参考文档

感谢以下大佬文章支持!!!

参考链接:https://blog.csdn.net/answer3lin/article/details/84638845
参考连接:https://blog.csdn.net/weixin_45975575/article/details/115561913

DNS
打 赏
  • 微信
WeChatPay
评论区
暂无评论
avatar