@阿里云 @dnspod 设计校验前请看下 RFC

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

工单节点使用指南

• 请用平和的语言准确描述你所遇到的问题

• 厂商的技术支持和你一样也是有喜怒哀乐的普通人类，尊重是相互的

• 如果是关于 V2EX 本身的问题反馈，请使用反馈节点

这是一个创建于 1364 天前的主题，其中的信息可能已经有所发展或是发生改变。

最近在找支持 DNSSEC 的解析商，发现大部分解析商都已经支持了，但国内的阿里云和 dnspod 都是付费才支持，不过很多国外的解析商是免费提供的，比如：

cloudflare 免费套餐支持

gandi 买域名就送解析服务，DNSSEC 不需要额外付费

vultr 不需要购买主机，免费服务

desec 非盈利组织，宣称有 Anycast Networks

在设置 SRV 记录时，我发现阿里云和 dnspod 都不支持设置记录值为 0 0 0 .，也就是 target 不能为 .

但根据 RFC 2782：

   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

你要问我为什么要这样设置，RFC 6186：

   In addition, with SRV RRs it is possible to indicate that a
   particular service is not supported at all at a particular domain by
   setting the target of an SRV RR to ".".  If such records are present,
   clients MUST assume that the specified service is not available, and
   instead make use of the other SRV RRs for the purposes of determining
   the domain preference.

   Example: service records for IMAP and POP3 with both TLS and non-TLS
   service types are present.  Both IMAP and POP3 non-TLS service types
   are marked as not available.  IMAP (with TLS) has a lower-numbered
   priority value 0 than POP3 (with TLS) at priority 10, indicating to
   the MUA that IMAP is preferred over POP3, when the MUA can support
   either service, and only the TLS versions of the services are
   available.

       _imap._tcp     SRV  0 0 0   .
       _imaps._tcp    SRV  0 1 993 imap.example.com.
       _pop3._tcp     SRV  0 0 0   .
       _pop3s._tcp    SRV 10 1 995 pop3.example.com.

给阿里云提了工单，并附上 RFC，结果反馈我

您好，抱歉让您久等了，和后端确认目前阿里云的云解析，目前云解析暂不支持目标地址为“.”的 srv 记录解析。目前云解析这边暂无替代方案。如果您一定要添加这种解析，只能建议您考虑使用其他支持的平台来配置了。

刚刚又给腾讯云提了工单，还没有回复

RFC 6186 不看也就罢了，毕竟是关于 Use of SRV Records for Locating Email Submission/Access Services 的，但 RFC 2782 是关于 SRV 记录的 RFC，里面详细描述了 SRV 记录的格式，设计校验时都不看一下的吗？

不过我上面列出的国外解析商倒是都支持，果然国内的云平台把用户当傻子，什么都要校验一下

第 1 条附言 · 2021-03-30 07:36:25 +08:00

DNSSEC 跟 SRV 记录并没有任何关系，只是顺便一提。

DNSSEC 需要设置的是 DS 记录，不过我不会在国内买域名的，动不动就 hold，所以没有测试。

本贴只是吐槽阿里云和 dnspod 对 SRV 记录的校验不符合 RFC 。

第 2 条附言 · 2021-03-30 22:21:54 +08:00

腾讯云也回工单了：

关于srv记录暂不支持0 0 0 .这样的格式的需求，这边已经反馈给我们后端进行优化，您的建议是我们改善的方向和前进的动力。因此也希望您多体验体验我们的产品，有任何的需求或者建议都可以向我们反馈，也请您能给我们时间来成长完善，感谢您的支持！

让大厂改点东西果然很难

6 条回复 • 2021-03-30 09:27:06 +08:00

elfive

2021-03-30 00:11:39 +08:00 via iPhone

这不是技术能解决的问题。

Jat001

2021-03-30 00:18:15 +08:00

@elfive #1 校验代码没有充分考虑边界，做了画蛇添足的事情，要改不过是改个正则或加个判断的事情，有什么技术不能解决的

PMR

2021-03-30 07:28:10 +08:00 via Android

RFC 被人卡脖子的东西也用？必须自主知识产权，技术必须有特色
🌚

PMR

2021-03-30 07:29:27 +08:00 via Android

国内部署 Dnssec

某些不可描述行为不能操弄

Jat001

2021-03-30 07:32:59 +08:00

@PMR #4 DNSSEC 和 SRV 记录并没有关系，只是顺便一提

bclerdx

2021-03-30 09:27:06 +08:00 via Android

@PMR 别的国家或地区怎么没这么多事，就国内事多。。。