DNS and the Internet of Things: Outlining the challenges faced by DNS in the Internet of Things

(1)

DNS and the Internet of Things

Outlining the challenges faced by DNS in the Internet of Things

Almira Hamzic Isabel Olofsson

K T H R O Y AL I N S T I T U T E O F T E C H N O L O G Y

I N F O R M A T I O N A N D C O M M U N I C A T I O N T E C H N O L O G Y

(2)

Abstract

This thesis work consists of a literature study where different aspects of DNS and the Internet of Things have been researched. A functional naming and service identification method is an essential part in making the IoT global, and DNS is the current method of naming devices on the Internet. The study looks into some challenges DNS will encounter, namely functionality, security and availability.

This report concludes that a multicast DNS (mDNS) based solution designed for constrained networks is advantageous. This is despite the limited security that is currently available for such a solution. In the future, it is important that security has top priority, as there are currently limited means of security in DNS. Further study is needed when it comes to availability and how name resolving would work with constrained devices that utilise sleep mode.

Keywords

Internet of Things, IoT, DNS, security

(3)

Abstrakt

Detta examensarbete består av en litteraturstudie där olika aspekter av DNS (Domännamnssystemet, eng. Domain Name System) och Sakernas Internet (eng. Internet of Things) har studerats. En fungerande namngivnings-och serviceidentifieringsmetod är en viktig del för att kunna göra Sakernas Internet globalt, och DNS är den nuvarande metoden för att namnge enheter på Internet. Studien undersöker vissa utmaningar som DNS kan stöta på, nämligen funktionalitet, tillgänglighet och säkerhet.

Rapportens slutsats är att en lösning baserad på multisändnings-DNS (eng.

multicast DNS, mDNS) som är anpassad för begränsade nätverk (eng.

constrained networks) är fördelaktig. Detta trots den begränsade säkerhet som finns tillgänglig just nu för en sådan lösning. I framtiden är det viktigt att säkerheten har högsta prioritet, eftersom säkerheten är begränsad hos DNS.

Det behövs ytterligare studier när det gäller tillgänglighet och hur adressöversättning skulle fungera med begänsade enheter (eng. constrained devices) som använder viloläge.

Nyckelord

Sakernas Internet, IoT, DNS, säkerhet

(4)

1

Acronyms and abbreviations

Acronym/abbreviation Description

6LoWPAN IPv6 over Low power WPAN

ARPANET Advanced Research Projects Agency Network

DDoS Distributed Denial-of-Service

DNS Domain Name System

DNS-SD DNS-Based Service Discovery

DNSSEC DNS Security Extension

IANA Internet Assigned Number Authority

ICMP Internet Control Message Protocol

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IoT Internet of Things

IP Internet Protocol

ISP Internet Service Provider

ITU International Telecommunication Union

ITU-T ITU Telecommunications Standardization Sector

mDNS Multicast DNS

NFC Near Field Communication

RFC Request For Comment

RFID Radio-frequency identification

TCP Transmission Control Protocol

TLD Top Level Domain

TTL Time To Live

UDP User Datagram Protocol

WPAN Wireless Personal Area Network

(6)

1

1 Introduction

The Swedish Armed Forces (Swe. Försvarsmakten) have an interest in reliable and secure communication. This thesis has been carried out in collaboration with the Swedish Armed Forces to detail some of the many challenges that come with the rise of the Internet of Things (IoT). Below is a short introduction of the project. The introduction contains project background, purpose, goal, problem, scope, method, delimitation, ethics, sustainability and an outline of the thesis

1.1 Background

Depending on whom you ask, you will get a different prediction regarding how many connected things there will be in the near future. These predictions range from about 25 [1] billion to 50 [2] billion connected things by 2020, compared to an estimated 6.4 billion in mid-2015 [3]. The estimates vary greatly in part because it is something that is difficult to measure, but also because the different estimators use different definitions on what constitutes as a “thing” or “connected device” [4].

It is, however, clear that the number of connected devices or things are rapidly increasing and with that, several problems will arise. Some of the problems include scaling, security along with availability, and these problems need to be addressed before the Internet of Things (IoT) expands further [5].

Many of the devices in the IoT will be directly or indirectly connected to the Internet [6] so a naming and service identification method is an essential part in making the IoT global [7]. DNS is a significant part of the current infrastructure of the Internet. It is primarily used to resolve a hostname (e.g.

www.example.com) into an IP address. If the amount of devices does, as stated above, triple in five years, the amount of DNS requests will also multiply [8]. This will affect functionality, security and availability in the Internet of Things.

1.2 Purpose and goal

The purpose of this paper is to study the Domain Name System (DNS) in relation to the Internet of Things, focusing on how functionality, security and availability will be affected by the increasing number of things. The goal of this project is to provide information on the current state of the Internet of Things in this limited field. This project is a limited survey that offers suggestions on how to approach and solve the problems that arise from the increasing amount of IoT devices.

1.3 Problem and scope

DNS is an old protocol in terms of the Internet, since it was first designed over thirty years ago [9]. In comparison to the DNS protocol, the Internet of Things is a relatively new concept, as the name was first coined in 1999 [10]. Since

(7)

2 DNS is a relative old protocol it could prove difficult to adapt it for use in the IoT.

The project asks the following questions:

 What are the vulnerabilities of DNS?

 What can be changed in the DNS structure to better suit the Internet of Things?

 What can be done to ensure functionality, security and availability in DNS in the Internet of Things?

 Future work: How can the industry make sure that the Internet of Things stays secure despite the huge increase of devices?

1.4 Method

