在porkbun购买的greeniegolf.app域名配置TXT/MX records用于resend.com验证失败求助

兄弟太懂这种非DNS专家踩坑的焦虑了！先捋捋你的情况：你因为AWS不支持.app后缀，去Porkbun买了greeniegolf.app域名，接着在AWS建了托管区，把AWS的NS记录同步到Porkbun，S3静态站能正常访问——这步其实走对了，但到配置TXT/MX记录给resend做域名验证时就卡壳了：你把记录加到AWS托管区后，AWS自带的「Test Record」显示正常，但等了好几个小时，resend那边还是检测不到，mxtoolbox也查不到相关记录，网上又说一般不用等这么久，属实闹心。

给你几个排查方向，按优先级来：

• 先确认域名的NS服务器真的指向AWS了
  这是最核心的前提！如果Porkbun那边的NS记录没生效，你在AWS托管区加的任何记录外部都看不到。你可以用命令行查一下：

  dig NS greeniegolf.app
  # 或者用nslookup
  nslookup -type=NS greeniegolf.app
  

  看看返回的NS记录是不是和AWS托管区里的那四个完全一致。要是不一样，要么是你在Porkbun填错了，要么是Porkbun的NS记录还没完成全球同步（虽然一般几小时内会生效，但有时候可能延迟更久）。另外要注意：必须把Porkbun默认的NS记录全替换成AWS的，不能混合留着Porkbun的NS。

• 核对AWS托管区里的TXT/MX记录配置细节
  别小看拼写错误，很多时候问题就出在这：

  • 主机名：resend要求的是@（代表根域名）还是特定前缀？比如有些验证记录需要_resend-verification.greeniegolf.app这种，你有没有填对？
  • TXT记录内容：有没有带多余的双引号？比如resend给的验证字符串是abc123，你在AWS里填的时候直接写abc123就行，不用加引号（AWS会自动处理）。
  • MX记录：优先级和目标地址是不是完全符合resend的要求？比如resend给的MX地址是不是mx.resend.com之类的，优先级有没有填对？

• 排查DNS缓存问题
  本地DNS缓存、运营商缓存甚至mxtoolbox自身的缓存都可能导致你查不到新记录：

  • 换个网络测试，比如用手机流量（别连WiFi），再去mxtoolbox查；
  • 用公共DNS强制查询，比如：

    dig @8.8.8.8 TXT greeniegolf.app
    dig @8.8.8.8 MX greeniegolf.app
    

    这样绕开本地缓存，直接查公共DNS的结果，更准确。

• 确认AWS托管区是公开类型
  要是你不小心建了私有托管区，那只有AWS内部的资源能访问这个托管区的记录，外部的resend和mxtoolbox肯定查不到。去AWS Route53里看看托管区的类型，必须是「Public hosted zone」才对。

要是按上面几步排查完还是没解决，再看看Porkbun那边有没有开启DNSSEC之类的额外设置，有些时候DNSSEC配置不当也会影响记录的全球传播。

备注：内容来源于stack exchange，提问作者Justin Pfenning