USING DNS FOR GLOBAL DISCOVERY OF ENVIRONMENTAL

SERVICES

Andreas Kamilaris and Andreas Pitsillides

Networks Research Laboratory

Department of Computer Science, University of Cyprus, Nicosia, Cyprus

Keywords:

Domain Name System, Service Discovery, Web of Things, DNS-SD, REST, Environmental Services.

Abstract:

Embedded sensor devices are getting pervasive in our everyday lives. Due to the penetration of the Internet in

the real world, sensor devices become globally addressable, while the Web of Things envisions Web presence

to these devices and their services. Future abundance of Web-enabled sensors would imply the need for efﬁ-

cient techniques for globally discovering them. To solve this problem using the existing Internet infrastructure,

we explore the exploitation of the Domain Name System (DNS) as a scalable, ubiquitous, real-time directory

mechanism for embedded devices. We investigate some practical issues that could arise from such an attempt

and we discuss the potential of this approach.

1 INTRODUCTION

Embedded computing is becoming an integral part of

our lives. It is expected that millions of tiny sen-

sors are measuring with high precision environmental

conditions such as wind and temperature or physical

events such as pressure and motion.

Lately, the Internet is penetrating slowly-slowly

into the real world of physical objects. The introduc-

tion of IPv6 and the efforts for porting the IP stack on

embedded devices (Dunkels et al., 2004), enable the

vision of a global Internet of Things (IoT) (Gershen-

feld et al., 2004).

While the IoT brings interoperability between het-

erogeneous devices at the network layer, there is still

a need for consensus at the application layer. To ad-

dress this need, the Web of Things (WoT) (Wilde,

2007), (Guinard et al., 2010) reuses well-accepted

and understood Web standards to interconnect IP-

enabled resource-constrained devices. Thus, embed-

ded sensors can become fully integrated to the Web,

directly by embedding Web servers on them (Yazar

and Dunkels, 2009) or indirectly by means of gate-

ways (Kamilaris et al., 2011).

In the future, Web-enabled sensor devices will

constitute the large majority of the Web popula-

tion. These devices will be deployed around the

world to measure with high accuracy the physical

environment, exposing their functionalities as open

Web APIs. These Web APIs would probably con-

form to the REST architectural style (Fielding, 2000),

(Richardson and Ruby, 2007), which is a core element

of the WoT.

indent In general, there do not exist yet standard-

ized, scalable and ﬂexible ways to globally discover

these embedded devices, based on their characteris-

tics and capabilities. Dyser (Ostermaier et al., 2010)

and Snoogle (Wang et al., 2008) are early efforts to-

wards real-time discovery of physical entities, how-

ever, they either require additional Web infrastructure

or they do not scale for the World Wide Web. On the

other hand, microformats

suggest ways for making

HTTP data available for indexing and searching, but

their utilization for sensor devices would augment our

dependency to commercial search engines.

We believe that service discovery of embedded

sensor devices needs to be ubiquitous to the users of

the Web. The proposed solution must comply with ex-

isting Internet standards and should not require major

changes to the existing technical equipment and pro-

tocols. Users should be able to discover environmen-

tal services simply by typing related keywords in their

favorite Web browser. In this way, discovery of phys-

ical devices may be similar to the way we discover

Web sites through search engines.

In this paper, we propose to exploit the existing

Internet infrastructure to achieve real-time discovery

of embedded devices and environmental services. We

investigate the utilization of the Domain Name Sys-

tem (DNS) as a scalable, pervasive, global meta-data

http://microformats.org/

280

Kamilaris A. and Pitsillides A..

USING DNS FOR GLOBAL DISCOVERY OF ENVIRONMENTAL SERVICES.

DOI: 10.5220/0003953302800284

In Proceedings of the 8th International Conference on Web Information Systems and Technologies (WEBIST-2012), pages 280-284

ISBN: 978-989-8565-08-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

repository for embedded devices, and its extension for

supporting location-based discovery of Web-enabled

physical entities.

Applying an existing technology for discovery of

environmental services, especially one that has been

ubiquitous for decades, offers many advantages, in-

cluding well-deﬁned support, easy conﬁguration, ex-