The project consists of literature studies, as the proposed problem is partially caused by scaling. The project is a limited survey and will investigate the current situation of the IoT and DNS, to find out how to advance in the development of the Internet of Things.

In this project, a qualitative method will be used, since this project will answer the question of “how” and not “how much”. The project will take an inductive approach to research, aiming to draw conclusions based on the researched material. This method was chosen since there is no hypothesis for this project, therefore the goal is to analyse the findings and suggest strategies based on the studies.

While testing this problem would be possible, this is out of the scope of this project due to insufficient resources. These tests would be too advanced and resource-demanding for a project of this size.

1.5 Delimitation

This project will not be able to cover an in depth and detailed solution of this big problem. The reason for this is that the problem deals with scaling, and it would not be possible to simulate the problem due to insufficient resources.

Given the lack of simulation and testing, this project can only offer suggestions and input on how to further develop the IoT and DNS.

1.6 Ethics and sustainability

Since the project itself only consists of a literature study, there will be no ethical issues within the project. However, the ethical issues of the Internet of Things will become a concern when more personal information is stored in the devices. In the field of medicine, remote patient monitoring could become a reality [11]. Therefore, securing every aspect in the Internet of Things is crucial to the integrity of the users.

The devices in the Internet of Things are usually smaller with less capacity and computing power, and also more energy efficient than the traditional devices.

In addition to the devices themselves being sustainable in the future, they will

(8)

3 also be able to monitor and control the home environment of a user. This means that the user can turn off the lights or the heating while they are not home, and turn it back on when they are on their way home, which in turn saves energy.

Energy saving technology can also be used outside the homes and in the city.

The concept of Smart Sustainable Cities incorporates in the traditional infrastructure and can be used to improve energy efficiency, efficiency of water distribution systems and wastewater management [12]. That means that the Internet of Things will contribute to a more sustainable future.

1.7 Outline

This thesis starts off by describing the background of Internet of Things (IoT) and DNS in chapter 2. Chapter 3 describes the challenges this report has looked into and Chapter 4 describes the analysis and provides suggestions on how to solve the challenges. Lastly, Chapter 5 details the conclusions and future work.

(9)

4

2 Internet of Things and DNS background

Below is a background of the Internet of Things and DNS. This chapter outlines some key concepts in the Internet of Things in section 2.1, section 2.2 defines the difference between things and devices, section 2.3 is about the relationship between physical things and devices and section 2.4 describes the architecture of the IoT.

Section 2.5 covers the current situation in IoT naming, section 2.6 briefly explains how DNS works and the chapter continues to outline some of the vulnerabilities found in DNS in section 2.7. DNS Security Extensions (DNSSEC) is described in section 2.8, section 2.9 contains information about Multicast DNS (mDNS) and lastly, section 2.10 describes DNS-based Service Discovery (DNS-SD).

2.1 Internet of Things

Much like the case of estimating the number of devices, asking someone to define the Internet of Things will give you a different answer depending on whom you ask. There are so many different definitions made in various research reports, papers, books and articles etc. that the IoT tracking website postscapes.com has a page containing over 40 different definitions [13].

This report will be using the term Internet of Things as it is defined by the ITU Telecommunication Standardization Sector (ITU-T). ITU-T [14] is a division of The International Telecommunication Union (ITU) which is a United Nations (UN) specialized agency for information and communication technology (ICT). ITU-T works with developing and suggesting standards in the field of ICT and release their work as “ITU-T Recommendations”.

In one of these Recommendations, “Recommendation ITU-T Y.2060:

Overview of the Internet of Things” [15], which was released in 2012, they define the Internet of Things as follows:

“Internet of things (IoT): A global infrastructure for the information society, enabling advanced services by interconnecting (physical and virtual) things based on existing and evolving interoperable information and communication technologies.

NOTE 1 – Through the exploitation of identification, data capture, processing and communication capabilities, the IoT makes full use of things to offer services to all kinds of applications, whilst ensuring that security and privacy requirements are fulfilled.

NOTE 2 – From a broader perspective, the IoT can be perceived as a vision with technological and societal implications.”

(10)

5 As seen above, ITU-T themselves offer two definitions. These definitions are not different per se, but rather dependant on ‘which level’ you look at the Internet of Things. This means that the ‘vision’ definition in note 2 is based on the first, more technical, definition.

2.2 Defining things and devices

In the aforementioned Recommendation released by ITU-T [15], the “things”

in the Internet of Things are defined as:

“With regard to the Internet of things, this is an object of the physical world (physical things) or the information world (virtual things), which is capable of being identified and integrated into communication networks. “

The key words here are identified and integrated. The things do not necessarily have to be able to communicate themselves, but must have some means to be recognized in the IoT. An example of these types of things are things that can be scanned, such as a barcode attached to a package or a key tag.

Physical things could be pretty much anything that either is a device itself or uses a device to be integrated into the Internet of Things. Virtual things are strictly digital objects (software, multimedia etc.) that can be stored, accessed and handled in the information world.

The same Recommendation also defines what is considered a device in the IoT:

“With regard to the Internet of things, this is a piece of equipment with the mandatory capabilities of communication and the optional capabilities of sensing, actuation, data capture, data storage and data processing.”

The key word here is communication. Whether this communication is direct or indirect, between devices or human to device, vary depending on the situation in question.

2.3 The relationships between physical things and devices

Devices and physical things can have several different types of relationships with each other. The ITU-T Recommendation divides the devices that appear in the context of the IoT into four different categories. These four categories consist of general devices, sensing and actuating devices, data carrying devices and data capturing devices.

