An important part of the IPv4 protocol is that there are ranges of addresses that are reserved and cannot be used on the Internet. These include the localhost address 127.0.0.1 and the ranges for LANs, such as the address in 192.168/16 that are commonly used with retail Internet routers when assigning LAN addresses.
These addresses are critical in making the Internet work since they allow the Internet to easily coexist with private networks, especially when using standard devices. For example, every router sold by a company can have an admin address of 192.168.0.1 without interfering with other routers of the same brand. However, while there is support for naming devices on a network, a major problem is that unlike with IP addresses, DNS does any robust conventions to prevent conflicts with internal networks.
This lack of naming rules has caused problems as new top level domains are conflicting with names of internal resources and disrupting access. Before administrators only had to worry about a small set of conflicts, such as “com” or “ca” but now that anything can be a TLD, any name could potentially conflict with something on your network. In addition, the .local TLD does not seem to be robust enough to help this situation.
To solve this and perhaps promote more consistent naming of resources, network administrators and standard bodies should consider adopting the following TLDs:
.localhost
- This already exists and would continue to refer to 127.0.0.1 alone.
- Subdomains could point to 127.0.0.1 or to another 127/8 address, but nowhere else.
.lan (Local Area Network)
- These would only point to LAN addresses, such as the 192.168/16 addresses.
- Lookup would only take place within the LAN, never consulting DNS servers on the Internet.
- “lan” itself could point a designated device, such as one providing DHCP services.
- A device could be responsible for its own name and can subdomain that name for resources available though that device.
- There could also be a way to define domain trees that are managed independently of the devices they point to, such as on the device with the DHCP server.
.vpn (Virtual Private Network)
- As a synonym for .lan, this would exist mainly to make it easier for the user to understand where their resource is located. For example, a computer at a head office named files.mycompany.vpn makes more sense than files.mycompany.lan since the server is might not be in the user`s local area network.
.ian (Internet Area Network/Internal Area Network)
- This would indicate that the domain namespace is defined using user controlled DNS servers or host computers.
- The IP addresses can be any valid IP address.
- Public DNS servers should not return information about a .ian domain unless the .ian address is acting like a proxy server.
.wan (Wide Area Network aka the public Internet)
- This would explicitly say the address of the resource your want in on the public Internet and not a localhost address, LAN or VPN.
- This would be a valuable safeguard in some cases, such as security or in the event of overloaded names not named with the above conventions.
- An administrator could also use this like a telephone outside access code and require all public addresses require .wan, as if “wan” is the name of a proxy server.
In the event there is not an extension the best default would to be assuming an implicit .wan it there is a period in the name and .lan/.vpn/.ian if it is a single name. For these addresses, it would be up to the administrator or user to determine the best naming scheme to avoid and resolve addresses issues.
I feel that using this naming scheme would make DNS more robust and would allow for its future expansion, such as naming devices in the Internet of Things.