perienced developers and users, as well as availability

of open-source implementations.

The general idea of exploiting DNS for service

discovery is not new. DNS-based Service Discovery

(DNS-SD) (Cheshire and Krochmal, 2011a) proposes

using standard DNS programming interfaces, servers

and packet formats to browse a network for ser-

vices. Similarly, Multicast DNS (mDNS) (Cheshire

and Krochmal, 2011b) provides the ability to perform

DNS-like operations on a local network in the absence

of any conventional unicast DNS server.

Even though both protocols have been originally

designed for device/service discovery in local net-

works, DNS-SD has been extended to provide wide-

area service discovery. However, this functionality for

service advertising is domain-centric, meaning that

users are only able to be informed about services of-

fered in some particular domain. In contrast, our pro-

posal is service-centric, envisioning to enable global,

real-time, location-based discovery of pervasive ser-

vices, offered by Web-enabled sensor devices.

In the rest of the paper we examine the feasibil-

ity of this idea, addressing a number of practical is-

sues. Our approach conforms to the DNS-SD proto-

col, where possible.

2 ENVIRONMENTAL SERVICE

DISCOVERY THROUGH DNS

DNS is a hierarchical, distributed naming system for

computers. Its main functionality is the translation

of domain names meaningful to humans into IP ad-

dresses meaningful to machines. DNS distributes the

responsibility of assigning domain names and map-

ping those names to IP addresses by specifying au-

thoritative name servers for each domain. Authori-

tative name servers are responsible for their particu-

lar domains, and in turn can assign other authoritative

name servers for their sub-domains. This mechanism

allowed the DNS to be distributed and fault-tolerant.

Domain names consist of labels that are concate-

nated and delimited by dots, such as www.webist.org.

The right-most label indicates the top-level domain,

which is org in the previous example.

In the following subsections, we examine how to

change the organization of DNS to support location-

based, real-time discovery of environmental services.

2.1 Device Registration

We propose the inclusion of a new top-level domain

at the DNS, which is the env domain. This domain

is intended to support all embedded devices and envi-

ronmental services which are enabled to the Web and

registered to the DNS.

Specialized authoritative name servers may be re-

sponsible for this domain. These .env domain name

servers shall allow real-time registration of physical

devices and their (RESTful) Web services through

Dynamic DNS (DDNS) (Rekhter et al., 1997).

In general, a particular service

instance can be

described in DNS using SRV (Gulbrandsen et al.,

2000) and TXT (Mockapetris, 1987) records. A SRV

record has a name of the form:

< Instance > . < Service > . < Domain > (1)

and gives the target host and port where the service

instance can be reached. The DNS TXT record of

the same name gives additional information about this

instance, in a structured form using key/value pairs

Whenever a Web-enabled sensor device becomes

available on the Web, it would create a request to the

.env DNS server, asking for registration. In this re-

quest, the device must specify its name, location and

the services it offers. The .env server could offer a

Web API, allowing sensor devices to POST their dis-

covery details in HTTP requests. In case all informa-

tion is provided, the .env DNS server would acknowl-

edge the request, assigning a fully qualiﬁed domain

name to the device, registering it in a SRV record.

Hence, each sensor device will be assigned a

unique hostname that has the following format:

devicename. htt p. tcp.service.location.env (2)

where devicename is the user-friendly name of the

sensor device (<Instance> portion of the SRV

record), service is the actual Web service offered by

it and location is the absolute location of the device.

Service and location deﬁne the <Domain> portion,

which becomes service.location.env. The <Service>

section is either http. tcp or http. udp.

A sensor device may offer various environmental

services. Thus, multiple hostnames will be created

for this device, each for a different offered service.

Since the WoT proposes a resource-oriented archi-

tecture (Richardson and Ruby, 2007), services must

To avoid confusion, we note that by the notion of a ”ser-

vice”, the DNS refers to the Internet protocols used to inter-

act with some domain. In the WoT, services are meant as

the Web-based functionalities offered by Web-enabled sen-

sor devices.

USINGDNSFORGLOBALDISCOVERYOFENVIRONMENTALSERVICES

281

Figure 1: Environmental Service Discovery Procedure using DNS.

