.com, .org, .net, .gov, etc... are all registered Top-Level Domains (TLDs) that ICANN recognizes.
You can pay to lease a domain like "pickles.com" and everyone on the official DNS would recognize that. Your ISP will generally add their dns servers to your connection which will query ICANN. Google's DNS servers 8.8.8.8 and 8.8.4.4 do the same as well.

But what about running your own DNS root nameserver? You could have any domain you want. You could have services respond on the domains you specify. The problem is that you would run into many conflicts with existing registered domains.
A solution is to create your own TLD like .sekretclub or .pickles by running your own dns

Note: Companies will usually run an internal DNS server for intranet services, like "wiki.lan" or "intranet.local".

Malicious or private websites can choose to listen on domains that only exist on underground DNS servers. The DNS server can be a word-of-mouth IP address or work through some sort of invite system.

Proof of Concept - Underground Community

I created the TLD ".sekretclub" which does not exist on ICANN's regulated list of TLD's.

Bind is super simple to setup and configure

Querying the server responds with the IP of the domain

Then I added some domains to that, such as "forums.sekretclub", "hiddenwiki.sekretclub", "markets.sekretclub"

Super Sekret forums hosted only on this domain

The servers that have these IP's to are set to show the webpage only when that domain is requested.

It is very easy to add DNS servers to your workstation, so I simply added the IP address of the DNS server I created.

Security for the Club

We want this DNS to be invite only, but the DNS protocol does not allow for this feature

A solution is to have a database of whitelisted IP addresses that the DNS server includes in its firewall.

It would be easy to create a register page with invite codes to be included on the whitelist.

The DNS server then becomes the gateway into the underground services. The servers running the services should have the same firewall whitelist system in place. That way if someone knows the IP address and domain the service is listening on, they can't manually edit their /etc/hosts file to bypass the DNS server altogether.

This script on a cron or something would get the job done:

Loading ....

If the main DNS server is compromised, then the entire database of domains and IP's would be leaked. This single point of failure is definitely not ideal. A secondary DNS server could be created, but the main records would still be managed by one person.

If the service is infiltrated, then the server operators can migrate to new IP's and just update the dns entry. The DNS gateway can switch to a new IP as well.

Proof of Concept - Hidden Malware C2 Servers

Malware calls back to control. That is how they receive commands, exfiltrate data, etc...

Since hardcoding IP addresses into malware is generally a bad idea, most use domain names now. It is still easy to figure out what domains malware is calling out to, but it at least gives the attacker the opportunity to change the IP behind the domain. Instead of paying for domains, malware authors will generally just use free subdomains using services like no-ip.org.

The problem is that those domains are all still regulated by ICANN, and can be taken down or tracked with a request from an authority.

Some adware would change a user's DNS settings to point to malicious IP's when looking up domain names:

"The botnet operated by Rove Digital altered user DNS settings, pointing victims to malicious DNS in data centers in Estonia, New York, and Chicago. The malicious DNS servers would give fake, malicious answers, altering user searches, and promoting fake and dangerous products. Because every web search starts with DNS, the malware showed users an altered version of the Internet." http://www.dcwg.org/

Malware sometimes uses their own DNS servers to call back to domains that would be very difficult to track since they are not on ICANN's registry. The most an antivirus solution can do is alert if the user's DNS settings changed.