必知的技术知识:DNS资源纪录(ResourceRecord)介绍

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 必知的技术知识:DNS资源纪录(ResourceRecord)介绍

类型 SOA NS A AAAA PTR CNAME MX ----------------------------------------- SOA设定内容说明 Serial Refresh Retry Expire Minimum -----------------------------------------


DNS server内的每一个网域名称都有自己的档案,这个档案一般会称为区域档案(zone file),例如之前所提到的”named.ca”或”named.local” 档案…等等。 区域档案是由多个记录组成的,每一个记录称为资源记录(Resource Record,简称RR)。 当在设定DNS名称解析、反向解析及其他的管理目的时,您需要使用不同类型的RR,底下将介绍常用的RR类型及表示法。


记录类型


代码号码定义的 RFC描述功能


A


1


RFC 1035


IP 地址记录


传回一个 32 比特的 IPv4 地址,最常用于映射主机名称到 IP地址,但也用于DNSBL(RFC 1101)等。


AAAA


28


RFC 3596


IPv6 IP 地址记录


传回一个 12//代码效果参考:http://www.jhylw.com.cn/431833809.html

8 比特的 IPv6 地址,最常用于映射主机名称到 IP 地址。

AFSDB


18


RFC 1183


AFS文件系统


(Andrew File System)数据库核心的位置,于域名以外的 AFS 客户端常用来联系 AFS 核心。这个记录的子类型是被过时的的 DCE/DFS(DCE Distributed File System)所使用。


APL


42


RFC 3123


地址前缀列表


指定地址列表的范围,例如:CIDR 格式为各个类型的地址(试验性)。


CERT


37


RFC 4398


证书记录


存储 PKIX、SPKI、PGP等。


CNAME


5


RFC 1035


规范名称记录


一个主机名字的别名:域名系统将会继续尝试查找新的名字。


DHCID


49


RFC 4701


DHCP(动态主机设置协议)识别码


用于将 FQDN 选项结合至 DHCP。


DLV


32769


RFC 4431


DNSSEC(域名系统安全扩展)来源验证记录


为不在DNS委托者内发布DNSSEC的信任锚点,与 DS 记录使用相同的格式,RFC 5074 介绍了如何使用这些记录。


DNAME


39


RFC 2672


代表名称


DNAME 会为名称和其子名称产生别名,与 CNAME 不同,在其标签别名不会重复。但与 CNAME 记录相同的是,DNS将会继续尝试查找新的名字。


DNSKEY


48


RFC 4034


DNS 关键记录


于DNSSEC内使用的关键记录,与 KEY 使用相同格式。


DS


43


RFC 4034


委托签发者


此记录用于鉴定DNSSEC已授权区域的签名密钥。


HIP


55


RFC 5205


主机鉴定协议


将端点标识符及IP 地址定位的分开的方法。


IPSECKEY


45


RFC 4025


IPSEC 密钥


与 IPSEC 同时使用的密钥记录。


KEY


25


RFC 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)


29


RFC 1876


位置记录


将一个域名指定地理位置。


MX记录(MX record)


15


RFC 1035


电邮交互记录


引导域名到该域名的邮件传输代理(MTA, Message Transfer Agents)列表。


NAPTR记录(NAPTR record)


35


RFC 3403


命名管理指针


允许基于正则表达式的域名重写使其能够作为 URI、进一步域名查找等。


NS


2


RFC 1035


名称服务器记录


委托DNS区域(DNS zone)使用已提供的权威域名服务器。


NSEC


47


RFC 4034


下一代安全记录


DNSSEC 的一部分 — 用来验证一个未存在的服务器,使用与 NXT(已过时)记录的格式。


NSEC3


50


RFC 5155


NSEC 记录第三版


用作允许未经允许的区域行走以证明名称不存在性的 DNSSEC 扩展。


NSEC3PARAM


51


RFC 5155


NSEC3 参数


与 NSEC3 同时使用的参数记录。


PTR


12


RFC 1035


指针记录


引导至一个规范名称(Canonical Name)。与 CNAME 记录不同,DNS“不会”进行进程,只会传回名称。最常用来运行反向 DNS 查找,其他用途包括引作 DNS-SD。


RRSIG


46


RFC 4034


DNSSEC 证书


DNSSEC 安全记录集证书,与 SIG 记录使用相同的格式。


RP


17


RFC 1183


负责人


