如何在解析域时处理CNAMEs？

Question

我的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 long，最后一次重定向有A/AAAA记录到受限区域。

那么，有解决办法吗？“方便”的解析器如何处理这个问题？

Answer 1

因此，我已经结束了自己设置名称服务器，并提供类似于

$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攻击神话被打破.

Answer 2

我不会把这一切搞砸的，还有将其留给系统解析器处理。。

var dns = require('dns');
dns.lookup('host.example.com');