简介
这篇博客文章解释了DomainTools如何增强DNSDB以更好地处理通配符DNS记录。
在解释这些增强功能之前，让我们快速回顾一下通配符DNS记录。
DNS通配符记录
通常，我们对已经定义的完全限定域名(fqdn)进行DNS查询。例如，使用Un*x dig命令，我们可以看到该公司的网站解析为IPv4地址:乐动体育官网下载
＄挖www.xylmmw.com +短199.30.228.112这是因为在公司的权威DNS中定义了特定的DNS资源记录。乐动体育官网下载给定的可注册基本域名(如domaintools.com)可能具有许多此类预定义名称。这些名称可能包括邮件服务器、存储服务器、网络打印机等的fqdn。每个联网系统都定义了相应的常规DNS条目，因此，DNS适用于这些系统。
在这种环境中，没有特别定义的名称将无法解析。你可以通过尝试解析一个随机的“胡言乱语”主机名来验证这一点-它不会工作(正如预期的那样):
＄挖insdvkncvkxcnvxcvn.domaintools.com +短[没有发现或返回杂乱无章的主机名]然而，有些域被设置为利用“DNS通配符记录”。这些通配符记录将响应人们可能试图解决的任何主机名。例如，Tumblr建立了一个通配符DNS记录任何东西在tumblr.com将解决:
＄挖kjsndvjknsvijn.tumblr.com +短74.114.154.18 74.114.154.22 $挖joe-uses-too-much-hot-sauce-in-his-chili.tumblr.com +短74.114.154.22 74.114.154.18有时甚至整个顶级域都有DNS通配符记录。例如，点ph值当前是这样设置的:
＄挖ojnosufjojsf.ph +短45.79.222.138关于DNS通配符记录有许多微妙的注意事项，我们不会在这个简要介绍中介绍。如果对详细和深入的处理感兴趣，请参阅“通配符在域名系统中的作用”。https://datatracker.ietf.org/doc/html/rfc4592
“为什么站点有DNS通配符记录?”
站点定义DNS通配符记录的两个最常见的原因是:
(a)操作简便:一些组织通常允许用户在他们的一个域名下创建新网站。这些网站是通过指向用户页面的唯一主机名访问的。为了正确地将访问者路由到用户的网站，组织可以不断地创建新的特定DNS条目(每当注册一个新网站时就会有一个新的DNS记录)，但是定义一个通配符记录要容易得多，它将所有真实(或潜在的真实)网站的访问者路由到一组负载平衡器，让负载平衡基础设施“从那里获取”。
(b)广告收入:其他网站，包括一些顶级域名，可能会将任何容易输入错误的访问者纯粹视为广告的潜在浏览者。这意味着如果有人试图访问一些不存在的域名，这实际上是一件好事，因为他们可以显示一些广告。通配符DNS条目通常用于启用“如果他们打错字就显示广告”功能。
DNS通配符记录也可能是管理信息系统-被那些实施分布式拒绝服务(DDoS)攻击的人使用和利用。通配符将通常启用长主机名的解析，同时也允许多级不存在的子域。持续的超长、可解析但随机的欺骗DNS查询流通常会导致巨大的攻击负载(而且这些结果的缓存属性也很差)。
都是DNS通配符的名字不同于DNSDB通配符查询?”
是的，DNSDB通配符查询肯定不同于DNS通配符的名字。
您可以向DNSDB标准搜索查询特定的FQDN(例如，您可以在DNSDB标准搜索中查询特定的FQDN www.princeton.edu)。然而，DNSDB标准搜索也支持整个标签“左手通配符”和整个标签“右手通配符”搜索。
这意味着除了能够在DNSDB中查找特定的主机名外，您还可以使用左手通配符查询查看所有的fqdn harvard.edu已定义:
* .harvard.edu或者你可以用右手通配符搜索以“yale”开头的fqdn(如果有的话)(除了我们期望看到的yale.edu域):
耶鲁。*这类搜索模式通常称为“通配符搜索”，但它们与本文第2节中描述的通配符DNS名称无关。
我们还将借此机会提醒您，如果您曾经希望在DNSDB中进行更广泛的通配符查询(例如部分标签通配符或中间名称通配符，甚至正则表达式搜索)，您现在可以通过使用DNSDB Flexible Search来实现!在https://www.farsightsecurity.com/assets/media/download/DNSDB_Flexible_Search_Intro.pdf上可以找到灵活的搜索训练平台
DNS通配符记录引起的问题可能是被动DNS中的技术挑战
冒着显而易见的风险，DNSDB查询应该返回可用的结果。特别是，您需要能够看到与您的底层分析相关的结果，而不仅仅是淹没在噪音中。考虑以下现实情况:
- 单个DNSDB API查询最多返回一百万个结果。也就是说:
- 一些DNSDB API客户端(如DNSDB Scout)可能由于处理表时浏览器相关的限制而具有较低的结果限制。
- 在最初查询的第一个一百万个结果之后，如果您还需要更多结果，您可以进行三个额外的补充“偏移”查询(每个可能返回额外的一百万个结果)，总共最多可获得四百万个结果。
- 一百万个结果无疑是大量的结果。为了使之具体化，假设每个结果只有一行，并且每页打印有66行。一百万行输出将超过15000页打印!
- 现在，再加上一个DNS通配符名通常在一天内就会产生超过100万个独特的观察结果，并且日复一日地以这种速度不断积累结果。如果不进行管理，通配符值将在用户结果中阻塞“真实”域名。这是一个用户可见且重要的实际问题。
- 如果不进行管理，DNS通配符名称还会导致DNSDB MTBL文件存储容量过大，从而不必要地提高通过DNSDB Export在“本地”运行DNSDB副本的任何人的存储成本。
由于这些原因和其他原因，DomainTools经常擦洗DNS通配符名称，防止它们污染DNSDB。在过去，添加新的筛选器会无声地停止筛选通配符域的数据收集。用户可能想知道发生了什么——域名坏了吗?覆盖该领域的传感器是否停止了贡献?软件有问题吗?这种情况已经改变。
那么什么才是真正的新事物呢?
我们现在用一个特殊的大写前导标签标记筛选过的通配符域，_WILDCARD_
＄dnsdbq -r \*.mycricket.com/CNAME -A1d；;记录时间:2022-07-05 11:44:27 ..2022-07-27 19:16:11 (~22d 7h 31m);;数:81696;范围:mycricket.com。_WILDCARD_.mycricket.com。CNAME www.cricketwireless.com.edgekey.net。当您看到大写的前导标记时，您就会知道匹配的记录(其中许多记录看起来是随机生成的数据)已经“汇总”到单个合并条目中。我们相信这比在没有跟踪的情况下过滤这些条目要好，因为_WILDCARD_条目使得继续收集第一次看到/最后一次看到的时间戳和计数成为可能。
_WILDCARD_常见问题解答:
FAQ-1。“这些新的通配符条目有很多吗?”也许我可以做一个DNSDB搜索_通配符_。然后把他们都列出来?”
虽然您可能会在输出中遇到_WILDCARD_标记的名称，但DNSDBAPI用户目前不能使用dnsdbq, DNSDB Scout或类似的DNSDB API客户端搜索所有_WILDCARD_域的列表。这种排斥是有意的。
然而,DNSDB出口拥有本地MTBL文件的用户可以使用dnstable_dump命令获取这些记录的列表。例如，使用一个最近的每日MTBL文件:
＄dnstable_dump -r dns.20220726.D。mtbl -j | fgrep "_WILDCARD_"{“计数”:17076年,“time_first”:1658736570,“time_last”:1658857004,“rrname”:“_WILDCARD_.gap.ae。”,“rrtype”:“一”,“范围”:“gap.ae。”,“rdata”:[" 162.13.201.232 "]}(等)美元dnstable_dump -r dns.20220726.D。mtbl -j | fgrep "_WILDCARD_"> _WILDCARD_.txt＄排序-u < _WILDCARD_.txt | wc -l .txt756_WILDCARD_记录的数量在MTBL文件和MTBL文件之间会有所不同，这取决于我们看到的流量。
FAQ-2。“但是如果我用dnsdbq检查DNSDB，我确实看到一些通配符_。*条目已报告!”
注意，这些条目是小写的。它们在我们的数据提要中是“可见的”，不代表我们合并到_WILDCARD_记录中的域。特殊的通配符条目总是以_通配符_(仅限大写)
FAQ-3。“对于_WILDCARD_记录，计数意味着什么?”第一次看见和最后一次看见的时间呢?”
计数表示从_WILDCARD_条目实例化开始，所有匹配记录“卷”到通配符中的匹配记录的数量。类似地，日期时间反映了任何匹配资源记录卷起到通配符中的最早(和最晚)日期时间。
FAQ-4。一旦识别出DNS通配符，以前的通配符记录(例如，DNSDB中已经存在的条目)是否会被回顾性地合并到新的_WILDCARD_条目中?
我们现在不做回顾性通配符汇总。
FAQ-5。“新增的_通配符条目会向客户披露吗?”
仅以嵌入DNSDB的新条目的形式导出MTBL文件(如上文第6节所示)。
FAQ-6。“我们能‘提名’我们认为是通配符的域名吗?”或者告诉您不再使用通配符操作的记录?”
通配符是通过编程方式识别和验证/重新验证的。虽然我们感谢您的帮助，但目前不需要手动提名/除名程序。
FAQ-7。“在创建了_WILDCARD_条目后，为什么我仍然可以看到相同域名下的一些其他特定主机名?”
_WILDCARD_条目的作用域可能很窄，可能仅限于“A”记录或“CNAME”记录。具有相同后缀的其他条目(例如“NS”记录或“TXT”记录)可能仍然是狭义的静态定义。在这种情况下，这些条目将继续单独跟踪。类似地，为了将资源记录整合到_WILDCARD_条目中，RRset的所有其他方面都必须匹配。在内部，前面的过滤方法仅在每个子域或子域+rrtype基础上匹配记录。改进的通配符还允许过滤每个子域或子域+rrtype的特定rdata。举个例子，如果有一个通配符规则用于“*.foo.com a 127.0.0.1″”，那么像“bar.foo.com a 1.2.3.4”这样的记录仍然会产生未经过滤的观察结果。
FAQ-8。“有没有可能我会看到两个或更多不同的_WILDCARD_相同域名后缀的条目? "
是的。例如，假设一个_WILDCARD_ " a "记录生成一个IP地址的答案，然后更改到另一个IP地址。然后，您可能会看到两个_WILDCARD_“A”记录，一个用于旧IP，一个用于新IP(假设问题域仍然是通配符!)
FAQ-9。“我们怎么知道第三方不会用假通配符条目毒害DNSDB ?”(你怎么敢把一个‘编造’的值塞进DNSDB!)”
攻击者不能生成带有大写_通配符_标记的条目——所有“常规”“rnames”(如我们的传感器数据或区域文件数据中所示)在处理过程中被迫只使用小写。只有我们特别添加的记录才会有前导大写字母_WILDCARD_标签。
此外，由于标记的域是通配符，它们将字面上回答任何问题-包括我们的特殊通配符标记!这是一个非常安全/保守的方法。
FAQ-10。这与SIE有什么关系?
值得注意的是，作为DNSDB收集的原始输入的实时SIE通道流量是通配符过滤实际发生的上游源，通配符管理也将在那里被注意到。
FAQ-11。“我们还有问题要问!”我们能问谁呢?”
确认
DNSDB的通配符处理工作是许多参与者贡献的结果。我们要感谢并感谢(按字母顺序排列)马克·埃文斯，克里斯汀·福格尔，大卫·韦茨曼和斯蒂芬·瓦特。
