当前位置: 首页 > news >正文

CNAME记录

CNAME记录

维基百科,自由的百科全书

(重定向自CNAME)

真实名称记录(英语:Canonical Name Record),即CNAME记录,是域名系统(DNS)的一种记录。CNAME记录用于将一个域名(同名)映射到另一个域名(真实名称),域名解析服务器遇到CNAME记录会以映射到的目标重新开始查询。[1]

这对于需要在同一个IP地址上运行多个服务的情况来说非常方便。若要同时运行文件传输服务和Web服务,则可以把ftp.example.comwww.example.com都指向DNS记录example.com,而后者则有一个指向IP地址的A记录。如此一来,若服务器IP地址改变,则只需修改example.com的A记录即可。

CNAME记录必须指向另一个域名,而不能是IP地址。

细节

《RFC 1034》详细定义了CNAME记录的标准,并在《RFC 2181》的第十节中做了进一步规范。

CNAME记录在域名系统中的使用有诸多限制。当一个DNS解析服务器在查询各类记录时遇到一则CNAME记录时,它会立即重启查询,查询所映射到域名的对应记录。(除非是要查询CNAME记录本身,在那种情况下会返回所映射到的域名。)CNAME记录所映射的域名可以是域名服务中的任何域名。在同一服务器上,在远程服务器上,甚至在属于不同DNS zone(解析空间)的服务器上,都可以。

假设有下述DNS zone:

NAME                    TYPE   VALUE
--------------------------------------------------
bar.example.com.        CNAME  foo.example.com.
foo.example.com.        A      192.0.2.23

当要查询bar.example.com的A记录时,域名解析器会查到对应的CNAME记录,即foo.example.com,随即开始查询该域名的A记录,查到192.0.2.23则返回结果。

误会

可以使用CNAME记录将“bar.example.com”指向“foo.example.com”。因此,可能会有人随意的将bar.example.com称作是foo.example.com的“CNAME”。然而事实并非如此,bar.example.com的“CNAME”是foo.example.com,因为CNAME的意思是真实名称,而右侧才是真实名称,才是CNAME。

这则误会在《RFC 2181》“DNS规范的解释”一章中有提到。应当说左侧标签是右侧真实名称的一个同名。即下述CNAME记录:

bar.example.com.        CNAME  foo.example.com.

应当读作:

bar.example.com的真实名称是foo.example.com。请求访问bar.example.com的客户端会得到foo.example.com返回的结果。

限制

  • CNAME记录总是指向另一则域名,而非IP地址。
  • 有CNAME记录的域名不能有其他任何记录(MX记录、A记录等,《RFC 1034》第3.6.2节、《RFC 1912》第 2.4节) 唯一的例外是在使用DNSSEC的情况下,这时可以设置相关的DNSSEC相关记录,比如RRSIG,NSEC等(《RFC 2181》第10.1节)
  • 为了保证效率,应当避免将CNAME记录指向其他的CNAME记录,但并非不可以。因此,可以通过CNAME记录创造无法被解析的循环,比如:
foo.example.com.  CNAME  bar.example.com.
bar.example.com.  CNAME  foo.example.com.
  • MX记录和NS记录永远都不应指向由CNAME记录标记的域名(《RFC 2181》第10.3节)。因此,解析空间不应有下述结构:
example.com.      MX     0   foo.example.com.
foo.example.com.  CNAME  host.example.com.
host.example.com. A      192.0.2.1
  • 根据(《RFC1912》)第2.4节,根网域(Root Domain)不应该被添加 CNAME 纪录。但部分 DNS 服务商(例如 DNSPod、NS1)可以忽略该 RFC 标准而针对根网域做出 CNAME 解析,比如:
example.com.  CNAME  foo.example.com.

但这样做会导致该网域若有用于邮箱服务,则可能造成错误,详见如下方。

