Troubleshooting Siemens IOT2020 DNS Resolution on Static IP

Troubleshooting Siemens IOT2020 DNS Resolution on Static IP

The Siemens SIMATIC IOT2020 (6ES7647-0AA00-0YA2) and IOT2040 (6ES7647-0AA00-1YA2) are Intel Quark x1000-based industrial IoT gateways designed to bridge field-level PLC networks with higher-level MES, cloud, or analytics systems. Both ship with the Siemens "Example Image" based on Debian 8 (jessie) and the proprietary iot2000setup console tool that drives first-boot configuration through a serial terminal. A recurring field issue with these devices is that name resolution (DNS) works correctly under DHCP, but the moment a fixed / static IPv4 address is configured through iot2000setup, hostnames stop resolving and any application that depends on FQDN lookup (NTP, OPC UA, MQTT brokers, cloud SDKs, package updates) silently fails. This reference documents the root cause, the proven fix used by integrators in the field, and the verification steps that confirm DNS is genuinely restored rather than merely masked.

Affected Hardware, Firmware, and Image Revisions

The behavior described in this article is specific to the IOT2020/IOT2040 Example Image where iot2000setup writes /etc/network/interfaces directly and where resolvconf may or may not be installed depending on the exact point release. The IOT2050 uses a fundamentally different image and systemd-resolved; the manual /etc/resolv.conf edit pattern still works there but is not the canonical procedure.

Problem Statement

The fault pattern observed in the field is consistent across deployments:

1. The IOT2020 is configured through iot2000setup with DHCP. After reboot, ping 8.8.8.8 succeeds and ping google.com also succeeds. DNS resolution works.
2. The administrator reconfigures the device with a fixed IP address, subnet mask, and gateway through the same tool (or by editing /etc/network/interfaces directly).
3. After reboot, ping 8.8.8.8 still succeeds (Layer 3 is fine) but ping google.com fails with ping: unknown host google.com. The same behavior applies to every FQDN-based service the gateway runs.
4. Re-entering DHCP through iot2000setup immediately restores DNS. Re-entering a fixed IP breaks it again.

The output of cat /etc/resolv.conf after the failure typically shows either an empty file, a file containing only the literal word nameserver with no address, or a stale DHCP lease value that points at a server that no longer accepts the static client. The /etc/network/interfaces file may contain correct dns-nameservers directives, but those directives are silently ignored because resolvconf is not installed on the standard image and the ifupdown hooks have nobody to talk to.

Root Cause: Why DNS Stops Working After Static IP Configuration

The Example Image used by Siemens relies on the legacy Debian ifupdown network stack. The chain that should populate /etc/resolv.conf looks like this:

1. ifup eth0 parses /etc/network/interfaces.
2. If dns-nameservers 8.8.8.8 8.8.4.4 is present and the resolvconf package is installed, ifupdown passes the values to resolvconf, which atomically regenerates /etc/resolv.conf.
3. If resolvconf is not installed (default on the stock Example Image), ifupdown simply drops the directives and the file /etc/resolv.conf is never updated.

Under DHCP, the dhclient daemon writes /etc/resolv.conf directly via its resolv.conf hook script (/etc/dhcp/dhclient-exit-hooks.d/resolvconf or its fallback), which is why DNS appears to "work" only in DHCP mode. When the static configuration is written by iot2000setup, dhclient is no longer run, the hook is never executed, and no other component regenerates the resolver file.

A second failure mode compounds the issue: /etc/resolv.conf on the IOT2020 is sometimes a symlink to /var/run/resolvconf/resolv.conf. If resolvconf was never installed, that target file does not exist and the symlink dangles. Any attempt to overwrite the symlink target then writes to a non-existent path, leaving the operator convinced that the change "did not take".

Solution: Rebuild and Lock /etc/resolv.conf

The integrated procedure that resolves the issue on the IOT2020 / IOT2040 Example Image is the one documented in the original Siemens support thread and replicated by Siemens support engineers. It has three parts, all of which are required for a permanent fix.

Step 1 — Remove the stale /etc/resolv.conf

Connect to the IOT2020 either over the serial console (115200 8N1) or over SSH. Become root:

Inspect the current file and its inode:

ls -l /etc/resolv.conf
stat /etc/resolv.conf

If it is a symlink (which is the most common state on a stock image), unlink it:

If it is a regular file that was zeroed out by a failed DHCP attempt, delete it outright:

Step 2 — Write a fresh resolver file

