dns的cname https - codestacklinuxer

基础结构部分

DNS 报文的基础结构部分指的是报文首部，如图所示。

该部分中每个字段含义如下。

事务 ID：DNS 报文的 ID 标识。对于请求报文和其对应的应答报文，该字段的值是相同的。通过它可以区分 DNS 应答报文是对哪个请求进行响应的。

标志：DNS 报文中的标志字段。

问题计数：DNS 查询请求的数目。

回答资源记录数：DNS 响应的数目。

权威名称服务器计数：权威名称服务器的数目。

附加资源记录数：额外的记录数目（权威名称服务器对应 IP 地址的数目）。

基础结构部分中的标志字段又分为若干个字段，如图所示。

标志字段中每个字段的含义如下：

QR（Response）：查询请求/响应的标志信息。查询请求时，值为 0；响应时，值为 1。

Opcode：操作码。其中，0 表示标准查询；1 表示反向查询；2 表示服务器状态请求。

AA（Authoritative）：授权应答，该字段在响应报文中有效。值为 1 时，表示名称服务器是权威服务器；值为 0 时，表示不是权威服务器。

TC（Truncated）：表示是否被截断。值为 1 时，表示响应已超过 512 字节并已被截断，只返回前 512 个字节。

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

RA（Recursion Available）：可用递归。该字段只出现在响应报文中。当值为 1 时，表示服务器支持递归查询。

Z：保留字段，在所有的请求和应答报文中，它的值必须为 0。

rcode（Reply code）：返回码字段，表示响应的差错状态。当值为 0 时，表示没有错误；当值为 1 时，表示报文格式错误（Format error），服务器不能理解请求的报文；当值为 2 时，表示域名服务器失败（Server failure），因为服务器的原因导致没办法处理这个请求；当值为 3 时，表示名字错误（Name Error），只有对授权域名解析服务器有意义，指出解析的域名不存在；当值为 4 时，表示查询类型不支持（Not Implemented），即域名服务器不支持查询类型；当值为 5 时，表示拒绝（Refused），一般是服务器由于设置的策略拒绝给出应答，如服务器不希望对某些请求者给出应答。

当前出现一个sase问题，目前1x认证完成后，需要等待2min钟，钉钉才能登录，

最后在ap 数据平面上抓包，根据报文分析结果为：一开始dns 解析失败。具体分析过程就不说了

目前记录此文章主要是为了说明dns 中cname https等作用，顺便了解一下DNS的其余SOA NS TXT等作用

cname：

什么情况下会用到CNAME记录？
［如果需要将域名指向另一个域名，再由另一个域名提供ip地址，就需要添加CNAME记录］最常用到CNAME的情况包括：做CDN，做企业邮局

CDN服务之所以要用CNAME，最主要的原因是要根据用户所在位置选择并返回最优节点 IP。如果不用CNAME，A记录只能实现域名解析到IP，因此就无法实现CDN的加速效果。

一个 CDN 网络往往有非常多的边际(edge)节点，当你购买了 CDN 服务又想用自己的域名的时候，直接把你的域名 CNAME 到 CDN 的域名就好了，然后当用户连接的时候往往能够连接到他们最近的节点。

在分析报文的过程中：突然看到了HTTPS captive.apple.com 以及A captive.apple.com

type 为https 作用是啥？

DNS HTTPS流量作用：

2018 ESNI/ECH

随着 HTTPS/TLS 的日益普及，互联网的隐私问题得到极大的缓解。但是现在很多域名都会部署在云端，共享 IP，所以在建立 TLS 会话的时候需要协商使用哪个域名的证书。为此，TLS 支持一个名为 SNI 的扩展。浏览器在发起 TLS 连接的时候会将目标网站的域名以明文的方式发送给服务端。别有用心的人就可以监视用户所访问的网站。

所以SNI成了TLS最后一个隐私隐患。为此，人们提出 ESNI 方案来加密 SNI 信息。其基本原理就是通过 DNS 发布一个公钥（TXT 记录）。浏览器通过 DNS 查询到公钥对 SNI 加密，之后再发起 TLS 连接。最早只是加密 SNI 信息。最早只是加密 SNI 信息，后来发现还是有问题，索性将所有 ClientHello 信息都加密。这样 TLS 最后薄弱的一环也被修复了（标准还在制定中）。