(11)

6

Figure 1. Relationships between physical things and devices. Figure based on ITU-Ts definition [15]

The most straightforward of these is when a physical thing is also considered a device. ITU-T uses the term “general device” to describe this type of relationship. A general device is a physical thing (say a home appliance) that has an embedded processor and communication capabilities that integrate the

“thing” into the Internet of Things. Smartphones are considered general devices, as are personal computers.

Sensing and actuating devices observe the things around them. They may collect data and transmit it elsewhere or take action based on the sensed information. Examples include any type of sensor that can communicate as well as surveillance cameras.

Data-capturing devices are devices that use read/write operations to interact with physical things. They interact with either data carriers or data carrying devices that are attached to physical things. Data carriers are static (such as a barcode attached to a packet) while data carrying devices can have their stored information altered by a data-capturing device. Examples of data carrying devices include Radio-frequency identification (RFID) and Near Field Communication (NFC).

2.4 Architecture of the IoT

As described in previous sections there are different kinds of devices and things that make up the Internet of Things. Some of these devices can make use of the existing protocols, but due to hardware limitations some cannot.

These devices are commonly known as constrained devices and have limited processing power, memory and power resources. Depending on how much computing power a constrained device has, the Internet Engineering Task Force (IETF) classifies them from Class 0 (lowest) to Class 2 (highest). [16]

(12)

7 When these constrained devices become part of a network they are known as constrained nodes. A network that incorporates these constrained nodes is known as a constrained-node network. Due to the constrained nodes, there are limitations on a constrained-node network. These limitations are not seen on a network made up of hosts with more computing power. [16]

While some of the IoT devices may be capable of utilising traditional internet protocols, others are completely incapable because of their limited resources.

Therefore, these constrained nodes implement an IoT protocol stack that is more suitable to their limitations. In order to communicate with hosts on a network that implements a full TCP/IP stack, constrained devices on a constrained network need to utilise a gateway node [16]. Smartphones can be used as IoT gateways for smart devices (e.g. a smart watch) [17]. There are also dedicated devices that act like a gateway between the constrained network and the Internet [16]. These gateways bridge the gap between the TCP/IP stack and the IoT stack.

Figure 2. TCP/IP stack compared to IoT stack

At the bottom of the IoT protocol stack we have IEEE standard 802.15.4. It provides a low-speed, low-cost Wireless Personal Area Network (WPAN) with a range of a few meters. IEEE 802.15.4 can be used by devices to communicate with other nearby devices without the need for other infrastructure. [18]

The IPv6 over low power WPAN (6LoWPAN) protocol enables IPv6 packages to be sent and received over low powered networks based on IEEE 802.15.4.

This is possible by enabling encapsulation and header compression for IPv6.

6LoWPAN also supports mesh routing, i.e. each node in the network is capable of forwarding data to another node. This makes it easy to add nodes anywhere in the network since they will be able to communicate using other nodes as relays. [19]

The transport layer of the IoT protocol stack implements the User Datagram Protocol (UDP) which has proven suitable for constrained nodes since it is a lightweight protocol [18]. Even though TCP is more reliable than UDP, UDP is

(13)

8 the preferred protocol for constrained devices because of its speed. The fast communication is achieved due to UDP having no error correction, and having a lightweight configuration [20]. Certain IoT protocols, such as the Constrained Application Protocol (CoAP), implement some of the missing TCP features in the application layer [21].

In the application layer of the IoT protocol stack we have a number of application layer protocols that have been designed to be usable by constrained devices, such as CoAP [22], MQTT (formerly Messaging Queuing Telemetry Transport) [23] and Extensible Messaging and Presence Protocol (XMPP) [24]. These protocols work in different manners, but all of them can be used by small and lightweight devices.

2.5 IoT naming

In their survey covering the identification and accessing of IoT objects and services, M. Gajewski and P. Krawiec describe the current IoT situation as an

“Intranet of Things” rather than an Internet of Things [7]. The reason for this is that there are currently several naming technologies that are suited for different scenarios and those naming technologies are incompatible with each other.

One of the presented naming technologies is utilising the existing IPv6 and DNS technologies and adapting them for the IoT environment. This solution is heavily promoted by IETF standardisation body. It is made possible by the previously mentioned protocols 6LoWPAN and CoAP. 6LowPAN supports encapsulation and IP-header compression and CoAP supports web communication for constrained nodes and translation to HTTP for integration with the current Internet. [7]

In addition to the IPv6 based technology mentioned above, there are a few more specialised technology mentions that serves some niche functions in the IoT, such as the Electronic Product Code (EPC) which is used for identification of electronic tags such as RFID. [7]

2.6 The Domain Name System (DNS)

The Domain Name System (DNS) is a UDP-based application protocol that is a necessity for most people who are using the Internet. DNS has been around since 1983, in the ARPANET, although it worked differently back then [9]. In this section, today's DNS will be described, and most of the information comes from J. F. Kurose’ and K. W. Ross’ Computer Networking: A Top-Down Approach [25].

DNS resolves a hostname (e.g. a website address) and translates it to the corresponding IP-address where the website is hosted/located. A general example, that most people have encountered and can relate to, is when a user types a hostname, e.g. www.kth.se, into a web browser. The web browser sends a request called a DNS query. There are several different ways of

(14)

9 sending a query; it does not have to be a user that types a web address into a web browser.

