Skip to main content

DNS Based Device Name - Dynamic DNS Resolution

Name Syntax​

The second flavour of locally resolvable name does not use an embedded physical address. This approach must use some form of DynDNS for resolution:

<local-name> ::= <dev-id> "." <home-domain>

// dev-id is hash of device public key
<dev-id> ::=  {}

// bound-domain is a publicly resolvable domain name, with which the device is provisioned
<bound-domain> ::=  {}

Alternatively, it can announce itself with the equivalent HTTP URI, and (once contacted by a browser that has Internet connectivity on its own, even though not necessarily simultaneously) utilises the browser to obtain such a certificate.

This needs no more cooperation from the browser than regular JavaScript execution and can result in a redirect to equivalent HTTPS URI and thus the green padlock moments later.

This is likely achievable with current browsers. For an extended version that works even in fully offline situations, this can be adapted to a domain that promises to use the web service's policy.

Some user stories, details and the first stubs of what can become a tech demo can be found at GitHub - chrysn/provisioning-demo.

The provisioning flow for the DynDNS variant is almost identical; the only difference being is that the DNS registration and the Certificate request are made using:

[dev-id].devices.vendor.example

instead of:

*.[dev-id].devices.vendor.example

In other words, it is not necessary to register the wildcard because we are not prepending the physical address to the device name.

The provisioning can happen automatically when an unprovisioned device is connecting to the network. This would limit the user interaction for the first setup.

This method depends upon the ability of the device to update the authoritative DNS server for devices.vendor.example.

Name Provisioning​

The operational flow is triggered every time the user initiates a browser session with the target IoT device.

The user is expected to be in possession of the device in order to initiate this process.

sequenceDiagram Browser->>recursive DNS: Request IP using device URI recursive DNS->>authoritative DNS: Request IP using device URI Note right of authoritative DNS: Device URI: [dev-id].devices.vendor.example Note right of authoritative DNS: DNS server resolves address normally authoritative DNS ->>recursive DNS: IP resolved in browser recursive DNS->>Browser: IP resolved in browser Browser->> IoT Device: HTTPS request created target IP address, using device URI as common name IoT Device->> IoT Device: pre provisioned cert used to negotiate IoT Device->>Browser: Certificate is validated in normal way, using browser root CA's

whenever the physical address of the IoT device changes

sequenceDiagram IoT Device->> authoritative DynDNS Server: notify of new address authoritative DynDNS Server->> IoT Device: success

This interaction uses a credential that the device has with the DynDNS service. The credential may be provisioned in the factory.

Name Resolution​

Device DNS Name : operational flow - DynDNS variant

When using the DynDNS variant there are two parts to the operational flow:

  1. A flow initiated by the IoT device when the physical IP address changes (including the first time it is used).
  2. The flow initiated by the browser when connecting to the IoT device web server.

DynDNS Resolve​

The DynDNS resolution approach differs from the embedded local address; the DNS server uses the "most recent" physical address supplied by the DynDNS server instead of using the local address embedded within the device name.

sequenceDiagram Browser->>recursive DNS: Request IP using device URI Note right of recursive DNS: simply uses most recent physical address captured by the DynDNS server recursive DNS->>Browser: IP resolved in browser Browser->> IoT Device: HTTPS request created for the resolved IP address IoT Device->>Browser: Certificate is validated in normal way, using browser root ca's

Name Validation (Security)​

This approach has the advantage that it can leverage existing HTTPS certificate semantics and certificate issuing methods.

The issued certificates could make use of Key Usage and Extended Key Usage fields, so that local connections could be differentiated in the browser. Again, a browser change would be required to make this happen. It is unclear if there is any advantage to this.

Interim Analysis​

This solution shares many of the qualities of the previous approach (DNS Based Device Name - Embedded Physical Address).

The real differences that need to be considered:

  • This solution adds additional infrastructure: the IoT device needs a DynDNS like client, and the manufacturer/service provider will need to host this server. For devices that need to call home anyway, the addition of an IP address update may be very low cost.
  • Bootstrap the initial DynDNS server must either be done in the factory through provision of some credential (possibly a symmetric one), or via some bootstrapping protocol like BRSKI.
  • The fact we are using a DynDNS server means that global Internet access is needed in the operational as well as the provisioning mode.
  • If an RFC1918 IPv4 address is provided, then the Rebinding concerns also occur.
  • This solution seems to require more stateful support from the manufacturer, whereas the embedded mechanism of the previous system could be answered dynamically by a properly constructed server.