有关域名负责人的信息,电邮地址的 @ 通常写为 a。


SIG


24


RFC 2535


证书


SIG(0)(RFC 2931)及 TKEY(RFC 2930)使用的证书。【5】RFC 3755 designated RRSIG as the replacement for SIG for use within DNSSEC.【5】


SOA


6


RFC 1035


权威记录的起始


指定有关DNS区域的权威性信息,包含主要名称服务器、域名管理员的电邮地址、域名的流水式编号、和几个有关刷新区域的定时器。


SPF


99


RFC 4408


SPF 记录


作为 SPF 协议的一部分,优先作为先前在 TXT 存储 SPF 数据的临时做法,使用与先前在 TXT 存储的格式。


SRV记录(SRV record)


33


RFC 2782


服务定位器


广义为服务定位记录,被新式协议使用而避免产生特定协议的记录,例如:MX 记录。


SSHFP


44


RFC 4255


SSH 公共密钥指纹


DNS 系统用来发布 SSH 公共密钥指纹的资源记录,以用作辅助验证服务器的真实性。


TA


32768



DNSSEC 信任当局


DNSSEC 一部分无签订 DNS 根目录的部署提案,,使用与 DS 记录相同的格式【6】【7】。


TKEY记录(TKEY record)


249


RFC 2930


秘密密钥记录


为TSIG提供密钥材料的其中一类方法,that is 在公共密钥下加密的 accompanying KEY RR。【8】


TSIG


250


RFC 2845


交易证书


用以认证动态更新(Dynamic DNS)是来自合法的客户端,或与 DNSSEC 一样是验证回应是否来自合法的递归名称服务器。【9】


TXT


16


RFC 1035


文本记录


最初是为任意可读的文本 DNS 记录。自1990年起,些记录更经常地带有机读数据,以 RFC 1464 指定:opportunistic encryption、Sender Policy Framework(虽然这个临时使用的 TXT 记录在 SPF 记录推出后不被推荐)、DomainKeys、DNS-SD等。


其他类型及伪资源记录


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


代码号码定义的 RFC描述功能


*


255


RFC 1035


所有缓存的记录


传回所有服务器已知类型的记录。如果服务器未有任何关于名称的记录,该请求将被转发。而传回的记录未必完全完成,例如:当一个名称有 A 及 MX 类型的记录时,但服务器已缓存了 A 记录,就只有 A 记录会被传回。


AXFR


252


RFC 1035


全域转移


由主域名服务器转移整个区域文件至二级域名服务器。


IXFR


251


RFC 1995


增量区域转移


请求只有与先前流水式编号不同的特定区域的区域转移。此请求有机会被拒绝,如果权威服务器由于配置或缺乏必要的数据而无法履行请求,一个完整的(AXFR)会被发送以作回应。


OPT


41


RFC 2671


选项


这是一个“伪 DNS记录类型”以支持 EDNS。


类型


SOA


Start Of Authority,这种record 放在zone file 一开始的地方,每一个记录档只能有一个SOA,而且一定是档案中第一个“记录”,它描述这个zone 负责的name server,version number…等资料,以及当slave server 要备份这个zone 时的一些参数。 紧接在SOA 后面指定了这个区域的授权主机和管理者的信箱,这里分别是"school.edu.tw" 和" root.school.edu.tw",也就是school.edu.tw主机和root 的信箱。 这里要注意的是我们以"root.school.edu.tw"代表"root@school.edu.tw"


eg


@ IN SOA school.edu.tw. root.school.edu.tw. (


1999051401 ; Serial


3600 ; Refresh


300 ; Retry


3600000 ; Expire


3600 ) ; Minimum


在两个括号中间的选项表示SOA的设定内容,底下会有更详细的说明。


NS


name server,用来指定操作的DNS伺服器主机名称,需注意的是不可以IP位址表示。


eg


IN NS dns.twnic.net.tw.


A


address,将DNS网域名称对应到IPv4的32位元位址。


eg


server IN A 140.123.102.10


AAAA


可将DNS网域名称对应到IPv6的128位元位址。


eg


twnic.net.tw. 86400 IN AAAA 3ffe: :bbb:93:5


PTR


pointer,定义某个IP 对应的domain name,即将IP 位址转换成主机的FQDN。


eg


20 IN PTR mail.twnic.net.tw.


CNAME