It is worth noting that a user does not have to be directly involved in order to make a DNS query. While a software application that needs to connect to a server has no need for a user friendly hostname, there are a number of other reasons why looking up a hostname is better than using an IP address. A host could be having multiple IP addresses or using dynamic IP [26]. An example is a weather app on a smartphone; the app does a DNS lookup to the weather site in order to retrieve information about the weather. User interaction is not needed in order to do a DNS lookup.

The following example will look at a DNS query that is sent when a web address is typed into a web browser. The request is first sent to the local DNS server. This server is often located near the user; either on the same network or a few router-hops away. If it is the first time that the local DNS server has been asked to resolve this address, it will not be able to do so on its own.

Instead, the local DNS servers forward the request to a root domain server.

Figure 3 shows the whole progress of the request.

Figure 3. Explaining the flow of the query

The root domain servers are able to resolve the top-level domain (TLD) server addresses. There are 13 root domain servers in the world. These servers do, however, have replicas for security and reliability reasons. The root domain servers are labelled “A” through “M” and the address to the “A” root server is

(15)

10

“a.root-servers.net”. The naming convention is applicable for all root domain servers. DNS root server “A” receives around five billion queries per day [27].

When the local DNS server sends the request to the root domain servers, the root server responds with the top-level domain server address. Examples of TLDs are domains such as “.com”,”.edu”, “.org” and “.se”. In this case, the root server will resolve the “.se”-part and will send the response to the local DNS server. This server will now be able to send the request to the “.se”-TLD server. The TLD server will resolve the “kth.se”-part of the address and this information is then sent back to the local DNS server.

The local DNS server is now able to send the request to the authoritative server of kth.se. Every organisation that has a hostname that is accessible by the public has an authoritative DNS server that resolves the organisation’s addresses. This is the last step that needs to be completed in order to resolve the entire requested host name www.kth.se. The authoritative DNS server of www.kth.se responds to the DNS query with the IP-address of the website.

When the response reaches the local DNS server, this server forwards the response to the user and the user is able to retrieve the website. This system works in a hierarchical manner, see Figure 4.

When the whole query has been resolved and the local DNS server has received the IP-address, the IP-address can be cached in the local memory of the local DNS server. The resolution is saved with a Time to Live (TTL) [28].

TTL is measured in seconds and is needed to keep the information updated, in case there are changes in the network, e.g. a hostname changes its IP-address.

When the TTL expires, a new DNS query needs to be made.

Figure 4. The hierarchical structure of DNS

(16)

11 As can be seen in Figure 4, DNS has a hierarchical structure. The hierarchical structure and a large amount of servers allows DNS to handle the scaling issue. If only one server would have to resolve all the requests, the server would be over flooded and would not be able to handle all requests. The solution is to divide the traffic in a hierarchical manner, as has been explained previously.

2.7 DNS vulnerabilities

Even though DNS is widely used across the Internet, the system was not originally designed with security in mind. The reason for this was because the Internet was not accessible to the public at the time of the launch of DNS.

After the Internet became accessible to the public, vulnerabilities were discovered and exploited. Some examples of vulnerabilities in DNS include distributed denial-of-service (DDoS) attacks, both towards the DNS servers and other specific targets, and man-in-the-middle attacks. DDoS attacks have been increasing in volume and frequency in 2015 compared to 2014 [29], so it is important to keep in mind that these attacks do exist and to be prepared for them. Even though the duration of these attacks are shorter than they used to be (the targeted host can recover in less than an hour), they still do impact the business of the targeted companies.

One DDoS attack type is the attack that targets the root servers. The attacks are executed by over flooding the root servers with messages, usually ICMP (Internet Control Message Protocol) ping messages. These attacks are usually not very effective, however. These servers have firewalls that block certain types of messages. The local DNS servers might also have cached the addresses to TLD servers or frequently used web sites, which makes the attack unnoticeable by the user.

It would be more effective to attack the top-level domain servers because they are not as easily bypassed as the root domain servers are. Since the local DNS servers cache the TLD servers, it is important that the local DNS servers are online and working as intended. [25]

Another type of DDoS attack, one that is more likely to be visible to the average Internet user, is an attack against a specific host, such as a gaming company or the mail servers of a university. Even though these attacks are directed at a specific target, they may impact other, more essential hosts, such as an Internet Service Provider’s (ISP) DNS server. This happened in Sweden in December 2014 [30]. The targeted host was a gaming company, but the ISP’s DNS servers were used in the attack. This resulted in a large amount of customers losing not only their Internet access, but also access to their IPTV and IP-telephony.

Another similar instance happened during the spring of 2013, where a Swedish DNS server was used in an attack against American banks. According to Swedish newspaper Dagens Nyheter, there are still similar security

(17)

12 vulnerabilities in thousands of DNS servers belonging to Swedish authorities and municipalities [31].

DNS is also vulnerable to man-in-the-middle attacks. This kind of attack is also known as DNS spoofing or DNS cache poisoning. When a user sends a DNS query, the user expects the information they get from the DNS servers to be correct. This is not always the case. During a man-in-the-middle attack, an attacker might pretend to be a DNS server, and send the wrong IP address back [32]. This will cause the user to visit the wrong website. This fake website may look just like the original one that the user was trying to reach. As such, if the user believes the fake website to be the real one, the user might enter their username and password in a fake website giving the attacker this information.

This problem can be solved with DNS Security Extensions (DNSSEC).

2.8 DNS Security Extensions (DNSSEC)

The Domain Name System Security Extensions (DNSSEC) is a set of extensions that add security to DNS since DNS was not created with security in mind. DNSSEC provides origin authentication and integrity, but not confidentiality and availability [33]. It provides this by signing the queries, and by checking the signatures, ensuring that the response is received from the correct host. It is worth noting that the queries are not encrypted, only authenticated.