be described with uniform resource identiﬁers (URIs)

(see Section 3). This avoids ambiguities when users

construct environmental URLs in their Web browsers.

2.2 Service Discovery

Service discovery begins when a user types in his Web

browser a URL ending with the .env label. Since the

user may not be able to construct the equation shown

in (2), he could ask about all sensor devices offer-

ing service and deployed in location. This would be

achieved by using the PTR DNS record type (Mock-

apetris, 1987), as shown in Table 1, by specifying a

query of the form <Service>.<Domain>. In this

case, DNS would respond to the PTR lookup with a

list of relevant <Instance> records.

In case there exist numerous relevant records, a

technique such as round-robin DNS could be em-

ployed. Round-robin DNS is a technique for achiev-

ing load distribution and load balancing by respond-

ing to requests from various client computers accord-

ing to an appropriate statistical model.

After the user receives the list of relevant in-

stances, he can use any of them to construct a query

similar to the equation shown in (2). By typing this

URL in his Web browser, the DNS will translate it

to the actual IPv4/IPv6 address of the corresponding

sensor device. This translation is realized by using

the A and AAAA DNS record types, as shown in Ta-

ble 1. The user can also use the TXT DNS record type

to receive general characteristics/capabilities of some

sensor device, in case they are available.

When the IP address is resolved and the request is

forwarded to the appropriate sensor device, the device

needs to respond with a description of its functional-

ity. This is necessary in order to understand the se-

mantics of the device (e.g. indoor/outdoor, degree of

accuracy, measurement unit) and how to interact with

it to get informed about the environmental conditions.

Thus, a description language must be deﬁned, which

declares the device semantics, but also explains the

interaction possibilities with it.

Example description languages that could be

adopted are Extended Environments Markup Lan-

guage (EEML)

and SensorML

. These are languages

that describe the capabilities of sensor devices, but do

not describe effectively the interaction with them.

Therefore, we propose to employ Web Appli-

cation Description Language (WADL)

, which is

an XML-based language that provides a machine-

readable description of HTTP-based applications. It

can be considered as the RESTful equivalent of Web

Services Description Language (WSDL)

, which is

a standard for describing SOAP-based Web services.

WADL is intended for applications based on the

Web architecture, and it is meant as a platform- and

language-independent way of describing services.

After the user receives the WADL description, he

can construct the appropriate request, query the sen-

sor device and get informed about the environmental

conditions in the selected location, in a well-known

format such as XML or JSON. The whole discovery

procedure can be observed in Figure 1.

Environmental service discovery may involve not

only humans but also machines, for automated M2M

communication. In this case, machines could discover

useful services on demand, and take decisions auto-

matically based on current environmental conditions.

2.3 Freshness of Information

The idea of online directories for Web services (e.g.

UDDI

for WS-*) never worked, mainly because

of information inconsistency and unavailability.

Through DNS, these inconsistencies can be avoided.

http://www.eeml.org/

http://www.opengeospatial.org/standards/sensorml

https://wadl.dev.java.net/

http://www.w3.org/TR/wsdl

http://uddi.org/pubs/uddi v3.htm

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

282

Table 1: DNS Record Translation.

No DNS Record Explanation Example Record/URL

1 SRV Records the service instance of a device offering service at location mydevice. http. tcp.pollution.porto.env

2 PTR Lists which devices support service at location http. tcp.pollution.porto.env

3 A Translates an environmental URL to a 32-bit IPv4 address mydevice.pollution.porto.env

4 AAAA Translates an environmental URL to a 128-bit IPv6 address mydevice.pollution.porto.env

5 TXT Meta-data about the selected sensor device mydevice. http. tcp.pollution.porto.env

In general, the DDNS service allows the DDNS

server to allocate a static hostname to a physical de-

vice, and whenever the device is allocated a new IP

address, this is communicated to the DDNS provider

by software running on the device.

Furthermore, Dynamic DNS Update Leases

(Cheshire et al., 2006) constitutes a method of extend-

ing DDNS to contain an update lease life, allowing a

DNS server to perform DNS dynamic updates with

an attached lease time, that are automatically deleted

unless renewed before the lease expires.

