7

Situation description

So when I build in the factory my super-sensor which would be sending its metrics every 30 seconds to AWS IoT via MQTT, I have to bake into the device a DNS domain name to which the sensor will be connecting.

AWS IoT suggests using endpoint in the form <random-string>.iot.eu-west-1.amazonaws.com which for me would look like A26PKG2U6WRS2I.iot.eu-west-1.amazonaws.com

Here's slightly formatted output of dig A26PKG2U6WRS2I.iot.eu-west-1.amazonaws.com command which shows that after few redirects this domain name resolves to 6 IP addresses, which seem to be load balancers.

DOMAIN DETAILS: 

A26PKG2U6WRS2I.iot.eu-west-1.amazonaws.com. 290 
POINTS TO CNAME 
iotmoonraker.eu-west-1.prod.iot.eu-west-1.amazonaws.com.


iotmoonraker.eu-west-1.prod.iot.eu-west-1.amazonaws.com. 254 
POINTS TO CNAME 
dualstack.iotmoonraker-e-elb-9q2vvmxp3rir-1271985754.eu-west-1.elb.amazonaws.com.

RESOLVES TO IPs:
dualstack.iotmoonraker-e-elb-9q2vvmxp3rir-1271985754.eu-west-1.elb.amazonaws.com. 50 IN A 54.229.34.249
dualstack.iotmoonraker-e-elb-9q2vvmxp3rir-1271985754.eu-west-1.elb.amazonaws.com. 50 IN A 52.19.106.35
dualstack.iotmoonraker-e-elb-9q2vvmxp3rir-1271985754.eu-west-1.elb.amazonaws.com. 50 IN A 52.18.139.53
dualstack.iotmoonraker-e-elb-9q2vvmxp3rir-1271985754.eu-west-1.elb.amazonaws.com. 50 IN A 52.48.96.41
dualstack.iotmoonraker-e-elb-9q2vvmxp3rir-1271985754.eu-west-1.elb.amazonaws.com. 50 IN A 52.19.155.13
dualstack.iotmoonraker-e-elb-9q2vvmxp3rir-1271985754.eu-west-1.elb.amazonaws.com. 50 IN A 54.76.47.209

Question

There're two concerns I have:

  • When I am implementing the MQTT communication in C for my PIC microcontroller, my DNS resolver is confused by that many IPs that a single domain can resolve to. And at the moment I don't know if I can fix that. For the moment my solution is - to create my own domain name iot-ingestion.domain-i-own.com and point it to one of the IP addresses. Is there a better option?

  • How reliable is it to bake into bake into my device this A26PKG2U6WRS2I.iot.eu-west-1.amazonaws.com hostname? What if I want to switch change IoT stack in 2-3 years and switch to different technology/provider?

Dimitry K
  • 2,236
  • 1
  • 28
  • 37

2 Answers2

7

Yes, I would avoid revealing an 'internal' AWS hostname. You should also avoid fixing to a single IP address. In AWS IP addresses can change rapidly and get re-assigned to other customers.

The solution is to indeed use your own domain name, which you have control over, but to use a DNS CNAME record.

iot-ingestion.domain-i-own.com CNAME A26PKG2U6WRS2I.iot.eu-west-1.amazonaws.com.

It may even be worth baking different hostnames into different device firmware versions, so if there is a problem with one you can re-point it at a different endpoint, or cut it off completely, if it is damaging your services.

I have had good experiences with using Route 53, Amazon's DNS service. Which may also result in fewer DNS requests from your device to get to the end IP address.

njh
  • 783
  • 3
  • 15
  • 3
    I voted this answer up, because in principle, I agree, though for a different reason than the one stated: I see no issue with revealing the AWS name, but prefer to keep things under my control. Now my vote is locked, but I have to reconsider: The problem is that a CNAME isn't going to be sufficient... because SSL. The certificate presented by IoT won't match what the client is expecting. You're going to -- at best -- have a certificate mismatch, and equally likely, the `Host:` header on the incoming request is not going to match with IoT is expecting. – Michael - sqlbot Mar 03 '16 at 18:32
  • 1
    @Michael-sqlbot I have tested and thereis NO ssl mismatch, because the security model in AWS IoT is wrapping data in TLS1.2 tunnel, but it is NOT using any of the `Common Name (CN)` headers within the certificate. Unlike in HTTPS where **server** has to prove it is who he is, to the browser, in AWS IoT it's the device who has to prove to identify itself to a server. The security is based on the fact - if devices owns certificate and can sign with private key - it is ok to be ingested by any of AWS endpoints. – Dimitry K Mar 04 '16 at 09:06
  • @DimitryK Could you explain how you solved that? I'm using the AWSIoTPythonSDK and when I try to connect to a CNAME I created for the AWS IoT endpoint via MQTT, I get: `ssl.SSLError: ('Certificate subject does not match remote hostname.',)` – Rich Sutton Sep 29 '16 at 00:07
  • @RichSutton In order to diagnose the problem, can you please first try to connect to your endpoint via MQTT.fx? Does it work? – Dimitry K Sep 29 '16 at 15:38
  • 1
    @DimitryK I think SSL will be SSL no matter which library is being used to connect. I'm sure there's a way to disable SSL certificate verification to make my client ignore the fact that the hostname doesn't match the certificate subject CN, but I think an IoT system should be designed to only send data to the server(s) it trusts. Ultimately, AWS has to offer this as a feature to IoT users. – Rich Sutton Sep 30 '16 at 17:34
  • @RichSutton AFAIK IoT libraries (at least ones I use Javascript Aws IoT Sdk and also C-library used in PIC Microcontrollers) do not verify hostname or anything like that. They just match binary contents of the keys/certs. Thus I proposed you to use MQTT.fx tool to first test your certs and configuration. AWS worked w/o problems for me, so I would disagree that it is improperly designed. – Dimitry K Sep 30 '16 at 17:58
2

I believe this post is related. As of June 2019, custom domains do not seem to be officially supported for IOT endpoints, but are on the road map. This is a common ask from our customers.

This link provides further clarification.

Worthwelle
  • 1,244
  • 1
  • 16
  • 19
OrangeBadger
  • 21
  • 1