Figure 5. Explanation of a chain of trust. If X trusts Y and Y trusts Z, then X trusts Z as well.

A chain of trust is created when a parent domain verifies its subdomain. All root servers were secured and signed in 2010 [34] and these are managed by the Internet Assigned Number Authority (IANA) [35]. All DNS servers have managers, and these managers are responsible for authenticating and securing the DNS servers. Most TLDs are authenticated [36], which means that the TLDs can verify their respective subdomains. When the subdomains are authenticated, the root zones can also trust them, thus creating a chain of trust from the subdomains through the TLDs to the root zones.

When a user types a web address in the web browser and the request is sent to the local DNS server, the DNS client specifies that it is DNSSEC aware by setting the DO (DNSSEC OK) bit to 1. The request then reaches the local DNS server and the query is forwarded to the root name and TLD servers, the DO

(18)

13 bit is still set to 1, indicating that DNSSEC is being used. When the local DNS server receives the resolution to the authoritative server and forwards the query to that server, the authoritative servers know that the local server has the DO bit set to 1. This means that the local server is able to sign the query.

The authoritative servers can now include signatures in the DNS response.

These signatures are used for validation when the local DNS server sends the response to the DNS client. [37]

2.9 Multicast DNS (mDNS)

Multicast DNS (mDNS) was designed with the goal of being able to utilise the established DNS protocol in a local network environment [38]. Multicast DNS is a zero-configuration service, meaning that it requires no set-up because it configures itself automatically. Unlike DNS, which sends unicast messages to one receiver at a time, mDNS uses multicast to reach all hosts that are open to receive multicast messages on a local network. [39]

Multicast DNS is mainly used within a local network to resolve hostnames that end with the TLD-name “.local.” [39]. It could be used in conjunction with a unicast DNS-server. However, such a setup would no longer be considered a zero-configuration solution, as the server would need configuration. Multicast DNS also lacks the hierarchical structure of conventional DNS because creating a hierarchy would require configuration.

Figure 6. Unicast compared to multicast. Courtesy of Wikimedia Commons. [40]

[41]

In order to resolve a “.local.” hostname (e.g. “MyComputer.local.”), a host within the local network sends a query to the DNS multicast address 224.0.0.251 (IPv4) or to ff0x::fb (IPv6) asking for the queried host respond with its identity. The host, i.e. “mycomputer.local.”, responds with another multicast message that includes its IP address. This makes the address known not only to the original querier, but to the rest of the hosts on the local network as well. All the hosts on the local network can then update their caches with this new information. [39]

Multicast DNS can easily be compromised since its security relies on having a secure network. If someone with malicious intent manages to access a local network, they can easily pretend to be someone else. By simply changing their hostname to “mycomputer.local.” and responding to a multicast query before the real “mycomputer.local.” it is possible to impersonate the original host.

[42]

(19)

14 2.10 DNS-based Service Discovery (DNS-SD)

DNS-based Service Discovery (DNS-SD) gives hosts the ability to query for a specific service (e.g. a printer) on a given network (local or global). Available services have a Service Instance Name which has the format

"<Instance>.<Service>.<Domain>". The <instance> portion of the name is user configurable name of a device e.g. “OfficePrinter” or “3rdFloorPrinter”.

The <service> portion of the name specifies which service and which protocol should be used e.g. “._printer._tcp”. Lastly, the domain name “<domain>” is specified, e.g. “local.”. [43] [44]

By making a query for “<Service>.<Domain>" the querier will receive a list of all the instances that provide the requested service. So if a host would like to discover a printer on the local network it would query for

“_printer._tcp.local.” and get a list of printing services back containing the instances “OfficePrinter” and “3rdFloorPrinter”. [43] [44]

(20)

15

3 Challenges for DNS in the IoT

There are several challenges when it comes to DNS in the IoT. This chapter will outline challenges in the three areas that this thesis focuses on. Section 3.1 outlines the challenges in the functionality, section 3.3 is about the security and the last section, section 3.2, covers the availability challenges.

3.1 Functionality

In order for the IoT to grow and to become a global infrastructure, any device that will be a part of the IoT need to have a unique identifier [45]. As mentioned in section 2.4, Architecture of the IoT, devices in the IoT have limited capabilities. The limitations imposed by working with these constrained devices is the key challenge that needs to be considered. These limitations have various forms such as processing power, memory and power resources.

As a side effect, the constrained devices are smaller than traditional devices.

The advantage of having smaller devices is that they are portable. However, it would be inconvenient to configure or set up the devices every time they are moved. This issue can be solved with zero configuration.

3.2 Security

When DNS was first designed over thirty years ago, the security aspect was not considered. Security was later added as an extension, DNSSEC, providing origin authentication and integrity, which was written in section 2.8.

However, as mentioned in section 2.7, DNSSEC does not protect against DDoS attacks, which has become increasingly common, so these types of attacks are still very much a security issue when it comes to DNS.

3.3 Availability

In section 2.6 it is mentioned that in order to make a successful DNS query, the system needs to be able to send the queries to the different servers. The servers can only respond if they are online, so it is critical that these servers are up and running for DNS to be working as intended.

It is worth noting that mDNS and DNS-SD can be used in local networks, and these protocols do not require dedicated DNS servers, in order to work in the local network.

Additionally, constrained devices have limited power resources, often running on a battery of some sort. These devices need to conserve power, so they utilise sleep mode. A device in sleep mode cannot respond to being queried directly, which is an availability issue. [46]

(21)