而愿意遵守 RFC 标准的 DNS 供应商 (例如 Neustar UltraDNS、Cloudflare DNS)则采用了 Apex Alias 或 CNAME flattening 技术,这个技术将使得由 DNS 服务商自行处理 CNAME 解析的过程,并将最终解析的 A 纪录作为实际解析的结果,从而不与 RFC 标准抵触,比如:

example.com.  A      192.0.2.1
  • 用于邮箱服务的域名不应有CNAME记录。在实践中,这或许不会出错,但由于邮件服务的不同,可能会有意料之外的效果。[2]

DNAME记录

DNAME记录,即代理名称记录,由《RFC 6672》定义(原《RFC 2672》已经废弃)。一条DNAME记录会将某个域名的整个解析子树映射到另一域名,而CNAME只映射设定的域名,不映射子域名。如同CNAME一样,在DNS查询过程中,会查找所映射到的新域名的地址。域名解析服务器会为每一个被查询的子域名生成一则CNAME记录。为某个域名设置DNAME记录和为该域名的所有子域名设置CNAME记录的效果是一样的。

例如下述记录:

foo.example.com.        DNAME  bar.example.com.
bar.example.com.        A      192.0.2.23
xyzzy.bar.example.com.  A      192.0.2.24
*.bar.example.com.      A      192.0.2.25

查询foo.example.com的A记录不会返回任何结果。不同于CNAME记录,DNAME不会直接影响所设置域名的解析。

如果我们需要查询xyzzy.foo.example.com,则由于DNAME记录的映射会返回xyzzy.bar.example.com的A记录,即192.0.2.24。而如果将DNAME记录换成是CNAME记录的话,这样的请求则会报错提示无法找到。

由此,查询foobar.foo.example.com会由于DNAME记录映射返回192.0.2.25。

ANAME记录

部分DNS平台支持尚未被标准化的ALIAS[3]或ANAME记录类型。此类伪记录由DNS服务器维护,类似于CNAME记录,但在(某些)客户端解析时等同于A记录。ANAME记录通常会被设置指向另一域名。但在被客户端请求时候,则会直接返回对应的IP地址。ANAME记录的标准化过程正在进行中[4],但已经有许多不同的实现,所以由于平台的不同,效果也多种多样。有些存在于域名解析区的顶端,有些则为了提供邮件服务而存在。ANAME记录相对CNAME记录的一大优势是速度。服务端解析A记录的速度通常比客户端快,同时可以缓存对应的IP地址以备查询。IETF正在讨论和考虑ANAME记录的标准化。[5]

http://www.lryc.cn/news/349450.html

相关文章:

  • pytest + yaml 框架 -69.新增depend 关键字,导入其它yaml用例
  • 【网络】tcp的初始化序列号为什么要随机生成
  • 【SRC实战】利用APP前端加密构造数据包
  • ThreadLocal描述
  • Linux-基础命令第三天
  • Windows Server 2022 环境下WEB和DNS服务器配置方法
  • 静态住宅代理 IP 的影响
  • IP代理中的SOCKS5代理是什么?安全吗?
  • 一个用Kotlin编写简易的串行任务调度器
  • JavaScript异步编程——11-异常处理方案【万字长文,感谢支持】
  • python如何做一个服务器fastapi 和flask
  • Element-ui el-table组件单选/多选/跨页勾选讲解
  • CentOS 安装 SeaweedFS
  • Redis如何避免数据丢失?——AOF
  • xFormers
  • LQ杯当时的WP
  • 数据结构与算法学习笔记三---栈和队列
  • web入门——导航栏
  • 基于梯度流的扩散映射卡尔曼滤波算法的信号预处理matlab仿真
  • Flutter 中的 ListTile 小部件:全面指南
  • Kubernetes——CNI网络组件
  • 对关系型数据库管理系统的介绍
  • Nodejs 第七十一章(libuv)
  • mysql实战题目练习
  • Linux 案例命令使用操作总结
  • 图的拓扑序列(DFS2)
  • 2024年小学生古诗文大会备考:吃透历年真题和知识点(持续)
  • SystemC学习使用记录
  • Github20K星开源团队协作工具:Zulip
  • C语言基础-标准库函数