iTranslated by AI
Redirecting IoT Device Data Destinations with SORACOM Without Firmware Updates
TL;DR
- Even if a destination URL (e.g.,
harvest.soracom.io) is hardcoded in a device's firmware, you may be able to change the destination IP address by intercepting and replacing DNS responses. - SORACOM's Custom DNS allows you to specify a DNS server that is IP-reachable from an Air SIM device.
- In this article, I used
VPG (Virtual Private Gateway) Type-E + Gate D2D + Arc vSIM on EC2 + dnsmasqto resolveharvest.soracom.ioto100.127.69.42. - I did not expose port 53/tcp or 53/udp of the EC2 instance to the internet, limiting the DNS entry point to the IP address
10.128.0.53assigned to the Arc vSIM.
Introduction
When operating IoT devices, you may occasionally find that you need to change the cloud-side destination where devices send their data.
For example, in the following cases:
- You want to migrate from a legacy receiving infrastructure to a configuration using SORACOM Beam, etc.
- You want to change a configuration that sent data directly to SORACOM Harvest Data to one that forwards it to SORACOM Beam, etc., via the Unified Endpoint.
- You want to migrate a device that sent data to a destination in a LAN environment or closed network to one that sends it to a cloud-side destination via cellular communication.
All of these boil down to the problem of "wanting to change the destination URL" from the device side.
Normally, updating the firmware to change the destination URL is the most straightforward approach.
However, if there is no remote firmware update (OTA) mechanism, the devices are already installed in the field and difficult to retrieve, or a large number of devices are already in operation, it becomes difficult to rely solely on firmware updates.
Therefore, this article explains how to change the data destination by replacing name resolution results using Custom DNS on the SIM group side and a private DNS server, without changing the device's firmware.
As an example, we will treat a device that has the entry point for SORACOM Harvest Data, harvest.soracom.io, hardcoded into its code without being aware of the Unified Endpoint, and point it toward the Unified Endpoint entry point.
The idea is that while the device code still says harvest.soracom.io, the DNS response returns the IP address for the Unified Endpoint.
Refining the Implementation Method and Trade-offs
Prerequisite: Do not change firmware
In this article, firmware updates are excluded from the prerequisites. We will focus on cases where the destination URL on the device side cannot be changed due to reasons such as no OTA mechanism, difficulty in physical retrieval, or a large number of devices already in operation.
Target for DNS Replacement
With this premise, the method that can be used is changing only the DNS response.
The various endpoints for SORACOM have records published on public DNS.
Even if you are not connected to SORACOM Air, you should see the same results by resolving the following:
dig harvest.soracom.io A +short
dig uni.soracom.io A +short
dig unified.soracom.io A +short
The example responses are as follows:
100.127.111.111
100.127.69.42
100.127.69.42
| FQDN | IP Address |
|---|---|
harvest.soracom.io |
100.127.111.111 |
uni.soracom.io |
100.127.69.42 |
unified.soracom.io |
100.127.69.42 |
Therefore, we will have the target device resolve harvest.soracom.io to 100.127.69.42.
harvest.soracom.io -> 100.127.69.42
100.127.69.42 is the observed value treated as the destination for the Unified Endpoint in this configuration example.
While it is responded to via public DNS, this is not intended to be treated as a global IP address generally reachable from the internet; rather, it is a destination used from communication paths such as SORACOM Air.
If FQDNs can be used in firewall or fixed device settings, using the FQDN is safer.
In this method, the dnsmasq side holds an override configuration like harvest.soracom.io -> 100.127.69.42.
Therefore, if SORACOM's DNS records change, the overridden IP address must also be reviewed.
In actual operation, it is safer to monitor the resolution results of uni.soracom.io or unified.soracom.io periodically, and prepare an operation to update and reload the dnsmasq configuration upon detecting changes.
Where to Place the DNS Server
Normally, a device resolves harvest.soracom.io using public DNS.
To counter this, the SORACOM Air SIM group has a "custom DNS" setting that allows you to specify a DNS server to distribute to the device.
For the custom DNS, you specify the IP address of a DNS server that is reachable by IP from the target device.
One approach is to expose the DNS server to the internet and specify that global IP address in the custom DNS.
However, in this article, we will not expose the DNS server to the internet.
We will place the DNS server on an EC2 instance and join it to the SORACOM private network using SORACOM Arc vSIM.
From the Air SIM device, we will reach the Arc vSIM on EC2 via Gate D2D, and specify the IP address assigned to the Arc vSIM in the custom DNS.
In SORACOM screens and settings, an IP address assigned to such a SIM/vSIM is sometimes referred to as a "UE IP."
In this article, I will refer to it as "the IP address assigned to the Arc vSIM" hereafter.
Selecting the DNS Server Implementation
Assuming the DNS server is placed within the private network, we compare the implementation candidates.
| Method | Suitable Case | Trade-off |
|---|---|---|
dnsmasq |
Overwriting only one record, wanting to start lightly | Simple and suitable for this time. Weak at advanced ACLs or detailed cache control |
| Unbound | Wanting to build a robust DNS server | More configuration items, but easier to handle ACLs and cache control |
| BIND | Wanting to manage finely as an authoritative DNS | Overkill for this use case. Making a zone for the entire soracom.io can easily break other name resolutions |
| CoreDNS | Wanting to operate in Kubernetes or container environments | Easy to handle if a container infrastructure exists, but dnsmasq is easier for a standalone EC2 |
| Route 53 Resolver Inbound Endpoint | Wanting to integrate with the AWS-side DNS infrastructure | Easy to handle as a managed service, but incurs costs for dedicated resources |
For this use case, dnsmasq is the most straightforward.
It can provide a fixed response for harvest.soracom.io and forward other name resolutions to an upstream DNS.
If you only need to resolve SORACOM endpoint names as in this case, public DNS can also resolve them.
If you also need to resolve internal corporate domains or names within a private network, change the forwarding destination to a DNS capable of resolving those.
Even if using BIND, you must overwrite only harvest.soracom.io rather than setting the entire soracom.io as an authoritative zone.
Instance Size
For instance size, if it is only for overwriting a single DNS record, focus on memory and stability of persistent connection rather than CPU.
t4g.nano is sufficient for verification, but when including the OS, WireGuard, dnsmasq, logs, and monitoring agents, t4g.micro is easier to handle for production minimums.
For redundancy, a configuration preparing two t4g.micro instances, creating two Arc vSIMs, and specifying them as the Primary and Secondary of the custom DNS is a good cost-effective compromise.
Note that the prices for EC2, VPG, and SORACOM Arc vary depending on the region, timing, and contract conditions, so be sure to check the latest pricing information before actual operation.
Trade-offs for this Configuration
This article focuses on a configuration using VPG Type-E + Gate D2D + Arc vSIM on EC2 + dnsmasq.
Compared to a configuration using Route 53 Resolver Inbound Endpoint, your responsibility for operating the DNS server yourself increases.
On the other hand, a major advantage is that it can be started with a very small EC2 instance for the purpose of DNS overwriting of a single record, making it easy to configure at low cost.
Also, what can be replaced by DNS is the name resolution result.
For communication that checks the host name at the application layer, such as HTTP Host headers or HTTPS SNI/certificate validation, separate confirmation is required.
Details of the Configuration
We decompose the architecture diagram from the beginning in terms of communication paths and resources created.
Breaking down what we are doing, there are three main points:
- Place a DNS server in a location reachable via IP from the Air SIM device.
- Distribute the IP address of that DNS server using the SIM group's custom DNS.
- On the DNS server side, change the response for the hard-coded FQDN to a different destination IP.
In this configuration, the DNS server is on EC2.
However, the destination as seen from the Air SIM device is not the EC2's public IP or private IP, but the IP address assigned to the Arc vSIM: 10.128.0.53.
Because Gate D2D allows the Air SIM device to reach this IP address, it can be used as a reference for the custom DNS.
The main resources used in the configuration example are as follows.
Identifiers such as SIM ID, IMSI, VPG ID, Group ID, Arc SIM ID, EC2 Instance ID, Public IP, and Security Group ID are masked for this public article.
| Item | Value |
|---|---|
| VPG | Type-E |
| SIM Group | Group for verification |
| Arc vSIM | For DNS server on EC2 |
| IP address of Arc vSIM used as DNS server | 10.128.0.53 |
| Device Subnet CIDR | 10.128.0.0/9 |
| EC2 Region | ap-northeast-1 |
| EC2 Private IP | Masked |
| EC2 inbound 53/tcp, 53/udp | Not opened |
| EC2 access path | SSM Session Manager |
We do not open 53/tcp or 53/udp in the EC2 Security Group.
DNS queries are reached through the WireGuard interface wg0 of SORACOM Arc, not from the internet.
SORACOM Side Settings
On the SORACOM side, we place the Air SIM and the Arc vSIM on the EC2 into the same VPG Type-E / Gate D2D reachable range.
The core of the configuration is the SIM group.
It is easiest to think about the steps in the following order:
- Create a VPG Type-E and enable inter-device communication using Gate D2D.
- Prepare an Arc vSIM for the DNS server on EC2 and use
10.128.0.53as the IP address assigned to the Arc vSIM. - Include the Air SIM and the Arc vSIM in the same SIM group, or a configuration where they can reach each other via Gate D2D.
- Associate the target VPG Type-E in the SIM group's VPG settings.
- Specify
10.128.0.53as the custom DNS for the same SIM group.
1. Create a VPG Type-E and Enable Gate D2D
First, create a VPG Type-E and confirm the IP address range of the device subnet.
In this example, 10.128.0.0/9 is used as the Device Subnet CIDR.
On the same screen, enable SORACOM Gate C2D / D2D in the device LAN settings.
This allows the Air SIM and Arc vSIM under the same VPG to reach each other via Gate D2D.
Reference Documentation:
2. Assign 10.128.0.53 to the Arc vSIM
Prepare an Arc vSIM for the DNS server on EC2 and assign 10.128.0.53 using the IP address map.
This IP address will be the reference destination specified in the SIM group's custom DNS later.
Reference Documentation:
In the screenshot, the IMSI of the Arc vSIM is masked.
3. Place the Air SIM and Arc vSIM in the Same Reachable Range
Configure the Air SIM and Arc vSIM to be in the same SIM group, or use a setup where they can reach each other via the same VPG Type-E / Gate D2D even if they are in different groups.
In the screen example, it is confirmed that the Arc vSIM used on the EC2 side belongs to the target SIM group.
The Air SIM side follows the same logic, placing it in the target SIM group or the same Gate D2D reachable range.
Reference Documentation:
In the screenshot, the SIM ID, ICCID, and IMSI are masked.
4. Associate the VPG Type-E with the SIM Group
In the VPG settings of the SIM group, associate the created VPG Type-E.
This ensures that Air SIMs belonging to that SIM group communicate under the VPG.
Reference Documentation:
In the screenshot, the VPG ID is masked.
5. Specify 10.128.0.53 as the Custom DNS for the SIM Group
Finally, enable custom DNS in the SORACOM Air for Cellular settings of the same SIM group and specify 10.128.0.53.
What you specify here is not the EC2's private or public IP, but the IP address assigned to the Arc vSIM running on the EC2.
Reference Documentation:
When the Air SIM device reconnects, 10.128.0.53 is distributed as the DNS for the PDP context.
At this point, the DNS server viewed from the Air SIM device becomes the IP address assigned to the Arc vSIM, rather than the EC2's private or public IP.
EC2 and Arc vSIM Settings
On the EC2 side, we prepare a Linux instance to run the DNS server, and then run the SORACOM Arc vSIM and dnsmasq on it.
Here, we assume a Linux distribution where WireGuard and dnsmasq can be used, such as Amazon Linux 2023 or Ubuntu.
The setup flow is as follows:
- Create an EC2 instance.
- Enable access to the EC2 via SSM Session Manager or similar.
- Do not open 53/tcp or 53/udp to the Internet in the Security Group.
- Install WireGuard and
dnsmasqon the EC2. - Deploy the SORACOM Arc vSIM WireGuard configuration to the EC2.
- Set the
wg0address to10.128.0.53/32. - Limit
dnsmasqlistening towg0for external requests. - Override only
harvest.soracom.ioto100.127.69.42.
1. Create an EC2 Instance
Create the EC2 instance using the standard procedure.
In this example, one Linux instance was prepared in the Tokyo region.
No large instance is required for DNS server purposes, and you can start with a small instance for verification.
In the screenshot, the instance ID, IP address, and DNS name are masked.
Reference Documentation:
2. Enable Access to the EC2 via SSM Session Manager
SSM Session Manager was used for the access path to the EC2.
This allows command execution on the EC2 without opening inbound ports for SSH.
To use this, the EC2 must have the necessary IAM role, the SSM Agent must be running, and the EC2 must have HTTPS reachability to Systems Manager.
If running in a private subnet, also check the access paths such as NAT Gateway or VPC Endpoints.
In the AWS Console connection screen, select SSM Session Manager and confirm that the Ping status is "Online" and the Session Manager connection status is "Connected."
Reference Documentation:
3. Do Not Open 53/tcp, 53/udp to the Internet in the Security Group
In this configuration, we do not expose the DNS server to the Internet.
DNS queries from Air SIM devices reach the IP address assigned to the Arc vSIM via Gate D2D.
Therefore, do not add inbound rules for 53/tcp or 53/udp to the EC2's Security Group.
In the example screenshot, there are 0 inbound rules.
Reference Documentation:
4. Install WireGuard and dnsmasq
Install the packages according to your distribution.
Since we will also perform verification using dig later, we include bind-utils for Amazon Linux 2023 or dnsutils for Ubuntu.
For Amazon Linux 2023, the command would be as follows:
sudo dnf install -y wireguard-tools dnsmasq bind-utils
For Ubuntu, it would be as follows:
sudo apt update
sudo apt install -y wireguard dnsmasq dnsutils
5. Deploy the SORACOM Arc vSIM WireGuard configuration to the EC2
Create a WireGuard configuration file from the SORACOM Arc vSIM session settings and deploy it to /etc/wireguard/wg0.conf on the EC2.
For the SORACOM Arc configuration steps, please also refer to the official documentation.
After that, enable wg-quick@wg0.
sudo systemctl enable --now wg-quick@wg0
6. Set the wg0 address to 10.128.0.53/32
The key point here is to use 10.128.0.53 as the IP address assigned to the Arc vSIM, rather than the EC2's private IP.
Subsequent dnsmasq processes will listen on this IP address on wg0.
The key elements of wg0 are as follows:
[Interface]
Address = 10.128.0.53/32
[Peer]
PersistentKeepalive = 25
AllowedIPs = <SORACOM private CIDR from Arc vSIM settings>, 10.128.0.0/9
It is important to match the Address with the IP address set in the SIM Group's Custom DNS. In this example, it is 10.128.0.53/32.
In addition, include 10.128.0.0/9, which is the Air SIM side Device Subnet CIDR, in the AllowedIPs along with the SORACOM private CIDR from the Arc vSIM settings.
This allows the Air SIM device to reach the Arc vSIM on the EC2 via Gate D2D.
PersistentKeepalive is set to 25 to maintain the path under NAT and on the cloud side.
dnsmasq Configuration
We configured dnsmasq on the EC2 to limit external listening to the WireGuard interface wg0. From here on, the operations are performed after logging into the EC2 via SSM Session Manager or similar.
7. Limit dnsmasq external listening to wg0
First, verify that wg0 is up and has 10.128.0.53/32 assigned.
ip addr show wg0
Next, create an additional configuration file for dnsmasq. Here, we create it as /etc/dnsmasq.d/soracom-override.conf.
sudo tee /etc/dnsmasq.d/soracom-override.conf >/dev/null <<'EOF'
address=/harvest.soracom.io/100.127.69.42
interface=wg0
bind-interfaces
server=1.1.1.1
server=8.8.8.8
EOF
The content of the configuration file is as follows:
address=/harvest.soracom.io/100.127.69.42
interface=wg0
bind-interfaces
server=1.1.1.1
server=8.8.8.8
By specifying interface=wg0 and bind-interfaces, it will not listen for DNS on the EC2's public or VPC interfaces. Since we have not opened 53/tcp or 53/udp in the Security Group either, it will not become an externally accessible DNS server.
Once the configuration is in place, enable and restart dnsmasq.
sudo systemctl enable dnsmasq
sudo systemctl restart dnsmasq
sudo systemctl status dnsmasq --no-pager
Since dnsmasq is bound to wg0, it may fail to start if dnsmasq is started before wg0 is up. In that case, start wg-quick@wg0 first, then restart dnsmasq.
sudo systemctl restart wg-quick@wg0
sudo systemctl restart dnsmasq
You can check the listening status with ss.
sudo ss -lntup | grep ':53'
For Air SIM devices, if it is listening on 10.128.0.53:53, it is in the state expected for this configuration. An example of the actual output is as follows:
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:* users:(("dnsmasq",pid=28627,fd=6))
udp UNCONN 0 0 10.128.0.53:53 0.0.0.0:* users:(("dnsmasq",pid=28627,fd=4))
udp UNCONN 0 0 [::1]:53 [::]:* users:(("dnsmasq",pid=28627,fd=8))
tcp LISTEN 0 32 10.128.0.53:53 0.0.0.0:* users:(("dnsmasq",pid=28627,fd=5))
tcp LISTEN 0 32 127.0.0.1:53 0.0.0.0:* users:(("dnsmasq",pid=28627,fd=7))
tcp LISTEN 0 32 [::1]:53 [::]:* users:(("dnsmasq",pid=28627,fd=9))
It is also listening on 127.0.0.1 and [::1], but not on the EC2's external interfaces. We confirm that it is listening on 10.128.0.53:53 as the path used by Air SIM devices.
You can also check the status of the dnsmasq service.
sudo systemctl status dnsmasq --no-pager
An example of the actual output is as follows. The EC2 private IP included in the hostname is masked.
● dnsmasq.service - DNS caching server.
Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; enabled; preset: disabled)
Active: active (running) since Thu 2026-05-14 15:15:34 UTC; 2 days ago
Process: 28625 ExecStart=/usr/sbin/dnsmasq (code=exited, status=0/SUCCESS)
Main PID: 28627 (dnsmasq)
Tasks: 1 (limit: 1014)
Memory: 544.0K
CPU: 15ms
CGroup: /system.slice/dnsmasq.service
└─28627 /usr/sbin/dnsmasq
May 14 15:15:34 <ec2-private-hostname> systemd[1]: Starting dnsmasq.service - DNS caching server....
May 14 15:15:34 <ec2-private-hostname> dnsmasq[28627]: started, version 2.90 cachesize 150
May 14 15:15:34 <ec2-private-hostname> dnsmasq[28627]: using nameserver 1.1.1.1#53
May 14 15:15:34 <ec2-private-hostname> dnsmasq[28627]: using nameserver 8.8.8.8#53
May 14 15:15:34 <ec2-private-hostname> dnsmasq[28627]: read /etc/hosts - 6 names
May 14 15:15:34 <ec2-private-hostname> systemd[1]: Started dnsmasq.service - DNS caching server..
8. Override only harvest.soracom.io to 100.127.69.42
In this configuration, we return 100.127.69.42 fixed only for harvest.soracom.io. The device firmware will continue to resolve harvest.soracom.io, but the actual connection destination IP is expected to be directed to the Unified Endpoint side. All other name resolution requests are forwarded to the regular upstream DNS.
EC2-side Verification
First, verify that dnsmasq responds as expected from the EC2 side.
dig @10.128.0.53 harvest.soracom.io A +short
The result is as follows:
100.127.69.42
Also, verify regular name resolution.
dig @10.128.0.53 example.com A +short
We confirmed that this is forwarded to the upstream DNS and returns the regular A record. An example of the actual output is as follows:
104.20.23.154
172.66.147.243
Additionally, verify reachability to the SORACOM side via Arc. Here, we are pinging 100.127.100.127, which was used to verify reachability to SORACOM in this test, using wg0 as the source interface. Since the same reachability test destination may not be available in your environment, please replace it with a destination you can verify in your currently used SORACOM environment.
ping -I wg0 100.127.100.127
This connectivity check was also OK. An example of the actual output is as follows:
PING 100.127.100.127 (100.127.100.127) from 10.128.0.53 wg0: 56(84) bytes of data.
64 bytes from 100.127.100.127: icmp_seq=1 ttl=64 time=9.65 ms
64 bytes from 100.127.100.127: icmp_seq=2 ttl=64 time=4.15 ms
64 bytes from 100.127.100.127: icmp_seq=3 ttl=64 time=3.98 ms
64 bytes from 100.127.100.127: icmp_seq=4 ttl=64 time=4.07 ms
64 bytes from 100.127.100.127: icmp_seq=5 ttl=64 time=3.99 ms
^C
--- 100.127.100.127 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 3.979/5.169/9.649/2.240 ms
Verification on Air SIM Device
On the Air SIM side, verify that the device has acquired 10.128.0.53 as the custom DNS and that harvest.soracom.io resolves to the expected IP address. This verification method can be adapted to your environment. Whether using a modem control tool on Linux or Windows, or serial logs from a microcontroller, it is sufficient to verify the device's own DNS resolution results.
In this example, we used a Soracom Onyx and verified it via AT commands. The method for sending AT commands to a Soracom Onyx from macOS is summarized in a separate article: "Sending AT Commands to Soracom Onyx on macOS". In this article, assuming you can open the AT console using that method, we will only cover the DNS verification results.
SIM information was checked using the following AT commands:
AT+CIMI
AT+QCCID
Although IMSI and ICCID are masked in this public article, we were able to confirm that the target SIM is as expected.
Next, activate the PDP context.
AT+CGDCONT=1,"IP","soracom.io"
AT+CGACT=1,1
AT+CGCONTRDP=1
The result is as follows:
+CGCONTRDP: 1,6,soracom.io,10.130.59.244,,10.128.0.53,
From this result, we can confirm the following:
| Item | Value |
|---|---|
| APN | soracom.io |
| IP Address assigned to device | 10.130.59.244 |
| Primary DNS | 10.128.0.53 |
| Secondary DNS | None |
In other words, the Air SIM device has successfully acquired 10.128.0.53 as the custom DNS for the target SIM group.
Verification of DNS Override
Finally, perform name resolution for harvest.soracom.io from the Air SIM device side.
AT+QIDNSGIP=1,"harvest.soracom.io"
The result is as follows:
+QIURC: "dnsgip","100.127.69.42"
As expected, harvest.soracom.io was resolved to 100.127.69.42. From the device's perspective, the destination hostname has not changed, but the DNS response has been substituted with the IP address pointing to the Unified Endpoint side.
Based on this result, we have confirmed that the DNS query from the Air SIM device was processed through the following path:
Summary
If you want to change the data transmission destination for IoT devices without changing the firmware, one approach is to combine the SIM group's custom DNS with an on-premises DNS server. If you can place a DNS server in a location reachable by the Air SIM device, you can make the device reference that DNS server via custom DNS. By overriding the response for a specific FQDN at that DNS server, you can switch the connection destination IP for devices with hardcoded transmission URLs, provided the conditions are met.
In this article, we used VPG Type-E + Gate D2D + Arc vSIM on EC2 + dnsmasq as a configuration example to override the Air SIM device's DNS within a closed network without using a Route 53 Resolver Inbound Endpoint. The key points are:
- Join the Arc vSIM on EC2 to the SORACOM closed network as
10.128.0.53/32 - Limit
dnsmasqexternal listening towg0 - Do not expose EC2's 53/tcp and 53/udp to the Internet
- Have the Air SIM device acquire
10.128.0.53as its custom DNS - Have the Air SIM device query the
dnsmasqon EC2 via Gate D2D - Return
100.127.69.42as the DNS response while keepingharvest.soracom.ioin the firmware
Since the DNS server is not exposed to the Internet and listens on the IP address assigned to the SORACOM Arc side, the DNS entry point is restricted to the SORACOM closed network side. Also, because it eliminates the need to create a Route 53 Resolver Inbound Endpoint, it is easy to start with a lightweight configuration for small-scale verification or limited use cases.
On the other hand, this configuration requires you to operate your own DNS server. In actual operation, it is necessary to consider the redundancy of dnsmasq, failover during EC2 failures, DNS logging, management of overridden domains, behavior during upstream DNS failures, and the impact scope per SIM group. This is not to suggest that this should always be used as a substitute for a Route 53 Resolver Inbound Endpoint, but rather a configuration example for substituting the transmission destination at the DNS level for devices where firmware cannot be changed.
Reference Documents
Discussion