Hence, the name server ”forgets” after some time

interval the registration of the sensor devices. Devices

may be forced to state frequently their operability to

the DNS server, by re-registering, e.g. every some

hours. In this way, dynamic IP address assignment to

devices could be supported and also device unavail-

ability could be identiﬁed in a relatively small delay.

3 PRACTICAL ISSUES

Our approach creates numerous practical issues that

must be effectively addressed. The general operation

of the DNS is expected to be affected, mainly in terms

of management, security and increased trafﬁc.

Concerning management issues, since the DNS

follows a hierarchical structure, the addition of the

.env top-level domain is not expected to be a compli-

cated task. Availability of devices and services may

be assured by DDNS update leases.

Partial reliability could be ensured by checking

the IP addresses of the sensor devices, if they fall in

the locations claimed by them during the registration

process. More reliability and trust would be achieved

if some user-based feedback system was applied for

sensor devices and their environmental services, sim-

ilar to the way eBay works for rating its users.

User-based rating could be realized if sensor de-

vices had a social presence on the Web. Towards this

direction, Evrythng

company aims to create Web-

based social proﬁles for physical devices. It would

then be easy for users to rate them, according to

their quality of service. Such an initiative would also

provide more advanced privacy, allowing the owners

http://evrythng.net/

of the devices to share them only with their family,

friends or everyone. In general, the social Web could

be harnessed for authenticating and authorizing users

to interact with environmental services.

Our approach requires unique devicename assign-

ment to sensor devices that have same services and

location. Upon a conﬂict, the DNS server should au-

tomatically select a new name for the device, typically

by appending a digit at the end of its name. Since the

.env DNS server would constitute a distributed repos-

itory, the devicename assignment should be visible to

all .env name servers. Due to the massive amount of

Web-enabled devices in the near future, this could be

the cause of high load to DNS. However, this issue

may be mitigated by area- or location-based assign-

ment of devices to the .env DNS servers.

Another important issue concerns naming of ser-

vices and locations. For example, locations are named

differently in each language (e.g. ”Lisbon” in English

vs ”Lisboa” in Portuguese). To avoid these ambigu-

ities and guarantee uniqueness, electronic directory

services such as X.500

could be used, where a dis-

tributed database would contain unique translations

for services and locations.

Since the DNS system supports a built-in caching

mechanism, this mechanism could be exploited to

support caching of sensory data. During their regis-

tration, sensor devices would include their latest mea-

surements, stored in TXT resource records. These

measurements could then be forwarded to users who

query the .env DNS server for a relevant service,

while they are still fresh

. Nonetheless, current DNS

infrastructure can not tolerate such high loads.

Finally, the whole system would be optimized by

forcing the .env DNS server to return directly the

IP addresses of relevant sensor devices and not their

hostnames. However, this may not be practical since

the IP addresses of the devices may change frequently

while their hostnames remain the same. Furthermore,

some users might prefer to use some particular sensor

devices they found more reliable than others. By ex-

changing only IP addresses, this connection between

Web clients and sensor devices can not be maintained.

http://www.x500standard.com/

Deﬁning the freshness of measurements varies between

devices and services.

USINGDNSFORGLOBALDISCOVERYOFENVIRONMENTALSERVICES

283

4 DISCUSSION

The procedure of discovering environmental services

can be automated by selecting some sensor device

from the list returned by the .env DNS server, pars-

ing its WADL ﬁle and constructing HTTP requests.

This process can even be personalized, by select-

ing only devices that meet particular user preferences.

For example, some users may wish to interact solely

with devices having positive online feedback or those

belonging to well-known authorities such as govern-

mental organizations. User characteristics could be

extracted from their online social networking status.

Since the whole idea is participatory-based, only

people who are willing to share their sensor devices

with the online community would do so. We believe

that in the future a culture could be created around

the concept of sharing environmental services with

the rest of the world.

Even though our proposal targets environmental

services, it could be well generalized to support any

kind of physical devices and/or pervasive services.

To achieve this, standardized ”domain vocabularies”

need to be created, for facilitating the construction of

queries by end users. For example, a user that wishes

to park his car in Barcelona could just need to type in