Create a new /etc/resolv.conf with one or more valid upstream resolvers. Use the gateway IP (most reliable when on a routed corporate subnet) and a public fallback such as Google's 8.8.8.8 / 8.8.4.4 or Cloudflare's 1.1.1.1:

cat > /etc/resolv.conf <<'EOF'
# Generated manually for static-IP deployment
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver 1.1.1.1
search example.local
EOF

The search directive is optional but recommended when the IOT2020 needs to reach PLCs by short hostname (e.g. s7-1500 instead of s7-1500.plant.example.local). Use the DNS suffix your control network actually publishes; do not invent one.

Lock the permissions so the file is not silently overwritten by a misbehaving service:

chmod 644 /etc/resolv.conf
chown root:root /etc/resolv.conf

Step 3 — Make the file immutable

This is the step that prevents recurrence after reboot. The chattr +i flag tells the kernel to reject any write to the file, including writes from dhclient hooks, ifupdown scripts, or stray apt post-install hooks:

Verify the immutable bit is set:

lsattr /etc/resolv.conf
# expected output line: ----i---------e----- /etc/resolv.conf

If you ever need to edit the file later (for example to switch upstream resolvers), drop the immutable bit first:

chattr -i /etc/resolv.conf
nano /etc/resolv.conf
chattr +i /etc/resolv.conf

Verification Procedure

Run the following checks in order. Each one isolates a different layer of the resolver path.

1. Resolver file present and immutable:
   ls -l /etc/resolv.conf && lsattr /etc/resolv.conf
   Expected: regular file owned by root, ----i---------e----- flag set.
2. Layer 3 reachability:
   ping -c 3 8.8.8.8
   Expected: at least one reply. If this fails the gateway is the issue, not DNS.
3. Direct DNS query against each configured resolver:
   dig @8.8.8.8 google.com +short
   Expected: at least one A record. If dig is not installed, apt-get install dnsutils first.
4. Resolver library path:
   getent hosts google.com
   Expected: prints the IP address. This exercises libc → /etc/nsswitch.conf → /etc/resolv.conf end to end.
5. Application-level probe:
   curl -v https://www.siemens.com --max-time 10 -o /dev/null
   Expected: TLS handshake completes. If this fails but step 4 succeeds, suspect a transparent proxy, MTU, or TLS interception device on the corporate network.
6. Persistence after reboot:
   reboot and re-run steps 1 and 4 from a fresh SSH session. If DNS breaks again, the immutable bit was not honored (typically because the filesystem was remounted or the file was recreated by an init script).

Persistent Configuration Through /etc/network/interfaces

For deployments that prefer to keep all network state in one declarative file, install the resolvconf package so that ifupdown can update the resolver file automatically when the interface comes up:

apt-get update
apt-get install resolvconf

Then add the DNS directives to /etc/network/interfaces inside the iface eth0 inet static stanza:

auto eth0
iface eth0 inet static
    address 192.168.1.50
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 192.168.1.1 8.8.8.8 1.1.1.1
    dns-search example.local

Reboot, then verify:

ls -l /etc/resolv.conf
# Expected: /etc/resolv.conf -> /var/run/resolvconf/resolv.conf
cat /etc/resolv.conf

Apply the immutable bit to the underlying target file so that downstream hooks cannot clobber it:

Alternative: Disabling Network Manager Overrides

On later Example Image point releases (V2.6 and above), Siemens introduced NetworkManager alongside ifupdown. NetworkManager owns /etc/resolv.conf via its own dispatcher and will overwrite the file you manually wrote if it believes it has authority over the interface. To keep the manual file in place:

systemctl stop NetworkManager
systemctl disable NetworkManager

Then re-apply the immutable bit and reboot. This approach is acceptable on a single-ethernet device that is permanently wired into one control VLAN, which is the typical IOT2020 deployment topology.

Edge Cases: Corporate Proxies, IPv6, and Split DNS

Troubleshooting Matrix

Backup and Rollback Procedure

Before touching /etc/resolv.conf, snapshot the current network state so a broken change can be undone from the serial console:

cp /etc/resolv.conf /etc/resolv.conf.bak
cp /etc/network/interfaces /etc/network/interfaces.bak
cp /etc/nsswitch.conf /etc/nsswitch.conf.bak

Rollback is then a single command from the serial console:

chattr -i /etc/resolv.conf
cp /etc/resolv.conf.bak /etc/resolv.conf
chattr +i /etc/resolv.conf
systemctl restart networking

Frequently Asked Questions