Changes

* FriGate: Blockchain DNS services provided through a proxy, accelerates access to blocked websites, encrypts traffic, opens Tor sites, and supports EmerDNS.<ref>[https://chrome.google.com/webstore/detail/frigate-vpn/gmgimpdjmagalimgdaeacfcpoimfpikm FriGate, Web Store, Chrome]</ref><ref>[https://fri-gate.org/ FriGate]</ref>

* FriGate: Blockchain DNS services provided through a proxy, accelerates access to blocked websites, encrypts traffic, opens Tor sites, and supports EmerDNS.<ref>[https://chrome.google.com/webstore/detail/frigate-vpn/gmgimpdjmagalimgdaeacfcpoimfpikm FriGate, Web Store, Chrome]</ref><ref>[https://fri-gate.org/ FriGate]</ref>

* [https://handshake.org Handshake]: A DNS-backwards compatible naming protocol. It adds a distributed, decentralized blockchain-based system to the root zone file where TLD ownership information is stored. No one controls it and anyone can use it, allowing for a root zone that is uncensorable, permissionless, and free of gatekeepers. Every peer in the Handshake network [[Cryptography|cryptographically]] validates and manages the root zone, eliminating the need for the Certificate Authority system.<ref>[https://learn.namebase.io/about-handshake/about-handshake About Handshake, Namebase]</ref> The Beacon browser can natively access the

* [https://handshake.org Handshake]: A DNS-backwards compatible naming protocol. It adds a distributed, decentralized blockchain-based system to the root zone file where TLD ownership information is stored. No one controls it and anyone can use it, allowing for a root zone that is uncensorable, permissionless, and free of gatekeepers. Every peer in the Handshake network [[Cryptography|cryptographically]] validates and manages the root zone, eliminating the need for the Certificate Authority system.<ref>[https://learn.namebase.io/about-handshake/about-handshake About Handshake, Namebase]</ref> The Beacon browser can natively access the Handshake domains.

Handshake domains.

:: ''Potential shortcomings'': [[Andrew Allemann]] points out that: Handshake is decentralized at the top level, allowing many companies and people to create top-level domains. However, it is centralized at the second level. [[Namecheap]] sells Handshake domains like .creator, .oo, and individuals pay annual fees for them. These blockchain-based domains have renewal fees and few people can access them. Moreover, with so many top-level domains, few to none may gain general recognition, a problem some people cited in the 2012 [[New gTLD Program]].<ref>[https://domainnamewire.com/2022/01/13/blockchain-domains-and-the-big-challenges-they-face/ Blockchain Domains' Challenges, DNW]</ref>

:: ''Potential shortcomings'': [[Andrew Allemann]] points out that: Handshake is decentralized at the top level, allowing many companies and people to create top-level domains. However, it is centralized at the second level. [[Namecheap]] sells Handshake domains like .creator, .oo, and individuals pay annual fees for them. These blockchain-based domains have renewal fees and few people can access them. Moreover, with so many top-level domains, few to none may gain general recognition, a problem some people cited in the 2012 [[New gTLD Program]].<ref>[https://domainnamewire.com/2022/01/13/blockchain-domains-and-the-big-challenges-they-face/ Blockchain Domains' Challenges, DNW]</ref>

* [http://i-dns.net/ iDNS]: Beginning as a research project at the University of Singapore, this DNS ran under the auspices of the Asia-Pacific Networking Group in 1998 and was incorporated in 1999. i-DNS successfully test-bedded [[IDN]]s over a 6-month period, in collaboration with [[CNNIC]], and the NICs of Japan, Korea, Hong Kong, Taiwan, Malaysia, Thailand, and Singapore.<ref>[http://www.i-dns.net/company/history/history.html Our History, i-DNS]</ref>  

* [http://i-dns.net/ iDNS]: Beginning as a research project at the University of Singapore, this DNS ran under the auspices of the Asia-Pacific Networking Group in 1998 and was incorporated in 1999. i-DNS successfully test-bedded [[IDN]]s over a 6-month period, in collaboration with [[CNNIC]], and the NICs of Japan, Korea, Hong Kong, Taiwan, Malaysia, Thailand, and Singapore.<ref>[http://www.i-dns.net/company/history/history.html Our History, i-DNS]</ref>  

===Functionality===

===Functionality===

Commentators note that alternative name systems today are clunky, hard to reach, and expensive; they put the onus on browsers, which do not want to govern.<ref>Tyler Mason, GoDaddy Blockchain Domain Names Webinar, 12/1/2021</ref> Adapting applications to use multiple alternative naming systems is complicated and particularly if the names overlap. Applications would have to know which alternative naming system to look up for each domain name or define an order for making the lookups. The approach for defining an order in the DNS has proved non-deterministic and problematic.<ref>[https://www.icann.org/en/system/files/files/octo-034-27apr22-en.pdf Challenges with Alternative Name Systems, pg. 8, ICANN OCTO, April 27, 2022]</ref> Web gateways do not require any set up on the client's side, but they have to be maintained over time, must scale with demand, and are a single point of failure and a target for [[Threat Actor|malicious actors]].  

Commentators note that alternative name systems today are clunky, hard to reach, and expensive; they put the onus on browsers, which do not want to govern.<ref>Tyler Mason, GoDaddy Blockchain Domain Names Webinar, 12/1/2021</ref> Adapting applications to use multiple alternative naming systems is complicated and particularly if the names overlap. Applications would have to know which alternative naming system to look up for each domain name or define an order for making the lookups. The approach for defining an order in the DNS has proved non-deterministic and problematic.<ref>[https://www.icann.org/en/system/files/files/octo-034-27apr22-en.pdf Challenges with Alternative Name Systems, pg. 8, ICANN OCTO, April 27, 2022]</ref> Web gateways do not require any set up on the client's side, but they have to be maintained over time, must scale with demand, and are a single point of failure and a target for [[Threat Actor|malicious actors]]. When a plurality of naming systems is deployed, the same number of bridges must be built, and users need to know to which alternative naming system the domain is registered to be able to use the right bridge to reach it.<ref>[https://www.icann.org/en/system/files/files/octo-034-27apr22-en.pdf Challenges with Alternative Name Systems, pg. 12, ICANN OCTO, April 27, 2022]</ref>

====Early altroots====

====Popularity====

* Limited audience: few people can view sites or send emails and only to those also using domains in the alternative TLDs. This could be improved through the use of special helper applications, or if a custom configuration was made to their computer, or to their nameservers, or a custom configuration at an ISP upstream in the DNS hierarchy. None of these solutions were as comprehensive as being listed in the default nameservers that are seen when an operating system starts. Whilst technically trivial to set up, actually running a reliable root server network, in the long run, is a serious undertaking, requiring multiple servers to be kept running 24/7 in geographically diverse locations. During the dot-com boom, some alt-root providers believed that there were substantial profits to be made from providing alternative top-level domains. Only a small proportion of ISPs actually use any of the zones served by alt-root operators, generally sticking to the ICANN-specified root servers. This in turn led to the commercial failure of several alternative DNS root providers.

* Limited audience: few people can view sites or send emails and only to those also using domains in the alternative TLDs. This could be improved through the use of special helper applications, or if a custom configuration was made to their computer, or to their nameservers, or a custom configuration at an ISP upstream in the DNS hierarchy. None of these solutions were as comprehensive as being listed in the default nameservers that are seen when an operating system starts. Whilst technically trivial to set up, actually running a reliable root server network, in the long run, is a serious undertaking, requiring multiple servers to be kept running 24/7 in geographically diverse locations. During the dot-com boom, some alt-root providers believed that there were substantial profits to be made from providing alternative top-level domains. Only a small proportion of ISPs actually use any of the zones served by alt-root operators, generally sticking to the ICANN-specified root servers. This in turn led to the commercial failure of several alternative DNS root providers.

====Blockchain Domains====

====Blockchain Domains====