16 As mDNS and DNS-SD are based on DNS, they both support DNSSEC and it is recommended in the mDNS RFC [39] to use these extensions. There is no other built in security in these protocols. Instead, an mDNS enabled networks rely on the security of the network and the assumption that everyone on said networks has no malicious intentions. [39]

(22)

17

4 Discussion

This chapter discusses what can be done in the IoT and DNS. Section 4.1 analyses an IoT scenario and the challenges presented in the previous chapter.

Section 4.2 offers suggestions on how to improve the IoT and DNS.

4.1 Analysis

Imagine a scenario where a user is at work and wants to go grocery shopping after work. If the user is unsure of what they have in their refrigerator, they could connect to the refrigerator from work and check the contents. Instead of having to remember a complicated IP address, it is sufficient to remember a host name. In this case, in order to connect to the refrigerator, the DNS servers need to function properly and be up and running, as mentioned in section 3.3.

Figure 7. Home scenario

However, when the user is connected to the local network it is unnecessary to access an IoT device globally. It is sufficient to access it locally. In a scenario where a user is already at home, and wants to change the temperature in the house, they would not need to connect to a DNS server in order to reach the thermostat.

Instead of using conventional DNS, the user can use mDNS and DNS-SD to discover devices and services within the local network. This has been proposed by several papers that have presented lightweight implementations of mDNS and DNS-SD designed to be used in constrained networks [46] [47]

[48] [49]. Keeping the DNS queries confined to the local network reduces the amount of DNS queries sent to the DNS servers.

mDNS and DNS-SD also support zero-configuration networking, which has been mentioned in section 2.9. This means that adding new devices to the local network or relocating devices to another network is made easier since it would require no set up aside from connecting to the new network.

(23)

18 Even though there are security concerns present in the DNS, mDNS and DNS- SD protocols, adapting mDNS and DNS-SD for the IoT has its advantages over designing an entire new protocol. The mDNS and DNS-SD protocols were based on the DNS protocol to make them easy to work with for those already familiar with DNS and therefore easy to adopt. Hence, basing a DNS protocol for constrained devices on the already existing mDNS and DNS-SD protocols would be desirable. Doing so will hopefully increase the chances of the protocol being widely adopted and possibly accepted as a new standard.

It is important to consider the security aspects of these protocols. Currently, if a company suffers a DDoS attack, the company might lose potential revenue or, in the case of an attack targeting an ISP DNS server, the ISPs customers might not be able to access the Internet, as mentioned in section 2.7. In the future, however, these attacks might be more dangerous. Medical IoT devices are a possibility [11] and these devices may contain sensitive, or even life supporting information. If these devices cannot be reached due to an DNS DDoS attack, then potential vital information cannot be accessed by medical personnel.

Another aspect to look at is sleep mode. As mentioned in 3.3 there could be a problem with sleep mode since a device in sleep mode cannot respond to queries. As sleep mode is important when it comes to saving power, it is advisable to utilise this in some way due to the limited resources of constrained devices. In a paper [46] it was proposed that these requests should instead be relegated to the gateway and buffered until the device is awake.

4.2 Suggestions

There are improvements that can be made with regards to DNS in the IoT.

This thesis suggests the following, based on the previous analysis:

Base a solution on mDNS and DNS-SD. A solution based on an already existing technology is more likely to be adopted and accepted. Having one hostname resolving standard as opposed to having many competing ones will make the development of the IoT smoother and allows for other technology to be based on it.

Research sleep mode. It is advisable to utilise sleep mode in the IoT devices. Sleep mode is advantageous because it conserves resources, but devices are not able to respond to queries while in sleep mode. There needs to be more research in how to communicate with these devices.

(24)

19 Focus on the security flaws. The mentioned security extensions in DNS are not able to fully protect the devices from various attacks and the mDNS protocol relies on having a secure network in order to communicate securely.

This is not enough, as security will be critical in the future due to having more sensitive devices connected to the Internet. As the number of IoT devices are increasing, it is important to start focusing on security before the IoT becomes truly global.

(25)

20

5 Conclusion

In this thesis, a literature study of DNS and the Internet of Things has been carried out. The intention was to examine DNS and get a perspective on how the protocol would work in a new environment.

The project asks a couple of questions in section 1.3, and the answers to the questions can be found below.

What are the vulnerabilities of DNS?

There are several vulnerabilities in DNS, such as DDoS attacks and man-in-the-middle attacks. Man-in-the-middle attacks can be somewhat prevented by using DNSSEC, although it is concerning that some TLDs still do not support DNSSEC. This report does not include suggestions on how to prevent DDoS attacks due to it being a difficult issue.

Covered in sections 2.7 and 2.8.

What can be changed in the DNS structure to better suit the Internet of Things?

The DNS structure within a local network can utilise mDNS to make it easier for devices to communicate within a local network. Zero- configuration also makes it easier to move things from one network to another. Another structure change that can be made is to use DNS-SD to find specific services on a network.

Covered in sections 2.9, 2.10 and 4.1.

What can be done to ensure functionality, security and availability in DNS in the Internet of Things?

To keep the functionality, mDNS and DNS-SD is recommended and proposed in several papers. These papers also present light-weight, optimised versions of these protocols that are suitable for the IoT. Some security can be achieved by using DNSSEC, but a network cannot be entirely secure and a mDNS enabled network relies on the security of the network. Availability is achieved by having the DNS servers up and running at all times, as well as optimising sleep mode in devices.

Covered in section 2.6, section 2.8, chapter 3 and section 4.1.

Future work: How can the industry make sure that the Internet of Things stays secure despite the huge increase of devices?

Since there are limited means of security in DNS, there needs to be more research and focus on security. This is especially concerning because there will be more devices in the health sector and they will be carrying sensitive data.

Covered in section 4.2.

(26)

21 5.1 Future work

This thesis only covered a literature study on how DNS could be affected in the Internet of Things. In the future, it would be advisable to make simulations and tests, and to study how DNS, DNSSEC, mDNS and DNS-SD work with the Internet of Things. This includes looking at how well an mDNS/DNS-SD will scale in the Internet of Things and how suitable such an implementation is for larger local networks.

Another area that needs further research is testing the limits of an mDNS/DNS-SD implementation for constrained node networks and how the communication between these local constrained networks will evolve.

The field of IoT is an on-going and growing area of research, with multiple papers and articles published each week. IoT technology is being established at this very moment, and it is up to the current researchers and developers to set a solid foundation for this field to stand on so that the Internet of Things can become the global infrastructure it is defined as.

(27)

22

References

[1] S. Parks and M. Albertini, “ITU: Commited to connecting the world,”

ITU, 17 07 2015. [Online]. Available:

https://www.itu.int/net/pressoffice/press_releases/2015/31.aspx#.Va k7jPlViko. [Accessed 18 04 2016].

[2] D. Evans, “The Internet of Things - How the Next Evolution of the Internet,” April 2011. [Online]. Available:

http://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IB SG_0411FINAL.pdf. [Accessed 29 March 2016].

[3] R. v. d. Meulen, “Gartner Says 6.4 Billion Connected "Things" Will Be in Use in 2016, Up 30 Percent From 2015,” Gartner, 10 November

2015. [Online]. Available:

http://www.gartner.com/newsroom/id/3165317. [Accessed 09 May 2016].

[4] P. Biggs, J. Garrity, L. Connie and A. Polomska, “Harnessing the Internet of Things for Global Development,” Geneva, 2016.

[5] L. Atzori, A. Iera and M. Giacomo, “The Internet of Things: A survey,”

Computer Networks, vol. 54, no. 15, pp. 2787-2805, 2010.

[6] K. Rose, S. Eldridge and L. Chapin, “The Internet of Things: an Overview,” Internet Society, October 2015.

[7] M. Gajewski and P. Krawiec, “Identification and Access to Objects and Services in the IoT Environment,” in Internet of Things (IoT) in 5G Mobile Technologies, Cham, Springer International Publishing, 2016, pp. 275-297.

[8] O. Vermesan, M. Harrison, K. Kalaboukas, al., “Identification Technology,” in Vision and Challenges for Realising the Internet of Things, Publications Office of the European Union, 2010, p. 59.

[9] P. Mockapetris, “RFC 882: Domain Names - Concepts and Facilities,”

IETF, 1983.

[10] K. Asthon, “That 'Internet of Things' Thing - RFID Journal,” RFID Journal, 22 June 2009. [Online]. Available:

http://www.rfidjournal.com/articles/view?4986. [Accessed 25 May 2016].

[11] M. Rouse, “What is remote patient monitoring (RPM)? - Definition from WhatIs.com,” TechTarget, November 2014. [Online]. Available:

http://searchhealthit.techtarget.com/definition/remote-patient- monitoring-RPM. [Accessed 25 May 2016].

[12] “ITU-T, Smart Sustainable Cities at a Glance,” ITU-T, [Online].

Available: http://www.itu.int/en/ITU-T/ssc/Pages/info-ssc.aspx.

[Accessed 25 May 2016].

[13] “Postscapes: Tracking the Internet of Things,” , [Online]. Available:

http://postscapes.com/internet-of-things-definition. [Accessed 18 04 2016].

[14] “ITU-T in brief,” ITU-T, [Online]. Available:

https://www.itu.int/en/ITU-T/about/Pages/default.aspx. [Accessed 18 04 2016].

(28)

23 [15] “Recommendation ITU-T Y.2060: Overview of the Internet of things,”

ITU, Geneva, 2012.

[16] C. Bormann, M. Ersue and A. Keranen, “IETF RFC 7228: Terminology for Constrained Node Networks,” May 2014. [Online]. Available:

https://tools.ietf.org/html/rfc7228. [Accessed 15 June 2016].

[17] T. Zachariah, N. Klugman, B. Campbell, J. Adkins , N. Jackson and P.

Dutta, “The Internet of Things Has a Gateway Problem,” Mobile Computing Systems and Applications: Proceedings of the 16th International Workshop, pp. 27-32, 2015.

[18] Z. Sheng, S. Yang, Y. Yu, et al., “A survey on the IETF protocol suit for the Internet of Things: Standards, challenges, and opportunities,”

IEEE Wireless Communications, vol. 20, no. 6, pp. 91-98, December 2013.

[19] G. Mulligan and C. J. Sreenan, “The 6LoWPAN architecture,”

Embedded networked sensors: Proceedings of the 4th workshop, (EmNets '07), pp. 78-82, 2007.

[20] J. F. Kurose and K. W. Ross, “3.3. Connectionless Transport: UDP,” in Computer Networking: A top-down approach, 6th ed., Pearson, 2013, pp. 198-204.

[21] I. Ishaq, D. Carels, G. Teklemariam, et al., “IETF Standardization in the Field of the Internet of Things (IoT): A Survey,” Journal of Sensor and Actuator Networks, vol. 2, no. 2, pp. 235-287, 2013.

[22] Z. Shelby, K. Hartke, C. Bormann, et al., “RFC 7252: The Constrained Application Protocol (CoAP),” June 2014. [Online]. Available:

https://tools.ietf.org/html/rfc7252. [Accessed 18 May 2016].

[23] “MQTT,” [Online]. Available: http://mqtt.org/. [Accessed 18 May 2016].

[24] “XMPP | Internet of Things (IoT),” [Online]. Available:

https://xmpp.org/uses/internet-of-things.html. [Accessed 18 May 2016].

[25] J. F. Kurose and K. W. Ross, “2.5. DNS - The Internet’s Directory Service,” in Computer Networking: A Top-Down Approach, 6th ed., Pearson, 2013, pp. 130-144.

[26] H. Elliotte Rusty, Java Network Programming, 4th edition, O'Really Media, Inc., 2013.

[27] “How Verisign Operates Internet Root Service,” [Online]. Available:

http://a.root-servers.org/metrics/index.html. [Accessed 18 04 2016].

[28] “Caching and Time to Live,” Microsoft, [Online]. Available:

https://technet.microsoft.com/en-us/library/cc958972.aspx.

[Accessed 18 04 2016].

[29] “DDoS attacks grow,” Network Security, vol. 2015, no. 5, pp. 2, 20, 2015.

[30] C. Malm, “Stor attack mot Telia,” IDG.se, 11 12 2014. [Online].

Available: http://www.idg.se/2.1085/1.601659/stor-attack-mot-telia.

[Accessed 18 04 2016].

[31] K. Örstadius, “Tusentals servrar kan bli verktyg för it-brott,” Dagens Nyheter, 11 04 2016. [Online]. Available:

http://www.dn.se/nyheter/sverige/tusentals-servrar-kan-bli-verktyg-

(29)

24 for-it-brott/. [Accessed 18 04 2016].

[32] L. H. Z. S. F. C. K. Z. Xiaolong Bai, “Defense against DNS Man-In-The- Middle Spoofing,” in Web Information Systems and Mining, Taiyuan, China, Springer-Verlag Berlin Heidelberg , 2011, pp. 312-319.

[33] R. Arends, R. Austein, M. Larsen, et al., “RFC 4033: DNS Security Introduction and Requirements,” IETF, March 2005. [Online].

Available: https://www.ietf.org/rfc/rfc4033.txt. [Accessed 09 May 2016].

[34] “Information about DNSSEC for the Root Zone,” IANA, VeriSign Inc., [Online]. Available: http://www.root-dnssec.org/. [Accessed 09 May 2016].

[35] “IANA -- Root Zone Management,” IANA, [Online]. Available:

https://www.iana.org/domains/root. [Accessed 09 May 2016].

[36] T. Manderson, “ICANN Research - TLD DNSSEC Report,” ICANN, [Online]. Available: http://stats.research.icann.org/dns/tld_report/.

[Accessed 09 May 2016].

[37] “Overview of DNSSEC,” Microsoft TechNet, 11 February 2014.

[Online]. Available: https://technet.microsoft.com/en- us/library/jj200221.aspx. [Accessed 09 May 2016].

[38] S. Cheshire, “Multicast DNS,” [Online]. Available:

http://www.multicastdns.org/. [Accessed 9 May 2016].

[39] S. Cheshire and M. Krochmal, “RFC 6762: Multicast DNS,” IETF,

February 2013. [Online]. Available:

http://www.ietf.org/rfc/rfc6762.txt. [Accessed 09 May 2016].

[40] Multicast.svg. [Art]. Wikimedia.

[41] Unicast.svg. [Art]. Wikimedia.

[42] “Name (mDNS) Poisoning Attacks Inside the LAN,” January 2008.

[Online]. Available: http://www.gnucitizen.org/blog/name-mdns- poisoning-attacks-inside-the-lan/. [Accessed 09 May 2016].

[43] S. Cheshire, “DNS Service Discovery (DNS-SD),” [Online]. Available:

http://www.dns-sd.org/. [Accessed 09 May 2016].

[44] S. Cheshire and M. Krochmal, “RFC 6763: DNS-Based Service Discovery,” IETF, February 2013. [Online]. Available:

http://www.ietf.org/rfc/rfc6763.txt. [Accessed 09 May 2016].

[45] J. Gubbi, R. Buyya, S. Marusic, et al., “Internet of Things (IoT): A vision, architectural elements, and future directions,” Generation Computer Systems, vol. 29, no. 7, pp. 1645-1660, September 2013.

[46] P. Martinez-Julia, A. J. Jara and A. Skarmeta, “Light-Weight Multicast DNS and DNS-SD (lmDNS-SD): IPv6-Based Resource and Service Discovery for the Web of Things,” Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing, pp. 731-738, July 2012.

[47] R. Klauck and M. Kirsche, “Enhanced DNS message compression - Optimizing mDNS/DNS-SD for the use in 6LoWPANs,” IEEE International Conference on Pervasive Computing and Communications Workshops, pp. 596-601, March 2013.

[48] P. Lopez, D. Fernandez, R. Marin-Perez, et al., “Scalable Oriented- Service Architecture for Heterogeneous and Ubiquitous IoT Domains,”

(30)

25

18 November 2013. [Online]. Available:

http://arxiv.org/abs/1311.4293. [Accessed 23 05 2016].

[49] A. Siljanovski, A. Sehgal and J. Schönwälder, “Service Discovery in Resource Constrained Networks using Multicast DNS,” Networks and Communications (EuCNC), 2014 European Conference, pp. 1-5, June 2014.

(31)

DNS and the Internet of Things: Outlining the challenges faced by DNS in the Internet of Things