DNS学习笔记2--DNS记录
第二篇搁置了一段时间，整理一下发出来。
文章目录
- DNS查询工具
- nslookup
- dig
- 域名解析
- DNS 记录
- A记录
- CNAME记录
- MX记录
- SOA记录
- TXT记录
- NS 记录
- SRV记录
- CAA记录
- PTR记录
- 顶级域访问
- URL显性/隐性转发
- 1 . URL隐性转发
- 2 . URL显性转发
- TIPs
DNS查询工具
nslookup
windows系统中的工具，主要用来查询域名系统 (DNS) 基础结构的信息。
- 基本用法
在命令行中输入nslookup 域名，查询并显示域名相关的信息。 - 查询指定类型
nslookup –qt=DNS类型 目标域名
dig
linux下的工具，有些发行版本没有自带这个工具，需要额外进行安装。
- 基本命令
dig www.isc.org - 指定类型
dig yahoo.com A - 直接显示响应结果
dig yahoo.com A +noall +answer
域名解析
DNS 记录（又名区域文件）是位于权威 DNS 服务器中的指令，提供一个域的相关信息，包括哪些 IP 地址与该域关联，以及如何处理对该域的请求。这些记录由一系列以 DNS 语法编写的文本文件组成。DNS 语法只是用作命令的字符串，用于告诉 DNS 服务器该做什么。所有 DNS 记录具有“TTL ”，代表的是生存时间，表示DNS 服务器多久刷新一次该记录。
这一部分的和DNS协议没有直接关系，目的是在实际使用域名进行测试时，有些操作内容需要结合自己服务商合适和测试来明确具体的实现情况。
DNS 记录
常见记录类型
| 代码 | 定义的RFC | 描述 | 功能 |
|---|---|---|---|
| A | RFC 1035 | IP 地址记录 | 传回一个 32 比特的 IPv4 地址，最常用于映射主机名称到 IP地址，也用于DNSBL（RFC 1101）。 |
| DS | RFC 4034 | 委托签发者 | 此记录用于鉴定DNSSEC已授权区域的签名密钥。 |
| TA | 无 | DNSSEC 信任当局 | DNSSEC 一部分无签订 DNS 根目录的部署提案，，使用与 DS 记录相同的格式。 |
| NS | RFC 1035 | 名称服务器记录 | 委托DNS区域（DNS zone）使用已提供的权威域名服务器。 |
| RP | RFC 1183 | 负责人 | 有关域名负责人的信息，电邮地址的 @ 通常写为 a。 |
| APL | RFC 3123 | 地址前缀列表 | 指定地址列表的范围，例如：CIDR 格式为各个类型的地址（试验性）。 |
| DLV | RFC 4431 | DNSSEC（域名系统安全扩展）来源验证记录 | 为不在DNS委托者内发布DNSSEC的信任锚点，与 DS 记录使用相同的格式，RFC 5074 介绍了如何使用这些记录。 |
| HIP | RFC 5205 | 主机鉴定协议 | 将端点标识符及IP 地址定位的分开的方法。 |
| KEY | RFC 2535RFC 2930 | 关键记录 | 只用于 SIG(0)（RFC 2931）及 TKEY（RFC 2930）。RFC 3455 否定其作为应用程序键及限制DNSSEC的使用。RFC 3755 指定了 DNSKEY 作为DNSSEC的代替。 |
| PTR | RFC 1035 | 指针记录 | 引导至一个规范名称（Canonical Name）。与 CNAME 记录不同，DNS“不会”进行进程，只会传回名称。最常用来运行反向 DNS 查找，其他用途包括引作 DNS-SD。 |
| SIG | RFC 2535 | 证书 | SIG(0)（RFC 2931）及 TKEY（RFC 2930）使用的证书。RFC 3755designated RRSIG as the replacement for SIG for use within DNSSEC. |
| SOA | RFC 1035 | 权威记录的起始 | 指定有关DNS区域的权威性信息，包含主要名称服务器、域名管理员的电邮地址、域名的流水式编号、和几个有关刷新区域的定时器。 |
| SPF | RFC 4408 | SPF 记录 | 作为 SPF 协议的一部分，优先作为先前在 TXT 存储 SPF 数据的临时做法，使用与先前在 TXT 存储的格式。 |
| TXT | RFC 1035 | 文本记录 | 任意可读的文本 DNS 记录。也有机读数据，例如 RFC 1464 指定：opportunistic encryption、Sender Policy Framework、DomainKeys、DNS-SD等。 |
| AAAA | RFC 3596 | IPv6 IP 地址记录 | 传回一个 128 比特的 IPv6 地址，最常用于映射主机名称到 IP 地址。 |
| NSEC | RFC 4034 | 下一代安全记录 | DNSSEC 的一部分 — 用来验证一个未存在的服务器，使用与 NXT（已过时）记录的格式。 |
| CERT | RFC 4398 | 证书记录 | 存储 PKIX、SPKI、PGP等。 |
| TSIG | RFC 2845 | 交易证书 | 用以认证动态更新（Dynamic DNS）是来自合法的客户端，或与 DNSSEC 一样是验证回应是否来自合法的递归名称服务器。 |
| NSEC3 | RFC 5155 | NSEC 记录第三版 | 用作允许未经允许的区域行走以证明名称不存在性的 DNSSEC 扩展。 |
| SSHFP | RFC 4255 | SSH 公共密钥指纹 | DNS 系统用来发布 SSH 公共密钥指纹的资源记录，以用作辅助验证服务器的真实性。 |
| RRSIG | RFC 4034 | DNSSEC 证书 | DNSSEC 安全记录集证书，与 SIG 记录使用相同的格式。 |
| AFSDB | RFC 1183 | AFS文件系统 | （Andrew File System）数据库核心的位置，于域名以外的 AFS 客户端常用来联系 AFS 核心。这个记录的子类型是被过时的的 DCE/DFS（DCE Distributed File System）所使用。 |
| CNAME | RFC 1035 | 规范名称记录 | 一个主机名字的别名：域名系统将会继续尝试查找新的名字。将一个域或子域转发到另一个域，不提供 IP 地址。 |
| DHCID | RFC 4701 | DHCP（动态主机设置协议）识别码 | 用于将 FQDN 选项结合至 DHCP。 |
| DNAME | RFC 2672 | 代表名称 | DNAME 会为名称和其子名称产生别名，与 CNAME 不同，在其标签别名不会重复。但与 CNAME 记录相同的是，DNS将会继续尝试查找新的名字。 |
| DNSKEY | RFC 4034 | DNS 关键记录 | 于DNSSEC内使用的关键记录，与 KEY 使用相同格式。 |
| IPSECKEY | RFC 4025 | IPSEC 密钥 | 与 IPSEC 同时使用的密钥记录。 |
| NSEC3PARAM | RFC 5155 | NSEC3 参数 | 与 NSEC3 同时使用的参数记录。 |
| LOC | RFC 1876 | 位置记录 | 将一个域名指定地理位置。 |
| MX | RFC 1035 | 电邮交互记录 | 引导域名到该域名的邮件传输代理（MTA, Message Transfer Agents）列表，将邮件定向到电子邮件服务器。 |
| NAPTR | RFC 3403 | 命名管理指针 | 允许基于正则表达式的域名重写使其能够作为 URI、进一步域名查找等。 |
| SRV | RFC 2782 | 服务定位器 | 广义为服务定位记录，被新式协议使用而避免产生特定协议的记录，例如：MX 记录。 |
| TKEY | RFC 2930 | 秘密密钥记录 | 为TSIG提供密钥材料的其中一类方法，that is 在公共密钥下加密的 accompanying KEY RR。 |
| ANY | RFC 1035 | 所有缓存的记录 | 传回所有服务器已知类型的记录。如果服务器未有任何关于名称的记录，该请求将被转发。而传回的记录未必完全完成，例如：当一个名称有 A 及 MX 类型的记录时，但服务器已缓存了 A 记录，就只有 A 记录会被传回。 |
| AXFR | RFC 1035 | 全域转移 | 由主域名服务器转移整个区域文件至二级域名服务器。 |
| IXFR | RFC 1995 | 增量区域转移 | 请求只有与先前流水式编号不同的特定区域的区域转移。此请求有机会被拒绝，如果权威服务器由于配置或缺乏必要的数据而无法履行请求，一个完整的（AXFR）会被发送以作回应。 |
| OPT | RFC 2671 | 选项 | 这是一个“伪 DNS记录类型”以支持 EDNS。 |
冷门记录类型
| 记录类型 | 描述 |
|---|---|
| AFSDB | 此记录用于由 Carnegie Melon 开发的Andrew File System（AFS）的客户端。AFSDB 记录的功能是查找其他 AFS 单元。 |
| APL | 用于指定地址范围列表的试验性记录。 |
| CAA | “证书颁发机构授权”记录，允许域所有者声明哪些证书颁发机构可以为该域颁发证书。如果不存在 CAA 记录，则任何人都可以为该域颁发证书。子域也会继承这些记录。 |
| DNSKEY | 包含用于验证域名安全系统扩展（DNSSEC）签名的公钥。 |
| CDNSKEY | 这是 DNSKEY 记录的子副本，应将其转移给父级。 |
| CERT | 用于存储公钥证书。 |
| DCHID | 用于存储有关动态主机配置协议（DHCP）的信息，该协议是 IP 网络上使用的标准化网络协议。 |
| DNAME | 记录创建域别名，类似CNAME一样，但会重定向所有子域。例如，如果“example.com”的所有者购买了域名“website.net”并为其提供了指向“example.com”的 DNAME 记录，则该指针还将扩展到“blog.website.net”以及任何其他子域。 |
| HIP | “主机身份协议”，这是一种分隔 IP 地址角色的方式；此记录最常用于移动计算。 |
| IPSECKEY | “IPSEC 密钥”记录与 Internet 协议安全（IPSEC）、端到端安全协议框架以及 Internet 协议套件（TCP/IP）的一部分配合使用。 |
| LOC | 包含域的地理信息，采用经度和纬度坐标形式。 |
| NAPTR | 可将“名称权威指针”记录与 SRV 记录相结合，以便基于正则表达式动态创建指向的 URI。 |
| NSEC | 用于证明所请求的 DNS 资源记录不存在。 |
| RRSIG | 存储用于根据 DNSSEC 对记录进行身份验证的数字签名。 |
| RP | 存储域负责人的电子邮件地址。 |
| SSHFP | 该记录存储“SSH 公钥指纹”；SSH 代表安全外壳，这是一种可在不安全网络上实现安全通信的加密网络协议。 |
A记录
“A”代表“地址”，是 DNS 记录的最基本类型，指出给定域的 IP 地址。例如，如果提取 example.com 的 DNS 记录，其“A”记录目前会返回 IP 地址 12.34.56.78。“A”记录仅保存 Ipv4 地址，如果站点具有 Ipv6 地址，需要使用“AAAA”记录。
示例：
| example.com | record type | value | TTL |
|---|---|---|---|
| @ | A | 12.34.56.78 | 14400 |
此处的“@”表示这是根域的记录，“14400”这个值是 TTL（生存时间），以秒为单位。A 记录的默认 TTL 是 14400 秒。这意味着，如果更新 A 记录，则需要 240 分钟（14400秒）后才会生效。
绝大多数网站只有一个 A 记录，但可以有多个，可以将请求流量分配到托管相同内容的多个 IP 地址中的一个。
CNAME记录
当需要将域名指向另一个域名，再由另一个域名提供 IP 地址，就需要添加 CNAME 记录，最常用到 CNAME 的场景包括做 CDN、企业邮箱、全局流量管理等。
CNAME 记录可以指向另一个具有 CNAME 记录的另一个域或具有 A 记录的域。例如，假设 www.example.com 有一个 CNAME 记录，值是“example.com”（没有“www”）。当 DNS 服务器访问 www.example.com 的 DNS 记录时，它实际上会触发对 example.com 的另一个 DNS 查找，返回 example.com 的 IP 地址。在这种情况下，可以说 example1.com 是 example.com 的规范名称（或真实名称）。所有 CNAME 记录都必须指向一个域，而不是 IP 地址。
通常，当站点具有子域（例如 blog.example.com 或shop.example.com）时，这些子域将具有指向根域（example.com）的 CNAME 记录。这样，如果主机的 IP 发生更改，则仅需要更新根域的 DNS A 记录，并且所有 CNAME 记录都会跟随对根所做的任何更改。
一个常见的误解是 CNAME 记录必须始终解析为其指向的域所在的网站，但事实并非如此。CNAME 记录仅将客户端指向与根域相同的 IP 地址。客户端访问该 IP 地址后，Web 服务器仍将相应地处理 URL。例如，blog.example.com 可能有一个 CNAME 指向 example.com，从而将客户端定向到 example.com 的 IP 地址。但是，当客户端实际连接到该 IP 地址时，Web 服务器将查看 URL，发现它是 blog.example.com，并且提供博客页面而不是主页。
示例：
| example1.com | record type | value | TTL |
|---|---|---|---|
| @ | CNAME | example.com | 32600 |
example1.com 指向 example.com。假设基于上面的A记录，最终会解析到 IP 地址 12.34.56.78。
MX记录
MX将电子邮件定向到邮件服务器。MX 记录指示如何根据简单邮件传输协议（SMTP，所有电子邮件的标准协议）路由电子邮件。与 CNAME 记录类似，MX 记录必须始终指向另一个域。
设置邮箱时，为了让邮箱通过域名找到邮箱服务器，顺利收到邮件，就需要添加 MX 记录。MX全称为mail exchanger，用于电子邮件系统发邮件时根据收信人的地址后缀来定位邮件服务器。例如，当有人发邮件给“[email protected]”时，系统将对“example.com”进行DNS中的MX记录解析。如果MX记录存在，系统就根据MX记录的优先级，将邮件转发到与该MX相应的邮件服务器上。
MX优先级：输入内容通过联系邮箱注册商提供，MX 优先级的数值越低，优先级别就越高
示例：
| example.com | record type | value | TTL |
|---|---|---|---|
| @ | MX | 10 | mailhost.example.com |
| @ | MX | 20 | mailhost2.example.com |
在这些 MX 记录的值条目中，域名前的数字表示优先级；服务器将始终首先尝试 mailhost1，因为 10 小于 20；如果消息发送失败，服务器将默认为 mailhost2。
SOA记录
“授权机构起始”（SOA）记录可以存储有关域的重要信息，如管理员的电子邮件地址、上次更新域的时间，以及服务器在刷新之间应等待的时间。
示例：
| example.com | record type | value | TTL |
|---|---|---|---|
| @ | SOA | admin.example.com | 11200 |
此处的值表示一个电子邮件地址，可能会造成混淆，因为它缺少“@”符号；但在 SOA 记录中，admin.example.com 等效于 [email protected]。
TXT记录
“文本”（TXT）记录让域管理员能够将文本输入到 DNS 记录中，如果希望对域名进行标识和说明，可以使用 TXT 记录。现在也可以将一些机器可读代码也放入 TXT 记录中。一个域可以具有许多 TXT 记录，通常用于发件人策略框架（SPF），这些代码可帮助电子邮件服务器判断邮件是否来自受信任的来源，有有助于域所有权验证。例如，某些网站管理员工具会要求将 TXT 记录添加到域中，以证明该域的真正所有者。 TXT 记录多用来做 SPF 记录（反垃圾邮件）。
记录值：常用情况TXT 记录是用来做 SPF 反垃圾邮件的，最典型的 SPF 格式的 TXT 记录例子为“v=spf1 a mx ~all”，表示只有这个域名的 A 记录和 MX 记录中的 IP 地址有权限使用这个域名发送邮件。
示例：
| example.com | record type | value | TTL |
|---|---|---|---|
| @ | TXT | Test | 32600 |
NS 记录
NS 代表“名称服务器”，此记录指示哪个 DNS 服务器对所给域具有权威（哪一服务器含有实际的 DNS 记录）。如果需要把子域名交给其他 DNS 服务商解析，就需要添加 NS 记录。一个域通常会有多个 NS 记录，这些记录可以指示该域的主要和备用名称服务器。
示例：
| example.com | record type | value | TTL |
|---|---|---|---|
| @ | NS | ns1.exampleserver.com | 21600 |
SRV记录
SRV 记录用来标识某台服务器使用了某个服务，常见于微软系统的目录管理。“服务”记录指定特定服务的主机和端口，例如 IP 语音 (VOIP)、即时消息等。
支持的设置内容
记录类型： 选择 SRV 。
主机记录： 格式为 服务的名字.协议的类型。
例如：_sip._tcp
解析线路：默认 为必选项，未设置默认线路会导致部分用户无法解析
记录值：格式为 优先级 权重 端口 目标地址 ，每项中间需以空格分隔。
例如：0 5 5060 sipserver.example.com
示例：
| example.com | record type | value | TTL |
|---|---|---|---|
| @_sip._tcp.example.com. | SRV | 8080 exampledomain.com | 41200 |
在上面的示例中，“_sip”指示服务类型，“_tcp”指示协议，“8080”指示端口，而“example.com”是主机。
CAA记录
CAA(Certificate Authority Authorization)，即证书颁发机构授权。是一项新的可以添加到DNS记录中的额外字段,通过DNS机制创建CAA资源记录，可以限定域名颁发的证书和CA（证书颁发机构）之间的联系。未经授权的第三方尝试通过其他CA注册获取用于该域名的SSL/TLS证书将被拒绝。
域名设置 CAA 记录使网站所有者可授权指定CA机构为自己的域名颁发证书，以防止HTTPS证书错误签发，从而提高网站安全性。
CAA记录的记录格式
CAA记录的格式为：[flag] [tag] [value]，是由一个标志字节的[flag]和一个被称为属性的[tag]-[value]（标签-值）对组成。可以将多个CAA字段添加到域名的DNS记录中。
| 字段 | 说明 |
|---|---|
| flag | 0-255之间的无符号整数，用于标志认证机构。通常情况下填0，表示如果颁发证书机构无法识别本条信息，就忽略。 |
| tag | 支持 issue、issuewild 和 iodef。 |
tag值描述
issue：CA授权单个证书颁发机构发布的 任何类型 域名证书。
issuewild：CA授权单个证书颁发机构发布主机名的 通配符 证书。
iodef：CA可以将违规的颁发记录URL发送给某个电子邮箱。
value CA的域名或用于违规通知的电子邮箱。
PTR记录
“指针”记录与“A”记录正好相反；PTR 地址将为提供与给定 IP 地址关联的域。PTR 记录在反向查询区域中用于反向 DNS 搜索。
此处的值表示一个电子邮件地址，可能会造成混淆，因为它缺少“@”符号；但在 SOA 记录中，admin.example.com 等效于 [email protected]。
顶级域访问
一般是指子域名的前缀（如需创建子域名为www.dns-example.com, 主机记录输入 www；如需实现dns-example.com，主机记录输入 @）
URL显性/隐性转发
1 . URL隐性转发
URL隐性转发一般用的是iframe框架技术，非重定向技术。
实现后的效果描述：
为浏览器地址栏输入http://a.com 回车，打开网站内容是目标地址http://www.b.com/ 的网站内容，但地址栏显示http://a.com的地址。
2 . URL显性转发
支持URL转发301永久重定向、302暂时性定向。
实现后的效果描述：
为浏览器地址栏输入http://a.com回车，打开网站内容是目标地址http://www.b.com的网站内容，且地址栏显示目标地址http://www.b.com
TIPs
添加 URL 转发记录时，多数厂商要求转发前后的两个域名都需完成备案且两个域名的备案接入商都为自己。
一般对于URL转发各个厂家的云解析不提供攻击防护服务，如遇攻击黑洞时无法使用URL转发，需要人工将转发的主机记录配置为A或CNAME记录。
URL转发时记录值不能为IP地址
URL转发通常不支持泛解析设置。
URL转发的目标域名可能不支持中文域名。
URL转发前域名支持HTTP，不支持HTTPS，转发后的目标地址支持HTTP、HTTPS。