(See also Handle System Overview, Chapter 6, The Handle System and other Internet Services, RFC 3650.)

The Domain Name System (DNS), originally designed and used for mapping domain names into IP Addresses for network routing purposes, is one of a number of existing Internet identifier services or specifications that provide some of the functionalities of the Handle System. It is also the one to which the Handle System is most frequently compared. However, there are similarities and differences in both the design and intended use of the two systems.

Naming

The DNS naming hierarchy reflects a control hierarchy. That is, whoever runs .com controls who runs mybusiness.com and whoever controls mybusiness.com controls who runs branch.mybusiness.com, etc. This is not necessarily true of the Handle System. Any prefix (also called a naming authority (NA)) can be, and at the moment all are, at the same level. So administration of 20.1.2.3 can be completely separate from 20.1.2 which can be completely separate from 20.1 and so on. They can all live in root and all be controlled by different sets of administrators and all point to different handle services.

Two related points:

• while no one has implemented it, the specification does allow for delegation DNS-style, that is, 20.1.2.3 can exist but not live on the global root, and to find out anything about it you have to talk to the service responsible for 20.1.2;

• the naming hierarchy can be used in permissions to create new prefixes. That is, we could (and on occasion have) set up a prefix, 20.1 and give the administrators of 20.1 the permission on the global root (GHR) to create new prefixes that begin 20.1, e.g., 20.1.2, but without the ability to create anything that starts with 21. Once created, however, everything falls back to being flat.

Distributed Administration

Each identifier and prefix can have its own set of administrators independent from the system administrator. Handle administrators can add/delete identifier and identifier values via the handle system protocol securely over the public Internet. DNS systems may have ad hoc mechanisms for updating records, but there is a difference in perspective on data ownership. In DNS, the system administrator is generally considered the owner of the data, while in the Handle System the prefix administrator is considered the owner. In cases where there are many users creating data, with only a few servers, having prefix-level data ownership is desireable. Having a consistent administration protocol also makes it easier to develop programs for creating and modifying data, independent of any particular server implementation.

Proxies

Making DNS resolution work behind SOCKS proxies may be difficult, depending on the DNS library used. The handle library supports SOCKS proxies. Making DNS resolution work from behind HTTP proxies is probably impossible. The handle library supports HTTP proxies.

Unicode

The Handle System is 8-bit clean, so full Unicode is supported. There are hacks to make DNS support 8-bit character sets, but they are not widely implemented.

Replication

Mirroring in the Handle System has fine granularity. If a single record is updated, the server will copy only that record to the mirror servers. In DNS, if a single record is updated, the entire zone is invalidated, and all records must be copied to mirror servers.

Certification

DNS has to be fast, especially at the root. This makes it tend toward policies that aren't very good for alternative uses. For example, certificates aren't as robust as in the Handle System, because a design constraint of DNS-SEC was that all signatures had to be pregenerated. DNS-SEC also depends on X.509, which may or may not be desirable. Finally, DNS-SEC may not be present in all DNS implementations. The Handle System has more flexible and robust certification support.

Access Control

The Handle System has support for access control and authentication. DNS does not.

Record Size

The DNS protocol defaults to UDP, but if a record is greater than 512 bytes, the server returns an error requiring the client to resend the request over TCP, making for two round trips. If you are storing a lot of metadata, that's two round trips for every message. If you are storing extremely large amounts of data, DNS has a 64K limit, while the Handle System has a limit closer to 4G.

The handle protocol supports UDP chunking, so larger responses are possible over UDP. The handle library also makes it possible to exclusively use TCP, eliminating the issue altogether. Some DNS libraries may also allow forced TCP, but at the cost of losing the speed of UDP.

A lot of DNS servers don't support TCP at all, and if your organization's DNS servers don't, you will end up losing the DNS hierarchy and put a greater burden on the primary servers and the global DNS roots. Some more draconian ISPs don't allow users to bypass their DNS. If these ISPs don't support TCP-DNS, there is no way to resolve DNS records larger than 512 bytes.