我的 Web 应用程序从不受信任的用户那里接收一些未经过滤的字符串，然后必须确定，当这个字符串用作主机名时，是否以某种方式解析为禁止范围内的 IPv4 或 IPv6 地址，由一组预定义规则确定。
因此，如果字符串看起来是 IPv4 或 IPv6 地址(无论是否规范)，这很简单——只需将地址转换为规范形式，然后测试它是否在允许的范围内。
但是如果字符串是有效的主机名，那会解析为大量记录呢？使用 node.js 的内置 dns 模块，我获得了这个特定主机名的所有 DNS 记录列表( A 、 AAAA 、 TXT 、 MX 、 SRV 、 CNAME )。接下来是什么？ AFAIK、TXT、SRV 和 MX 根本不影响名称解析。 A 和 AAAA 可以根据上述规则集进行验证。
但是我应该怎么处理 CNAME 呢？我应该为遇到的每个 CNAME 发出递归 DNS 解析吗？直接无视，默默拒绝？如果我发出递归 DNS 解析，是否有机会阻止某些智能帽为我的应用程序提供无限 CNAME 流，例如 CNAME 1.foobar.com ⟶ CNAME 2.foobar.com ⟶ CNAME 3.foobar.com ⟶ CNAME 4.foobar.com ⟶ ... ？万一它在某个时候重复，我可以摆脱它，但如果它没有呢？如果我提前中断(比如在 N 次重定向之后)，黑客可以将这样的链伪造为 N+1 长，最后一次重定向将 A/AAAA 记录到限制区域。
那么，有没有解决办法呢？ “方便的”解析器如何处理这个问题？
最佳答案
所以，我已经结束了自己设置名称服务器，并将类似于的区域配置提供给它
$ORIGIN foobar.com
...
evil1 CNAME evil2.foobar.com
evil2 CNAME evil3.foobar.com
evil3 CNAME evil4.foobar.com
evil4 CNAME evil5.foobar.com
...
evil99997 CNAME evil99998.foobar.com
evil99998 CNAME evil99999.foobar.com
evil99999 CNAME evil100000.foobar.com
evil100000 A 127.12.34.56
nslookup 请求结束如下:$ nslookup evil1.foobar.com
Server: 127.0.0.1
Address: 127.0.0.1#53
evil1.foobar.com canonical name = evil2.foobar.com.
evil2.foobar.com canonical name = evil3.foobar.com.
evil3.foobar.com canonical name = evil4.foobar.com.
evil4.foobar.com canonical name = evil5.foobar.com.
evil5.foobar.com canonical name = evil6.foobar.com.
evil6.foobar.com canonical name = evil7.foobar.com.
evil7.foobar.com canonical name = evil8.foobar.com.
evil8.foobar.com canonical name = evil9.foobar.com.
evil9.foobar.com canonical name = evil10.foobar.com.
evil10.foobar.com canonical name = evil11.foobar.com.
evil11.foobar.com canonical name = evil12.foobar.com.
evil12.foobar.com canonical name = evil13.foobar.com.
evil13.foobar.com canonical name = evil14.foobar.com.
evil14.foobar.com canonical name = evil15.foobar.com.
evil15.foobar.com canonical name = evil16.foobar.com.
evil16.foobar.com canonical name = evil17.foobar.com.
evil17.foobar.com canonical name = evil18.foobar.com.
dig 产生类似的输出:# dig +recurse evil1.foobar.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> +recurse evil1.foobar.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34317
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;evil1.foobar.com. IN A
;; ANSWER SECTION:
evil1.foobar.com. 10 IN CNAME evil2.foobar.com.
evil2.foobar.com. 10 IN CNAME evil3.foobar.com.
evil3.foobar.com. 10 IN CNAME evil4.foobar.com.
evil4.foobar.com. 10 IN CNAME evil5.foobar.com.
evil5.foobar.com. 10 IN CNAME evil6.foobar.com.
evil6.foobar.com. 10 IN CNAME evil7.foobar.com.
evil7.foobar.com. 10 IN CNAME evil8.foobar.com.
evil8.foobar.com. 10 IN CNAME evil9.foobar.com.
evil9.foobar.com. 10 IN CNAME evil10.foobar.com.
evil10.foobar.com. 10 IN CNAME evil11.foobar.com.
evil11.foobar.com. 10 IN CNAME evil12.foobar.com.
evil12.foobar.com. 10 IN CNAME evil13.foobar.com.
evil13.foobar.com. 10 IN CNAME evil14.foobar.com.
evil14.foobar.com. 10 IN CNAME evil15.foobar.com.
evil15.foobar.com. 10 IN CNAME evil16.foobar.com.
evil16.foobar.com. 10 IN CNAME evil17.foobar.com.
evil17.foobar.com. 10 IN CNAME evil18.foobar.com.
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: ...
;; MSG SIZE rcvd: 388
根据对普通解析器的测试，如果
CNAME 链在 16 跳后没有找到有用的目标(例如，如果第 17 次仍然是 CNAME)，查找将被中断，域名将被拒绝为非解析。 CNAME 攻击神话破灭了。 关于node.js - 解析域时如何处理 CNAME？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/25083847/