|
This article proposes the reservation of a special use TLD to allow a more convenient addressing of devices by general physical location or context.
Introduction
As wireless networking and devices become more common there may be a need for a convenient way to address hosts by physical location or context, especially when the users themselves are using mobile or wearable devices.
A step towards this could be by reserving a special public use TLD (.here in the examples). Then this TLD can be independently hosted at various locations, so that each resulting .here domain falls under the context of that particular location. For a similar concept see RFC1918.
Example Usage of .here TLD
As an example a user could obtain a list of registered devices in each particular room or building by visiting https://all.here/ or perhaps just https://here/. Other forms could include https://who.here/ and https://what.here/
Say if the user wishes to control an air conditioner in a room, the user could visit https://airconditioner.here/ for the control page. The user could also “bookmark” popular settings such as https://airconditioner.here/settemp?celsius=25 and use it from room to room (assuming the air conditioners accept the same parameters).
Users of wearable devices could also address and access each other in a similar manner after registering with the location - e.g. https://lyeoh.here/sendobjectform or https://somebody.here/getobject?id=12345
Registration with an area could be done with DHCP [RFC2131] and dynamic DNS.
Various Considerations
Users could get the wrong address depending on how the default domain search is implemented - e.g. xxxx.here first, then xxxx.mydomain.com or vice versa. Also, it should be assumed that parties controlling the physical location could attempt to spoof or subvert communications.
Specifying .here. does not guarantee locality. Users may inadvertently or intentionally access devices at a different physical location.
Third parties could reserve a similar TLD (e.g. .her.) in order to catch typographical errors or unsuspecting users. As .her. and .he. may well become future TLDs, perhaps a less vulnerable name than .here should be used instead. A less elegant alternative is to also reserve the typos, but the Gere’s (e.g. Richard) of the world may protest.
The .here TLD has already been reserved by a member of the ORSC. So to avoid conflict another TLD may have to be chosen, giving due consideration to the various alternative root zones. It seems that .local or .loc could be used but at risk of confusion with .localhost [RFC2606].
References
[RFC2606] D. Eastlake and A. Panitz, “Reserved Top Level DNS Names”, RFC2606, June 1999.
[RFC2131] R. Droms, “Dynamic Host Configuration Protocol”, March 1997.
[RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, “Address Allocation for Private Internets”, February 1996.
Sponsored byVerisign
Sponsored byCSC
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byRadix
Sponsored byIPv4.Global
Sponsored byDNIB.com
It is already possible to define a location for any name in DNS. (See http://www.ckdhr.com/dns-loc/ )
There already is a LOCation resource record defined for DNS.
DNS allows many attributes to be associated with a name - this is why DNS is so flexible. If one turns DNS on its head and make those attributes part of the name itself then the name space unnecessarily explodes manyfold and we end up with two different means of assigning attributes to names.
We already have a method to do location. It works and has worked for years.
I want to extend my previous comment - I somewhat misunderstood what you are proposing.
I believe that what you want to do is more in the realm of discovery of local resources than in the realm of the domain name system. The concept of “proximity” is something that is full of nuances - for example in a high-rise office is the “nearest” printer the one 5m away, directly above on the next floor or is it the one that is 20m away across the hallway?
Proximity is a measured in multiple dimensions and is a relative metric. DNS, even if local zones were established, can merely represent a relatively static view of those dimensions.
I’ve proposed over the years a pheromone-like resource discovery protocol that does exhibit the kind of locality that you are looking for.
Hello Lincoln,
As you observed, we created the .HERE top level domain in December, 1999 which currently resolves in the ORSC Root Zone (as well as a few others).
‘Special use’ TLDs would seem to have some limitations in the concept you describe. (I perceive this as internalizing them rather than making them useful for communications from external locations…i.e. “the rest of the net”.)
We’re fully supportive of the concept however and think that with proper coordination the .HERE TLD could fill a gap just as you describe. We’ve been approached by someone, in fact, who had a similar concept using a ‘convention’ of SLDs in .com/.net space, but he was only able to gather 15-20% of the domains needed for his convention to work in .com space.
I’d welcome the possibility of any collaboration from you or anyone on this concept and the idea could be tested here in ORSC namespace. :) Feel free to contact me.
Regards,
Dena A. Whitebirch