canonical name,可为同一部主机设定许多别名,例如mix.twnic.net.tw的别名可为和ftp.twnic.net.tw,因此所设定的别名都会连至同一部伺服器。


eg


www IN CNAME mix


MX


mail exchanger,设定区域中担任邮件伺服器的主机,所有要送往那部机器的mail 都要经过mail exchanger 转送。 而数字则是该主机邮件传递时的优先次序,此值越低表示有越高的邮件处理优先权。


eg


server IN MX 10 mail.twnic.net.tw.


SOA设定内容说明


SOA record,以之前例子来看,其中@ 这个符号是缩写,代表named.conf 中这个zone file 所对应的zone。 SOA 后面的两个参数是指这个zone file 是在哪部主机(school.edu.tw)定义的,以及这个zone file 的负责人(注意是写成root.school.edu.tw),然后是用括号括起来的5 个参数, 分别由底下说明。


Serial


代表这个zone file 的版本,每当zone file 内容有变动,name server 管理者就应该增加这个号码,因为slave 会将这个号码与其copy 的那份比对以便决定是否要再copy 一次(即进行zone transfer )。


Refresh


slave server 每隔这段时间(秒),就会检查master server 上的serial number。 不 过这里会发生一个问题就是,在master server 在update data 完成到slave server 来检查时再update 可能还有 好一段时间,因此这段期间master/slave DNS server间zone files 就可能出现不一致。 所 以在Bind较新的版本中便加入"notify"功能,使用者在"named.conf" 设定中在需要的zone 中加入"notify"的设定,则master server在update 完成某个zone file 的data 后便会主动发个讯息(NOTIFY),借以通知该其它的slave servers,因此如果slave servers 也有支援这个"notify"功能时,接下来slave servers 马上就可以做zone transfer 来update data。


eg


