DNS <-> IP 认证有什么标准吗?

the*_*hai -2 domain-name-system authentication spf distributed-computing

我希望实现一种身份验证机制,该机制允许根据客户端的域名强制执行访问策略。身份验证服务器使用 DNS 中可用的信息来验证客户端授权。

更多细节:

访问策略 资源所有者将资源访问权限限制在特定的子域(例如 my-x-service.clientexample.com)。要访问资源,客户端必须证明它拥有子域或者它是授权代表域所有者访问该资源的第 3 方。

身份验证 为了证明它代表域所有者行事,客户端必须将其 IP 地址列入域名的 TXT 记录的白名单。身份验证服务器将客户端请求的 IP 地址与提供的声明域的 TXT 记录上发布的列表进行匹配。如果两者匹配,则授予对资源的访问权限。

   http://maps.serverexample.com/getLocationByname?params
   Content-Type: application/JSON
   Claim-Domain: my-x-service.clientexample.com
Run Code Online (Sandbox Code Playgroud)

是否已经有这样的标准?我只知道 SPF,但由于它用于电子邮件,我认为规范需要一些调整。

编辑 -

在此处输入图片说明

And*_*w B 6

SPF 不是安全凭证

我认为这里最大的误解是 SPF 记录提供了可信的凭证。事实上,SPF并不是一个安全的凭证,至少在真实的安全世界中是这样。

DNS 是一种本质上不安全的协议。它基于 UDP(无传输级握手),协议本身不实现握手,并且没有加密保证您得到的“回复”数据包没有被欺骗。如果你做一些研究,你会发现这个地方到处都是。

房间里的大象在这里很明显:如果 DNS 如此不安全,为什么 SPF 可以做它所做的事情?因为风险低。SPF 可能发生的最坏情况是零收益情况:如果您没有 SPF 记录,您就会回到原来的位置。SPF 是一个丑陋的妥协,邮件管理员在面对更大的问题时被迫达成,这就是它的范围。

为了进一步研究,我建议您查看一个鲜为人知的 DNS 记录类型,SSHFP以及它面临的有用挑战。SSHFP是将服务器的 SSH 公钥放入 DNS 的标准。您的 SSH 客户端永远不会要求您最初信任密钥。那太棒了。但是,如果您查看SSHFPSSH 客户端信任记录的先决条件,就会发现这里描述的问题类型完全相同。这应该消除关于 DNS 是否可用于在没有某种形式的根名称服务器信任的情况下提供安全凭证的任何疑虑。(DNSSEC)

DNS 安全不是唯一的挑战

好的,现在您知道为什么之前没有完成您所描述的内容了。DNSSEC 就在眼前,对吧?让我们暂时假设每个人都可以使用验证 DNSSEC 解析器,并且 DNSSEC 不会面临与 IPv6 相同的惯性。

这个标准可能不会发生。

我知道伴随 Mark 回答的评论线程不是您想听到的,但是当谈到发布受信任的 IP 列表是个坏主意时,他们已经牢记在心。大公司将非常不愿意实施三步信任,即您将可用于访问其系统的 IP 列表发布到互联网。这对他们来说是一个荒谬的前景,特别是当存在公钥密码学并且是管理委托信任系统的首选方式时。

在这个答案中,我提到了两种技术,它们解决了在全球范围内影响 IT 中每个人的更大问题,这两种技术都面临着巨大的惯性。与让这只鸟飞起来相比,这种惯性微不足道。这就是该死的真相。


Mar*_*son 5

想想这将如何运作。SPF 之所以起作用,是因为它允许远程邮件服务器验证他们收到的邮件,以确保邮件实际上来自它的目的地。这使发件人有责任首先拥有 SPF 记录。

这将如何与用于 Web 访问的 DNS 记录配合使用?它发布了一个允许连接到它的客户端列表,然后……什么?客户然后只是说“哦不!我不在名单上!我最好放弃我的连接!” 没有人写过不遵守这些记录的客户。没有人晚上必须锁门,我们不需要银行,因为我们把钱放在床底下的鞋盒里,警察退休了,因为每个人都刚刚开始相处,世界和平不再是一个不切实际的梦想。

如果您希望所有者将资源限制为已知 IP 地址,请按照几十年来的做法进行操作:使用防火墙。或者这样做,它已经完成了几乎一样长的时间:使用有关 Web 服务器配置的规则。

  • @mihai 我想不出有什么理由在 DNS 中发布您的安全策略。Web 服务器已经处理了这些限制,并且还有许多其他服务可以限制哪些地址/域可以连接。如果人们可以查找 TXT 记录,他们就可以查找 IP。它只是告诉我我需要闯入的地方,以便我可以转向你的系统。 (5认同)