Based on your comments and edits you may have some wrong assumptions about how the DNS works and what is a zonefile and what is in it. So my answer below will be from what I understand you are viewing as a problem. RFC 1034/1035 are the basis on how the DNS works, but they are old and technical documents so not really good introduction/tutorial on the subjects. Wikipedia articles on DNS may be better starters.
The DNS works as a tree (except that we reference it more as roots, because the root aka . is at the top and then we discuss things below it). Each node is administratively responsible of everything below it, and delegates part of the tree below to other nodes.
This has been done for many reasons but one of the target was in fact to go away from the global hosts file where you had at that time (pre DNS) a list in it of all possible names and their IP.
Now with the DNS you do not have a central list of all existing names for both technical and non technical reasons.
Technically, since you can have wildcards in various zones (which is the case in your examples, see below), the list of names is infinite or at least so big that you can not build it. Of course, its rate of change would also be difficult to follow.
Non technically, as I said each node is responsible for what it does... and may decide that the list of domain names (sub nodes) it has below it is note to be given publicly (which may or may not be for good reasons, and may or may not be easily circumvented like with DNSSEC NSEC enumeration, but that is not the point here).
So let us go back with your core assertion on an example we can now dissect:
I checked the zone file for ews.com.link TLD from icann and it does not include ews.com.link domain name, when I am sending a DNS query or dig for ews.com.link, I am getting below response
First, when you say ICANN you are probably more talking about IANA (as ICANN by itself has no technical operations in the day to day DNS). IANA handles the root zone, ., also called the apex. In summary, it basically contains the list of all currently delegated TLDs.
This zonefile is public, and can be retrieved in various ways: downloading by HTTP/FTP from IANA website, or just doing an AXFR DNS request to one of the DNS root servers allowing it, like f.root-servers.net.
So if you get it, and search in it, it is absolutely normal that you do not find ews.com.link in it. But you will find .link which is a current valid TLD delegated to some registry.
You can check using whois targeting IANA whois server too:
$ 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
Now you can recursively do the same thing: .LINK is a gTLD so under the ICANN contracts. They mandate it (the .LINK registry) to publish its zonefile. This requirement will be the same for all gTLDs, and at the opposite side, in ccTLDs case it is rare to be able to get their zonefiles.
So if you go through th appropriate procedures you will get the .LINK zonefile. Again, as expected you will not see ews.com.link in it, because the registry has delegated com.link (which is a normal domain name under .LINK like any other, do not be fooled by first label being com this changes nothing on the explanation) to some registrant that decided to buy it at some point. And then use it any why it wants.
You can check in the DNS on registry authoritative nameservers or use registry whois server to check that this com.link domain name has been registered and delegated in the 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
and
$ 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.
So this domain name is delegated to myhostadmin. The organisation behind it could, technically, offer anyone to download its zonefile (and/or allow AXFR requests) for anyone to know all about domain names below it, like your ews.com.link. However that does not happen for the reasons outlined at the beginning, and because this entity has no reason to do it.
However you can easily check that the given name exists (so is indeed listed, in some way, in the zonefile, even if you do not have access to it) by querying the responsible nameservers:
$ 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
In fact, with some curiosity, you will discover that there is a wildcard record. You can easily see that by replacing ews by any random string and getting back the exact same result (which shows that the complete list of domain names can not be in the zonefile, as this wildcard makes the server generate the reply for any name you are querying it with), or checking specifically for the wildcard record:
$ 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
Using a wildcard record is a common feature when you need to have nameservers to reply to many names, not necessarily known in advance and that can change often, when you do not want to reconfigure your nameservers each name. Technically using a wildcard is not without drawbacks, and needs at least to be careful but other than that it is a core DNS feature.
So this all explains why ews.com.link exists in the DNS (if you query for it you get an IPv4 address back thanks to the A record) but you will not find it, as is in any zonefile, first because it does not exist, as expected, in the . (root) or com (TLD), nor in the com.link zonefile, even if you would have access to it, just because it is a wildcard so the specific ews name is not even written anywhere.
All the other names you give are probably in the exact same case based on their common something.COM.something format. I hope that with the above explanations you could just recheck any of them you like and be prepared to understand the case more with all these explanations.
Again, about
The same results for below domain names which I check them in their tld zone file
for all the names you list you will find com.TLD in the TLD zonefile, but not whatever.com.TLD as this has nothing to do in the TLD zonefile, for any TLD.
