我们正在讨论什么DANE技术用于DNS域名认证，以及为什么它没有在浏览器中广泛使用。
/不溅水/ Paulius Dragunas什么是DANE
证书颁发机构（CA）是对加密
SSL证书进行认证的组织。 他们在上面贴上电子签名，确认其真实性。 但是，有时会颁发违反证书的情况。 例如，去年Google由于赛门铁克证书的泄露而启动了“终止信任”程序（我们在博客中详细介绍了这个故事-
一次或
两次 ）。
为了避免这种情况，几年前，IETF
开始开发 DANE技术（但并未在浏览器中广泛使用-为什么会发生这种情况，我们将在后面进行讨论）。
DANE（基于DNS的命名实体认证）是一组规范，允许您使用DNSSEC（名称系统安全扩展）来控制SSL证书的有效性。 DNSSEC是域名系统的扩展，可最大程度地减少与欺骗相关的攻击。 使用这两种技术，网站管理员或客户端可以联系DNS区域运营商之一，并确认所使用证书的有效性。
实际上，DANE充当自签名证书（DNSSEC是其可靠性的保证人）并补充了CA的功能。
如何运作
DANE规范在
RFC6698中进行了描述。 根据该文档，新类型已添加到
DNS资源记录中 -TLSA。 它包含有关传输的证书，传输的数据的大小和类型以及数据本身的信息。 网站管理员会创建证书的数字指纹，并使用DNSSEC对其进行签名，然后将其放入TLSA。
客户端连接到Internet上的站点，并将其证书与从DNS运营商处收到的“副本”进行比较。 如果它们匹配，则该资源被认为是受信任的。
DANE Wiki页面通过TCP端口443为example.org服务器提供以下示例DNS查询：
IN TLSA _443._tcp.example.org
答案如下：
_443._tcp.example.com. IN TLSA ( 3 0 0 30820307308201efa003020102020... )
DANE除了TLSA之外，还具有几个可与其他DNS记录一起使用的扩展名。 第一个是用于SSH连接密钥验证的SSHFP DNS记录。 在
RFC4255 ，
RFC6594和
RFC7479中进行了描述。 第二个是OPENPGPKEY条目，用于使用PGP（
RFC7929 ）进行密钥交换。 最后，第三个是SMIMEA记录（该标准未在RFC中制定，
只有一个草稿 ），用于通过S / MIME进行密码密钥交换。
DANE有什么问题
5月中旬，举行了DNS-OARC会议（这是一个致力于域名系统的安全性，稳定性和开发性的非营利组织）。 在其中一个小组中，专家
得出的结论是，浏览器中的DANE技术失败了（至少在当前实施中如此）。 出席会议的是
APNIC的高级研究员Geoff Huston，这是五个区域Internet注册商之一，
他将DANE称为“死技术”。
流行的浏览器不支持使用DANE进行证书身份验证。 市场上有一些特殊的插件可以显示TLSA记录的功能，但是对它们的支持正在逐步淘汰 。
DANE在浏览器中的传播问题与DNSSEC验证过程的持续时间有关。 首次连接到资源时，系统被迫执行加密计算以确认SSL证书的真实性，并遍历整个DNS服务器链（从根区域到主机域）。
/不飞溅/ 凯莉·戴克斯特拉 （ Kaley Dykstra）在Mozilla中使用TLS的
DNSSEC Chain Extension尝试了此缺陷。 应该减少客户端在身份验证期间必须查看的DNS记录的数量。 但是，开发团队内部出现了无法解决的分歧。 结果，尽管该项目被IETF于2018年3月批准，但被放弃了。
DANE受欢迎程度较低的另一个原因是，DNSSEC在世界范围内的普及率很低，
只有19％的资源可以使用它 。 专家认为，这还不足以积极推广DANE。
该行业很可能会朝着不同的方向发展。 相反，市场参与者将使用DNS-over-TLS（DoT）和DNS-over-HTTPS（DoH）协议，而不是使用DNS来验证SSL / TLS证书。 我们在
以前有关哈布雷的
材料中提到了最后一个。 它们加密并验证对DNS服务器的用户请求，从而防止攻击者欺骗数据。 在今年年初，DoT已在Google的公共DNS上实现。 至于DANE，该技术是否将能够“重返马鞍”并仍然成为大众，仍有待观察。
我们还有其他内容可供阅读：
如何自动化IT基础架构管理-讨论三个趋势
JMAP-交换电子邮件时，开放协议取代IMAP
如何使用应用程序编程接口省钱
以1cloud.ru为例的云服务中的DevOps
1cloud云架构演进
1cloud技术支持如何工作
云神话