解析域时如何处理CNAME?

时间:2014-08-01 15:39:26

标签: node.js security recursion dns

我的Web应用程序从不受信任的用户接收一些未经过滤的字符串,然后必须确定,如果此字符串用作主机名,则以某种方式解析为禁止范围内的IPv4或IPv6地址,由一组预定义规则确定。

因此,如果字符串看起来是IPv4或IPv6地址(规范或不规范),那很简单 - 只需将地址转换为规范形式,并测试它是否在允许的范围内。

但是如果字符串是有效的主机名,那会解析为很多记录呢?使用node.js的内置dns模块,我获得此特定主机名的所有DNS记录列表(AAAAATXTMX,{ {1}},SRV)。接下来是什么? AFAIK,CNAMETXTSRV根本不会影响名称解析。可以针对上述规则集验证MXA

但我应该如何处理AAAA?我应该为遇到的每个CNAME发出递归DNS解析吗?只是忽略它并默默地拒绝?如果我发出递归DNS解析,有任何机会阻止某些智能主机为我的应用程序提供无限的CNAME流,例如CNAME?如果它在某些时候重复,我可以突破它,但如果它没有呢?如果我提前休息(比如N个重定向),黑客可以伪造这样的链长N + 1,最后重定向有CNAME 1.foobar.com ⟶ CNAME 2.foobar.com ⟶ CNAME 3.foobar.com ⟶ CNAME 4.foobar.com ⟶ ... / A个记录到限制区域。

那么,有解决方案吗? “方便”的解析器如何处理这个?

2 个答案:

答案 0 :(得分:2)

所以,我已经结束了自己设置名称服务器,并提供类似于

的区域配置
$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

根据使用普通解析器进行的测试,如果{16}跳后CNAME链没有达到有用的目标(例如,如果第17个仍然是CNAME),则查找将被中断,域名将被拒绝为非-resolving。 CNAME攻击神话被破坏了。

答案 1 :(得分:0)

我不会混淆任何这一点,leave it up to the system resolver

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