不同的 CDN 肯定使用不同的 ECH 密钥。如果用 CDN A 的公钥加密并连接 CDN B 的 IP，这肯定会失败。现有的 DNS 系统也没有提供将不同记录绑定到一起的能力。

所以，有必要引入一种新型记录，其作用就是将服务的 IP 地址、ECH 公钥以及其他建立连接所需的信息关联起来，而且还要支持绑定根域名。这种新型记录就叫 Service Binding Record（SVCB）。

SVCB 记录概览

SVCB 记录的结构如下：

_端口._协议.子域名 TTL IN SVCB 优先级 目标域名 [服务参数...]

目标是通过一次 DNS 查询来加速通信连接过程


    优先级 == 0

表示别名模式（AliasMode）

支持绑定根域名


    优先级 != 0

表示服务模式（ServiceMode）

服务参数是任意键值对，主要的有：

TLS ALPN 提示信息

ECH 配置信息（公钥等）

IP 提示信息

HTTPS 记录概览

https 记录是一类特殊的 svcb 记录，功能上没有任何区别，但不需要指定 _https 协议前缀。可以更好地支持通配符域名。比如 *.example.com TTL IN HTTPS ... ，妆容现有的 CNAME 语义。

如果一个域名设置了 HTTPS 记录，就说明该域名支持 HTTPS/TLS 访问（类似 HSTS）。

DNS 服务器本身不对 SVCB/HTTPS 作任何区分。

别名模式 AliasMode

以下记录是将 example.com 的 http 服务信息指向 svc.example.net 域名。

example.com. 7200 IN HTTPS 0 svc.example.net.

如果还在 example.com 监听了非标准的端口（比如 8443），则应该再设置如下记录

_8443._https.example.com. 7200 IN HTTPS 0 svc.example.net.

服务模式 ServiceMode

下面是两条服务模式的 HTTPS 记录

svc.example.net. 7200 IN HTTPS 2 svc3.example.net. alpn=h3 port=8003 ech=...
svc.example.net. 7200 IN HTTPS 3 svc2.example.net. alpn=h2 port=8002 ech=...

其含义是可以使用 QUIC 协议连接 svc3.example.net 的 8003 端口或者使用 HTTP/2 连接 svc2.example.net 的 8002 端口，并且可以使用 ech 信息对 TLS 握手信息作加密处理。

DNS 查询流程

客户端同时发起 A/AAAA 和 HTTPS 记录（增加 50% 的查询量）

如果 HTTPS 记录是别名模式，则需要查询指向域名的 A/AAAA 和 HTTPS 记录

客户端需要查询服务模式下目标域名的 A/AAAA 记录

DNS 递归解析服务器可以通过附加字段提供这些记录

ECH 记录的特殊要求：

客户端需要在收到 HTTPS 查询结果之后再发起 TLS 连接，以防服务端开启 ECH

如果 HTTPS 查询超时，客户端不能假设服务端不支持 ECH，以防降级攻击

域名服务器记录，用来指定该域名由哪个DNS服务器来进行解析。它的结果是一条新的域名，不过是权威服务器的。

DoH 与 DoT

除了基于 HTTPS 的 DNS 外，目前还有另一种用于保护域名系统的技术：基于 TLS 的 DNS（DoT）。这两个协议看起来很相似，它们也都承诺了更高的用户安全性和隐私性。

但是这两项标准都是单独开发的，并且各有各的 RFC 文档。DoT 使用了安全协议 TLS，在用于 DNS 查询的用户数据报协议（UDP）的基础上添加了 TLS 加密。

DoT 使用 853 端口，DoH 则使用 HTTPS 的 443 端口。

http代理服务器（3-4-7层代理）-网络事件库公共组件、内核kernel驱动摄像头驱动 tcpip网络协议栈、netfilter、bridge 好像看过！！！！但行好事莫问前程 --身高体重180的胖子