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

2021-03-30 00:04:50 +08:00
 Jat001

最近在找支持 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 记录的格式,设计校验时都不看一下的吗?

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

1837 次点击
所在节点    全球工单系统
6 条回复
elfive
2021-03-30 00:11:39 +08:00
这不是技术能解决的问题。
Jat001
2021-03-30 00:18:15 +08:00
@elfive #1 校验代码没有充分考虑边界,做了画蛇添足的事情,要改不过是改个正则或加个判断的事情,有什么技术不能解决的
PMR
2021-03-30 07:28:10 +08:00
RFC 被人卡脖子的东西也用?必须自主知识产权,技术必须有特色
🌚
PMR
2021-03-30 07:29:27 +08:00
国内部署 Dnssec

某些不可描述行为不能操弄
Jat001
2021-03-30 07:32:59 +08:00
@PMR #4 DNSSEC 和 SRV 记录并没有关系,只是顺便一提
bclerdx
2021-03-30 09:27:06 +08:00
@PMR 别的国家或地区怎么没这么多事,就国内事多。。。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/766337

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX