While the \u201cnormal\u201d (bad) DNS behavior of devices and those of compromised devices are not directly related, there is an overlap in some of the mitigations that points us to how we can move toward security-by-design in the manufacture and operations of IoT. This article discusses the risks identified by the research, how these might be addressed and the mitigations network operators can use.<\/p>\n
Research Results<\/h3>\n
Using a large-scale IoT testbed, researchers at UCL and Inria analyzed 30 consumer IoT devices across categories such as cameras, doorbells, lights, sensors and medical devices.2<\/sup> The methodology included passive traffic inspection and active testing.<\/p>\n Key findings included:<\/p>\n Andrew Losty, a PhD student at UCL and one of the Internet Draft authors, presented research findings at RIPE 91,3<\/sup> and the slides and recording of this are available here<\/strong><\/a>. As one example, the following graph shows the lack of transaction ID randomization in some devices, making it more likely to accept a spoofed DNS response.<\/p>\n Figure 1. Transaction ID results<\/p>\n Strengthening DNS Security in IoT Devices<\/strong><\/p>\n To address the DNS-related vulnerabilities uncovered in the UCL and Inria research, we are working together on an Internet Engineering Task Force (IETF) Best Current Practice draft via the IoT working group. This is the logical place for this work as the DNS protocol is developed within the IETF and the IoT working group has a focus on the management and operations of the types of devices tested.<\/p>\n Manufacturers of IoT\/OT devices need to ensure adherence to the following:<\/p>\n More details can be found in the Internet Draft IoT DNS Security and Privacy Guidelines.4<\/sup><\/p>\n Network Operator Mitigations<\/strong><\/p>\n There are broadly two network operator types where IoT devices are deployed: service providers of consumer networks, for instance the networks we have at home, and organizations managing their own infrastructure. The main difference from a DNS perspective is that a consumer may use any DNS server, while an organization managing its own network should restrict DNS traffic to its own resolvers for security and policy reasons. In the consumer case it is advantageous for the end user to use the provider\u2019s resolvers and most home networks would do this in any case.<\/p>\n Operators can restrict networks where IoT devices are deployed to only query domain names in management zones via Protective DNS.5<\/sup> They can see what these are via analyzing DNS traffic, but we are calling on manufacturers to provide these, either by simply publishing them or via the use of the Manufacturer Usage Description (MUD) specification.6<\/sup><\/p>\n This means that the networks would be operated on a Zero Trust DNS basis, along the lines of Microsoft\u2019s Zero Trust DNS.7 This mitigates against devices being compromised, including in the supply chain.<\/p>\n Where DNS resolution needs to be more open, such as on consumer networks where any device can be deployed, the network operator can still use Protective DNS to block malicious domains used in the compromise or control of devices.<\/p>\n Operators should have resolvers validate responses via DNSSEC in any case, but specifically in the context of IoT it will allow devices to take advantage of manufacturers signing their public zones.<\/p>\n Regulation Improvements<\/strong><\/p>\n Having improved standards that are enforced through certification will move us to a more secure-by-design paradigm.<\/p>\n While organizations such as ETSI, ISO\/IEC, ITU-T and National Institute of Standards and Technology (NIST) have varying amounts of guidance on DNS security as it applies to IoT\/OT, there are certainly gaps here. Developing a Best Current Practice Draft within the IETF IoT Operations working group will allow this to be referenced by organizations such as ETSI where work for the certification of IoT devices is ongoing.<\/p>\n As an example, provision 5.5-5 in the ETSI EN 303 645 V3.1.3 (2024-09) standard states \u201cConsumer IoT device functionality that allows security-relevant changes in configuration via a network interface shall only be accessible after authentication. The exception is for network service protocols that are relied upon by the consumer IoT device and where the manufacturer cannot guarantee what configuration will be required for the consumer IoT device to operate.\u201d One of the exceptions is for DNS.<\/p>\n This should not exist as a blanket exemption. Rather than manufacturers complying with just device security, standards should consider the wider security context, especially where it is in same manufacturer\u2019s control. The ETSI standard states \u201cTo increase security, multi-factor authentication, such as use of a password plus OTP procedure, can be used to better protect the consumer IoT device or an associated service.\u201d The multi-factor authentication service and infrastructure is outside of the device and the manufacturer\u2019s control, whereas public management domains can be cryptographically signed, and devices can check if this has been verified\u2014all within one manufacturer\u2019s control.<\/p>\n The natural tension in this is keeping regulation generic enough to allow for developments in tech and to document intent or outcomes versus being protocol specific. This is where IETF Drafts and RFCs can be referenced to bridge the gap and mean standards bodies do not need to maintain specific detail on protocol compliance.<\/p>\n The message can be boiled down to manufacturers following the DNS standards we already have (as detailed in the Draft we published), helping operators by providing management domain information to secure networks, pushing the use of PKI to manage devices in the form of DNSSEC (we do this with certs) and regulators referencing this in their standards.<\/p>\n As we continue to work on the Draft, turning research findings into actionable guidelines, we invite you to join the conversation via the IETF whether you\u2019re a device manufacturer, network operator or security professional.<\/p>\n If you are a network operator or security professional there are some practices in the Draft that will improve network security and you can help practically, for instance ask the manufacturers of the devices you use to let you know the management domains names so you can lock down communications to only those domains via Protective DNS.<\/p>\n The Internet-Draft discussed in this blog has been authored by Jim Mozley (Infoblox), Abhishek Mishra (Inria), Andrew Losty (UCL), Anna Maria Mandalari (UCL) and Mathieu Cunche (INSA-Lyon & Inria).<\/p>\n\n
![\"Figure](\"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/iot-dns-security-figure1.jpeg\")
<\/p>\nRisk Mitigations<\/h3>\n
\n
Conclusion<\/h3>\n
Footnotes<\/h3>\n
\n