我知道我的问题与编程无关，但是我认为也许有人可以帮助我。 我有一个用于不同TLD的域名列表。我也有我的TLD的区域文件，但是一些域名在该区域文件中不存在。我检查了域名的DNS值，其中一些具有有效的DNS A响应。 我认为TLD的区域文件应包含该TLD注册的所有域名。那是对的吗？如果是，对域名进行DNS响应但区域文件中不存在该域名是什么意思？
例如，我检查了来自icann的区域文件中的ews.com.link TLD，并且其中不包含ews.com.link域名，当我发送DNS查询或ews.com.link挖掘时，我是低于回应：
; <<>> DiG 9.8.3-P1 <<>> ews.com.link
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43251
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 15
;; QUESTION SECTION:
;ews.com.link. IN A
;; ANSWER SECTION:
ews.com.link. 900 IN A 101.132.249.163
;; AUTHORITY SECTION:
com.link. 900 IN NS ns3.myhostadmin.net.
com.link. 900 IN NS ns1.myhostadmin.net.
com.link. 900 IN NS ns4.myhostadmin.net.
com.link. 900 IN NS ns6.myhostadmin.net.
com.link. 900 IN NS ns2.myhostadmin.net.
com.link. 900 IN NS ns5.myhostadmin.net.
;; ADDITIONAL SECTION:
ns1.myhostadmin.net. 2790 IN A 113.17.175.150
ns1.myhostadmin.net. 2790 IN A 183.131.155.224
ns1.myhostadmin.net. 2790 IN A 211.149.230.100
ns2.myhostadmin.net. 2790 IN A 113.17.175.200
ns2.myhostadmin.net. 2790 IN A 120.52.19.214
ns3.myhostadmin.net. 2790 IN A 113.17.175.150
ns3.myhostadmin.net. 2790 IN A 183.131.155.224
ns3.myhostadmin.net. 2790 IN A 211.149.230.100
ns4.myhostadmin.net. 2790 IN A 120.52.19.214
ns4.myhostadmin.net. 2790 IN A 113.17.175.200
ns5.myhostadmin.net. 2790 IN A 211.149.230.100
ns5.myhostadmin.net. 2790 IN A 113.17.175.150
ns5.myhostadmin.net. 2790 IN A 183.131.155.224
ns6.myhostadmin.net. 2790 IN A 120.52.19.214
ns6.myhostadmin.net. 2790 IN A 113.17.175.200
;; Query time: 356 msec
;; SERVER: 128.119.240.1#53(128.119.240.1)
;; WHEN: Wed Aug 15 13:51:21 2018
;; MSG SIZE rcvd: 409
以下域名的结果相同，我在其tld区域文件中对其进行了检查：
newd.com.limited
neqs.com.center
nesw.com.house
nsws.com.academy
bbc.com.cards
hews.com.camp
amh.com.pub
smg.com.zone
dmh.com.fail
hews.com.town
jews.com.photos
shm.com.toys
newws.com.boutique
ne3s.com.africa
nrws.com.game
nrws.com.africa
naws.com.tienda
nwes.com.cheap
niws.com.kitchen
amh.com.toys
newe.com.shoes
newx.com.koeln
smg.com.toys
答案 0 :(得分：2)
根据您的评论和编辑，您可能对DNS的工作原理以及什么是区域文件以及其中的内容有一些错误的假设。因此，我的回答是根据我的理解，您认为这是一个问题。 RFC 1034/1035是DNS工作原理的基础，但是它们是较旧的技术文档，因此并不是很好的主题介绍/教程。维基百科上有关DNS的文章可能是更好的入门书。
DNS就像树一样工作（除了我们更多地将其作为根引用之外，因为根aka .位于顶部，然后我们讨论其下的内容）。每个节点在管理上都负责其下面的所有内容，并将下面的树的一部分委托给其他节点。
这样做的原因有很多，但事实上，目标之一是远离您当时拥有的全局hosts文件（DNS之前），其中包含所有可能的名称及其名称的列表。 IP。
现在，由于技术和非技术方面的原因，有了DNS，您就没有一个所有现有名称的集中列表。
从技术上讲，由于您可以在各个区域中使用通配符（示例中的情况，请参见下文），因此名称列表是无限的，或者至少很大，以至于您无法构建它。当然，它的变化率也将很难遵循。
从技术上讲，非严格地说，正如我所说的，每个节点都要负责...并且可以决定将其下面的域名（子节点）列表公开（此列表可以公开也可以不公开）。出于充分的原因，并且可能像使用DNSSEC NSEC枚举一样容易或可能不容易被规避，但这不是重点。
因此，让我们回顾一下您现在可以剖析的示例的核心主张：
我检查了来自icann的区域文件中的ews.com.link TLD，它不包含ews.com.link域名，当我发送DNS查询或ews.com.link挖掘时，我得到了以下提示响应
首先，当您说ICANN时，您可能更多是在谈论IANA（因为ICANN本身在日常DNS中没有任何技术操作）。 IANA处理根区域.，也称为顶点。总之，它基本上包含所有当前委托的TLD的列表。
该区域文件是公共的，可以通过多种方式检索：通过HTTP / FTP从IANA网站下载，或仅向AXFR之类的其中一个DNS根服务器发出f.root-servers.net DNS请求。
因此，如果您找到它并进行搜索，则在其中找不到ews.com.link是绝对正常的。但是您会发现.link是委派给某个注册表的当前有效TLD。
您也可以使用定位IANA Whois服务器的Whois：
$ whois -h whois.iana.org link
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
domain: LINK
organisation: Uniregistry, Corp.
[..]
whois: whois.uniregistry.net
status: ACTIVE
remarks: Registration information: http://uniregistry.link
created: 2014-01-09
changed: 2018-06-06
source: IANA
现在，您可以递归地执行相同的操作：.LINK是gTLD，因此根据ICANN合同。他们要求它（.LINK注册表）发布其区域文件。所有gTLD的要求都是相同的，相反，在ccTLD的情况下，很少能够获得其区域文件。
因此，如果您执行适当的步骤，将获得.LINK区域文件。再次，正如您所料，您将不会在其中看到ews.com.link，因为注册表已委派com.link（这是.LINK下的普通域名，与其他任何域名一样，请勿被第一个标签欺骗） com，这对决定在某个时间点购买它的注册人来说没有任何改变。然后随便使用它。
您可以在注册表权威名称服务器上签入DNS或使用注册表whois服务器来检查此com.link域名是否已在DNS中注册和委托：
$ whois -h whois.uniregistry.net com.link
Domain Name: com.link
Registry Domain ID: DO_fd33bffce176f0124de4523031e7b404-UR
Registrar WHOIS Server: whois.west263.com
Registrar URL: west263.com
Updated Date: 2017-10-12T09:33:41.832Z
Creation Date: 2017-07-26T20:26:32.723Z
Registry Expiry Date: 2020-07-26T20:26:32.723Z
Registrar: Chengdu West Dimension Digital Technology Co., LTD
和
$ dig @NS1.UNIREGISTRY.NET com.link NS +nodnssec +norecurse +nocookie +noall +auth
; <<>> DiG 9.12.0 <<>> @NS1.UNIREGISTRY.NET com.link NS +nodnssec +norecurse +nocookie +noall +auth
; (1 server found)
;; global options: +cmd
com.link. 900 IN NS ns4.myhostadmin.net.
com.link. 900 IN NS ns6.myhostadmin.net.
com.link. 900 IN NS ns5.myhostadmin.net.
com.link. 900 IN NS ns3.myhostadmin.net.
com.link. 900 IN NS ns2.myhostadmin.net.
com.link. 900 IN NS ns1.myhostadmin.net.
因此，该域名被委派给 myhostadmin 。从技术上讲，其背后的组织可以让任何人下载其区域文件（和/或允许AXFR请求），以使任何人都可以了解其下方的域名，例如您的ews.com.link。但是，由于开头所述的原因，并且由于该实体没有理由这样做，因此不会发生这种情况。
但是，通过查询负责的名称服务器，您可以轻松地检查给定名称的存在（即使以某种方式，即使在您没有访问权限的情况下，它也确实会在区域文件中列出）：
$ dig @ns1.myhostadmin.net. ews.com.link +nodnssec +norecurse +nocookie +noall +ans
; <<>> DiG 9.12.0 <<>> @ns1.myhostadmin.net. ews.com.link +nodnssec +norecurse +nocookie +noall +ans
; (3 servers found)
;; global options: +cmd
ews.com.link. 900 IN A 101.132.249.163
实际上，出于好奇，您会发现有通配符记录。您可以很容易地看到，用任意字符串替换ews并返回完全相同的结果（这表明域名的完整列表不能在zonefile中，因为此通配符使服务器生成针对以下内容的回复您用来查询的任何名称），或专门检查通配符记录：
$ dig @ns1.myhostadmin.net. *.com.link +nodnssec +norecurse +nocookie +noall +ans
; <<>> DiG 9.12.0 <<>> @ns1.myhostadmin.net. *.com.link +nodnssec +norecurse +nocookie +noall +ans
; (3 servers found)
;; global options: +cmd
*.com.link. 900 IN A 101.132.249.163
当您需要名称服务器来答复许多名称（不一定是事先知道的名称，并且可能会经常更改，而您不想重新配置名称服务器的每个名称）时，使用通配符记录是一项常见功能。从技术上讲，使用通配符并非没有缺点，至少需要谨慎，但它是DNS的核心功能。
因此，所有这些都解释了为什么ews.com.link存在于DNS中（如果您查询它，由于有了A记录，您将获得一个IPv4地址），但您将找不到它，就像在任何情况下一样区域文件，首先是因为它不按预期在.（根）或com（TLD）或com.link区域文件中不存在，即使您可以访问它，只是因为它是一个通配符，所以特定的ews名称甚至都不会写在任何地方。
您提供的所有其他名称根据其常见的something.COM.something格式可能完全相同。我希望通过以上解释，您可以重新检查您喜欢的任何一种，并准备好通过所有这些解释来进一步了解此案。
大约
以下域名的结果与我在其tld区域文件中检查的结果相同
对于您列出的所有名称，您将在com.TLD区域文件中找到TLD，但找不到whatever.com.TLD，因为在TLD区域文件中，对于任何名称TLD。