DNS currently suffers from a number of significant issues that need to be considered and potentially addressed. The most significant issue involving the current infrastructure deals with the fact that the current generic domain name space is too "flat" with the result that name conflict, including trademark rights will become increasing unavoidable.
The congestion in the .COM domains makes competition for easily recognizable names very difficult to manage. Furthermore, the monopoly operation of this single top-level domain by NSI presents further problems, including scalability, reliability, and fairness.
Eliminating the sole monopoly operation over .COM alone does not seem that it will necessarily eliminate all problems, since it would be conceivable that competition between registries operating the .COM domain might arise and create further problems, besides the obvious ones of database management and coherency that would need to be ensured if multiple registries control a single domain.
Retiring .COM would appear to be an extreme measure at this stage. If the DNS becomes more scalable and less expensive, .COM may in due course be considered to be obsolete for most purposes, and at that time the question of how much longer to maintain it might arise. Meanwhile, the existing problems in .COM should be urgently addressed.
A more reasonable solution to these problems would be to create several new top-level domains that would allow for a greater level of diversity between registered domains and less of a need for corporations to need to want to control all domains containing a substring of their registered trademark. Conflicting domains, systems, and registries should not be permitted to jeopardize the inter-operation of the Internet.
Competition in and expansion of the domain name registration system should be encouraged. By allowing the creation of new top level domains, new registries could be allowed to control the new domains independently of others without negatively affecting the operations of the pre-established top-level domains being operated by other registries
Furthermore, the choice of top-level domain registry should not be sufficient for any service provider to deny the ability of service users to access content. Service providers should be required to make a reasonable effort to support new top-level domain registry providers as soon as they are available. No content-provider should be denied accessibility to others due to the management decisions, operation policy, service base, or any other reason.
The Internet should be primarily a global inter-operating system ensuring unrestricted access from any Internet address to any other. The responsible organizations should ensure that the introduction of new Domains and/or new Root Servers should be compatible with that principle. The expansion of the Internet will no doubt require that an increasing number of top level and second level domains be introduced, but the consequences for the network's overall integrity will have to be carefully checked and monitored over time.
The overall framework for accommodating competition should be open, robust, efficient, and fair. The DNS should not introduce new forms of dominance or anti-competitive restrictions into the Internet at the time when other aspects of the communications industry are benefiting greatly from the introduction of competition. Internet users should also benefit from competition in the telecommunications industry.
Compared to other spectrums that are regulated by a registrar, there are actually very little limitations on the capacity on the DNS that is currently implemented. For instance, the radio spectrum is limited by physical limitations imposed by physics. However, given sufficient bandwidth and memory of machines serving the top level domains to requesting clients, there should be no significant limitations to the number of domains or hosts that can be accommodated.
Other implementation limitations have mostly been addressed by recent RFC's and for the most part are addressable. Incremental zone transfers can be supported to eliminate the need to completely send the entire zone file when an update is detected. Use of the NOTIFY signal can be used to indicate to DNS secondaries that an update to the zone file has occurred, eliminating wasteful network and cpu accesses required in frequent polling activities.
One of the most significant issues that is still a significant issue in current DNS servers is the lack of security when performing zone transfers or even standard queries. Since DNS queries are primarily done over UDP, it is relatively easy to spoof packets originating from fake IP addresses, since the transmission of a single UDP packet doesn't require a bidirectional handshake between the two parties to occur, like in TCP/IP.
By utilizing this ability to spoof packets, it would be possible for a third party to forge DNS response queries that appear to be originating from an authoritive server for a domain. Depending on DNS server implementation, it may be possible to "precache" the response to a DNS query so that when an application attempts to verify a host/ip addresses's associated DNS entry, its local DNS server will return the bogus pre-cached value. This precise problem was present in some earlier versions of BIND.
Although security additions to DNS have been proposed, and experimental Secure DNS servers implemented for testing purposes, such mechanisms have not been widely deployed. Furthermore, most DNS administrators do not understand the need to implement a Secure DNS, even if such software were readily available for use and deployment.
DNS is used constantly for authentication and logging purposely, so much that its abundant use frequently goes ignored. Many sites do host security access blocking (through "tcpwrappers" and the use of "hosts-allow" and "hosts-deny" files) to do host authentication to services based on their originating host/domain name. Additionally, if one attempts to send email to a particular address, one expects that the mail cannot be unfairly misdirected because of a spoofed DNS lookup to one of the delivery machines along the path. Furthermore, if someone visits a website, they would like to be able to depend on the fact that it will connect to the site that they are expecting. All of these issues emphasize the needs for a more secure DNS server implementation to be deployed and made available.
Other pages relating to the criticisms of the current DNS infrastructure can be found at a number of places on the net, including: