When remote HMI programming software needs an IP, not a DNS name

Why the hostname will not connect

DNS does one job: it turns a name into an address. The DNS service on the site's router keeps the site's name pointed at its current public address, and a name-aware program such as a browser follows it. The programming client follows a different rule. It is not DNS-aware: its link field stores a number and gives a name nowhere to go. That is also why a session saved with last month's address dies after the public address changes, even though the name still opens the panel's web pages.

Decide your case with one look at the link setup. If the field accepts a name, enter it and skip the rest of this page; some tools and gateway drivers do resolve names, and a gateway configured with a DNS hostname URL reaches its controller by name. If the field is numeric only, do the lookup below. The panel's own address inside the plant is a separate device-side setting, assigned automatically or entered by hand, and nothing in this procedure touches it.

What you need

• The Dynamic DNS hostname, spelled exactly as the service registered it.
• The programming computer on its usual network, with the operating system's lookup tools: nslookup, with ping as the fallback.
• The DNS service dashboard, or the site router's WAN status page, for the cross-check.
• An approved way into the site: the port forwards the network owner configured, or a site VPN.

Resolve the name, enter the address, check the session

1. On the programming computer, resolve the hostname: nslookup plantline1.example.net, with your hostname in place of the example name. The answer prints the current address, for example 203.0.113.47. ping plantline1.example.net prints the same address on its first line when nslookup is unavailable.
2. Cross-check the answer against the DNS service dashboard or the router's WAN status page. Two matching values of 203.0.113.47 mean the record is current. An answer inside the private ranges set aside for local networks, 192.168.x.x, 10.x.x.x or 172.16.x.x through 172.31.x.x, is a resolver answering from the wrong side; take the public address from the router page instead, and refresh the record from the DNS service dashboard, because a record that missed an update is the usual reason a lookup and the router page disagree.
3. Open the communication link setup in the programming software and replace the stored address with the one from step 1. Change nothing else in the project: the limitation is name resolution only.
4. Connect and check the target: the session must name the panel you meant before any upload or download starts. If it names a different target, close without changes and repeat step 1.

Example: a Friday session and a Monday session

Setup for the example: hostname plantline1.example.net, a DNS record with a 60-second TTL, and a site internet lease of one day, 86,400 seconds (60 × 60 × 24).

Friday 07:58: the lookup returns 203.0.113.47. The router's WAN page reads 203.0.113.47. Match, so the record is current. Enter 203.0.113.47 in the link field, connect, make the change, close.

Over the weekend the lease expires and renews, and the provider assigns a different public address, 203.0.113.152. The router reports it to the DNS service, which updates the record at 06:00 Monday. The project file still holds 203.0.113.47.

Monday 08:00: the connect attempt on the stored address fails. Run the lookup again: it returns 203.0.113.152. The record changed at 06:00:00 with a 60-second TTL, and 06:00:00 plus 60 seconds is 06:01:00, so every resolver holds the new address by then and the 08:00 answer is safe to use. Enter 203.0.113.152, connect, and the session opens.

The result: one lease cycle, 86,400 seconds, was enough to stale a stored address, and one lookup fixed it. The name never moved; the number behind it did.

When the address is right and the link still fails

The address names the destination; the path is a separate matter. Work down this list:

1. Resolve again. A lookup older than one lease cycle may already be out of date.
2. Check the forward. The site router must carry the programming traffic from the public address to the panel's local address, and a forward set up for the panel's web pages does not cover the programming port. Work through the step-by-step checks for a failed remote access port forward, and note why a port forward does not change the HMI programming TCP port: the rule must point at the port the software actually uses, which its own documentation prints. Do not guess port numbers.
3. Check the panel's corner of the plant network. Switches and long cable runs between the router and the panel add their own failure points, the same planning problem as an HMI screen connected 1,500 feet from the PLC.

Ping gets one honest line here: a reply does not confirm the programming service is reachable, and a timeout does not confirm the panel is offline, because many sites block ping at the firewall. Judge the link by the software's own connect message.

The security rule above all of this: work only on the access path the site's network owner approved, a VPN or the specific forwards they configured. Never open the panel's programming port straight to the public internet to make a session easier to reach, and hand the job to the network owner when the destination or the path is in doubt.

Keep the address current, and when to stop re-resolving

Two timers set the routine. The lease timer belongs to the provider: a typical small-site lease is one day, 86,400 seconds, and a renewal can issue a different public address. The cache timer belongs to the record: Dynamic DNS providers publish short TTLs, commonly 60 seconds, so a fresh record reaches resolvers within a minute. Read the TTL from your lookup output and the lease from the router's DHCP or WAN page, and build the habit on them: resolve immediately before every session, never from a note.

Put the procedure in the job sheet: hostname, lookup time, address returned, and the software's message if the connect fails. For a site you program every few weeks, change the setup instead of repeating the lookup each visit. Ask the network owner for a static public address from the provider, or for a site VPN, and the stored number stops moving.

Recommendation: when the programming client's link field is numeric only, resolve the Dynamic DNS hostname immediately before each session, cross-check the answer against the router's WAN status page, and enter that address in the link field; if the same site needs programming more often than about once a month, ask its network owner for a static public address or a site VPN instead of re-resolving on every visit.

Questions