his Web browser parking.cars.Barcelona.

Finally, deﬁning extended environmental ontolo-

gies would encourage automatic information re-

trieval, generalized inferences and advanced Web

mashup development very easily. For example, when

the temperature in Porto is obtained, then the general

temperature of Portugal can be automatically inferred.

5 CONCLUSIONS

Embedded computing is becoming ubiquitous in our

everyday lives, being slowly-slowly blended with the

Web. Discovering in real-time miniaturized Web-

enabled sensor devices, deployed around the world,

is a problem that needs to be effectively solved.

In this paper, we investigated theoretically how the

DNS could be extended to support global discovery of

environmental services. Our small research indicates

that it may be feasible to achieve automatic, real-time

discovery of sensor devices, by means of specialized

domain name servers. Deﬁnitely, our proposal con-

stitutes only a novel idea and it would require a great

willingness from Web engineers to be realized.

It would be interesting to study ways for extending

DNS-based discovery of any Web resource offering a

RESTful Web API. Security is another crucial factor

not discussed that requires extensive research.

For future work, we plan to experiment with

BIND

, which is an open-source DNS software for

Linux, implementing a .env DNS server in a local

environment, demonstrating the potential of this ap-

proach. In parallel, we will develop a Mozilla Firefox

extension that automatically discovers sensor devices

just by typing relevant URLs, constructs their host-

names and interacts with them.

REFERENCES

Cheshire, S. and Krochmal, M. (2011a). DNS-Based Ser-

vice Discovery. IETF Draft, draft-cheshire-dnsext-

dns-sd.txt.

Cheshire, S. and Krochmal, M. (2011b). Multicast DNS.

IETF Draft, draft-cheshire-dnsext-multicastdns.txt.

Cheshire, S., Krochmal, M., and Sekar, K. (2006). Dynamic

DNS Update Leases. IETF Draft, draft-sekar-dns-ul-

01.txt.

Dunkels, A., Voigt, T., and Alonso, J. (2004). Making

TCP/IP Viable for Wireless Sensor Networks. In Proc.

EWSN 2004, Berlin, Germany.

Fielding, R. T. (2000). Architectural Styles and the Design

of Network-based Software Architectures. PhD thesis,

University of California, Irvine, California.

Gershenfeld, N., Krikorian, R., and Cohen, D. (2004). The

Internet of Things. Scientiﬁc American, 291(4):76–81.

Guinard, D., Trifa, V., and Wilde, E. (2010). Architecting a

Mashable Open World Wide Web of Things. Techni-

cal Report No. 663, ETH Zurich.

Gulbrandsen, A., Vixie, P., and Esibov, L. (2000). A DNS

RR for specifying the location of services. RFC 2782.

Kamilaris, A., Trifa, V., and Pitsillides, A. (2011). The

Smart Home meets the Web of Things. IJAHUC Jour-

nal, 7(3):145–154.

Mockapetris, P. (1987). Domain Names - Implementation

and Speciﬁcations. STD 13, RFC 1035.

Ostermaier, B., Roemer, K., Mattern, F., Fahrmair, M., and

Kellerer, W. (2010). A Real-Time Search Engine for

the Web of Things. In Proc. of the Internet of Things

2010 Conference, Tokyo, Japan.

Rekhter, Y., Thomson, S., Bound, J., and Vixie, P. (1997).

Dynamic Updates in the Domain Name System (DNS

UPDATE). RFC 2136.

Richardson, L. and Ruby, S. (2007). RESTful Web Services.

O’Reilly.

Wang, H., Tan, C., and Li, Q. (2008). Snoogle: A Search

Engine for the Physical World. In IEEE INFOCOM

2008, pages 1382 –1390, Phoenix, AZ, USA.

Wilde, E. (2007). Putting things to REST. Technical Report

UCB iSchool Report 2007-015, UC Berkeley.

Yazar, D. and Dunkels, A. (2009). Efﬁcient Application In-

tegration in IP-based Sensor Networks. In First ACM

Workshop On Embedded Sensing Systems For Energy-

Efﬁciency In Buildings (BuildSys), California, USA.

http://www.isc.org/software/bind

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

284