zone "twnic.com.tw" {


type master;


file "twnic.hosts";


notify yes;


also-notify { 192.168.10.1; }; //指定slave server的IP位址};


Retry


当slave server 无法和master 进行serial check时,要每隔几秒retry 一次。


Expire


当时间超过Expire 所定的秒数而slave server 都无法和master 取得连络,那么slave 会删除自己的这份copy。


Minimum


代表这个zone file 中所有record 的内定的TTL 值,也就是其它的DNS server cache 这笔record 时,最长不应该超过这个时间。


资源记录参考


(WS.10).aspx


更新时间: 2005年1月


应用到: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2


资源记录参考


DNS 数据库包括 DNS 服务器所使用的一个或多个区域文件。每个区域都拥有一组结构化的资源记录,其中以下项目是 DNS 服务器服务支持的项目。


DNS 资源记录的格式


如下表中所述,所有的资源记录都有一个使用相同顶级字段的定义格式。


<div class="table-w

相关文章
|
2月前
|
机器学习/深度学习 人工智能 自然语言处理
AI技术深度解析:从基础到应用的全面介绍
人工智能(AI)技术的迅猛发展,正在深刻改变着我们的生活和工作方式。从自然语言处理(NLP)到机器学习,从神经网络到大型语言模型(LLM),AI技术的每一次进步都带来了前所未有的机遇和挑战。本文将从背景、历史、业务场景、Python代码示例、流程图以及如何上手等多个方面,对AI技术中的关键组件进行深度解析,为读者呈现一个全面而深入的AI技术世界。
223 10
|
11天前
|
机器学习/深度学习 人工智能 算法
DeepSeek技术报告解析:为什么DeepSeek-R1 可以用低成本训练出高效的模型
DeepSeek-R1 通过创新的训练策略实现了显著的成本降低,同时保持了卓越的模型性能。本文将详细分析其核心训练方法。
288 11
DeepSeek技术报告解析:为什么DeepSeek-R1 可以用低成本训练出高效的模型
|
5天前
|
存储 人工智能 并行计算
2025年阿里云弹性裸金属服务器架构解析与资源配置方案
🚀 核心特性与技术创新:提供100%物理机性能输出,支持NVIDIA A100/V100 GPU直通,无虚拟化层损耗。网络与存储优化,400万PPS吞吐量,ESSD云盘IOPS达100万,RDMA延迟<5μs。全球部署覆盖华北、华东、华南及海外节点,支持跨地域负载均衡。典型应用场景包括AI训练、科学计算等,支持分布式训练和并行计算框架。弹性裸金属服务器+OSS存储+高速网络综合部署,满足高性能计算需求。
|
4天前
|
人工智能 自然语言处理 算法
DeepSeek模型的突破:性能超越R1满血版的关键技术解析
上海AI实验室周伯文团队的最新研究显示,7B版本的DeepSeek模型在性能上超越了R1满血版。该成果强调了计算最优Test-Time Scaling的重要性,并提出了一种创新的“弱到强”优化监督机制的研究思路,区别于传统的“从强到弱”策略。这一方法不仅提升了模型性能,还为未来AI研究提供了新方向。
167 5
|
30天前
|
缓存 算法 Oracle
深度干货 如何兼顾性能与可靠性?一文解析YashanDB主备高可用技术
数据库高可用(High Availability,HA)是指在系统遇到故障或异常情况时,能够自动快速地恢复并保持服务可用性的能力。如果数据库只有一个实例,该实例所在的服务器一旦发生故障,那就很难在短时间内恢复服务。长时间的服务中断会造成很大的损失,因此数据库高可用一般通过多实例副本冗余实现,如果一个实例发生故障,则可以将业务转移到另一个实例,快速恢复服务。
深度干货  如何兼顾性能与可靠性?一文解析YashanDB主备高可用技术
|
1月前
|
Serverless 对象存储 人工智能
智能文件解析:体验阿里云多模态信息提取解决方案
在当今数据驱动的时代,信息的获取和处理效率直接影响着企业决策的速度和质量。然而,面对日益多样化的文件格式(文本、图像、音频、视频),传统的处理方法显然已经无法满足需求。
93 4
智能文件解析:体验阿里云多模态信息提取解决方案
|
1月前
|
Kubernetes Linux 虚拟化
入门级容器技术解析:Docker和K8s的区别与关系
本文介绍了容器技术的发展历程及其重要组成部分Docker和Kubernetes。从传统物理机到虚拟机,再到容器化,每一步都旨在更高效地利用服务器资源并简化应用部署。容器技术通过隔离环境、减少依赖冲突和提高可移植性,解决了传统部署方式中的诸多问题。Docker作为容器化平台,专注于创建和管理容器;而Kubernetes则是一个强大的容器编排系统,用于自动化部署、扩展和管理容器化应用。两者相辅相成,共同推动了现代云原生应用的快速发展。
180 11
|
2月前
|
域名解析 负载均衡 安全
DNS技术标准趋势和安全研究
本文探讨了互联网域名基础设施的结构性安全风险,由清华大学段教授团队多年研究总结。文章指出,DNS系统的安全性不仅受代码实现影响,更源于其设计、实现、运营及治理中的固有缺陷。主要风险包括协议设计缺陷(如明文传输)、生态演进隐患(如单点故障增加)和薄弱的信任关系(如威胁情报被操纵)。团队通过多项研究揭示了这些深层次问题,并呼吁构建更加可信的DNS基础设施,以保障全球互联网的安全稳定运行。
|
2月前
|
运维 监控 DataWorks
DataWorks 稳定性保障全解析:深入监控与资源调配
DataWorks 的稳定性保障体系涵盖精细监控与资源调配,确保企业数据业务高效、稳定运行。监控模块包括资源、任务和质量监控,及时预警并处理异常;资源调配策略则针对集成、调度、数据服务及计算资源进行科学配置,保障数据同步、任务优先级和高并发需求。通过全方位的监控和合理的资源配置,DataWorks 为企业筑牢数据根基,助力数字化转型。
84 10
|
2月前
|
缓存 网络协议 安全
融合DNS技术产品和生态
本文介绍了阿里云在互联网基础资源领域的最新进展和解决方案,重点围绕共筑韧性寻址、赋能新质生产展开。随着应用规模的增长,基础服务的韧性变得尤为重要。阿里云作为互联网资源的践行者,致力于推动互联网基础资源技术研究和自主创新,打造更韧性的寻址基础服务。文章还详细介绍了浙江省IPv6创新实验室的成立背景与工作进展,以及阿里云在IPv6规模化部署、DNS产品能力升级等方面的成果。此外,阿里云通过端云融合场景下的企业级DNS服务,帮助企业构建稳定安全的DNS系统,确保企业在数字世界中的稳定运行。最后,文章强调了全链路极致高可用的企业DNS解决方案,为全球互联网基础资源的创新提供了中国标准和数字化解决方案。

热门文章

最新文章

推荐镜像

更多