# Hostnames on 8.1 to 8.3 **URL:** \ **Category:** Ignition\ **Tags:** vision\ **Created:** [July 15, 2026, 6:42am UTC](https://forum.inductiveautomation.com/t/hostnames-on-8-1-to-8-3/116409 "2026-07-15T06:42:18Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![jake.bierman](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@jake.bierman](https://forum.inductiveautomation.com/u/jake.bierman)\ **Post date:** [July 15, 2026, 6:42am UTC](https://forum.inductiveautomation.com/t/hostnames-on-8-1-to-8-3/116409/1 "2026-07-15T06:42:18Z")
Hey everyone, I'm currently testing a project migration from Ignition 8.1.54 to 8.3.7 and have run into an issue with `system.util.sendMessage()`. Our existing implementation targets Vision clients using the client hostname. In 8.1 this worked because the hostname was returned as just the machine name. However, in 8.3 it appears that the hostname now includes the DNS suffix. For example: - **Ignition 8.1.54** - `system.net.getHostName()` → `PC-NAME` - Client hostname in message responses → `PC-NAME` - **Ignition 8.3.7** - `system.net.getHostName()` still returns `PC-NAME` - However, `system.util.sendMessage()` responses list clients as `PC-NAME.domain.local` I can also confirm the same behaviour from the Gateway Vision Diagnostics page. The screenshots below are from two cloned Windows 11 VMs with identical network adapter settings, one running 8.1.54 and the other 8.3.7. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/c/2cbf37a734ad3bd74bccc885eb46890f155bb5fe.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/8/381c6d339bd9010fb85b09dcb9ce6e89e3698dd9.png) What I'm trying to determine is whether this is an intentional change in Ignition 8.3 or if it's related to something else in my environment. I haven't been able to find any mention of this change in the migration documentation or release notes. Has anyone else seen this behaviour, or can confirm whether 8.3 now reports Vision client hostnames as FQDNs? If this is expected, I'm trying to determine the best approach for updating our existing messaging scripts without having to modify every hostname comparison. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 15, 2026, 12:19pm UTC](https://forum.inductiveautomation.com/t/hostnames-on-8-1-to-8-3/116409/2 "2026-07-15T12:19:32Z")
It is your environment. The host name is retrieved with a reverse DNS lookup in your infrastructure. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [July 15, 2026, 5:14pm UTC](https://forum.inductiveautomation.com/t/hostnames-on-8-1-to-8-3/116409/3 "2026-07-15T17:14:48Z")
What value is set for 'Resolve Client Hostnames'? > **[HTTP Settings​ - Web Server Settings | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.3/platform/gateway/web-interface/network/web-server-settings#http-settings)** > > The Web Server Settings page is for configuring the HTTP and HTTPS ports, enabling SSL/TLS, redirecting traffic through a known address, and specifying whether or not all HTTP traffic should be forcefully redirecting to HTTPS. > [@jake.bierman](#): > > intentional change in Ignition 8.3 This particular thing changing was not intentional, but the way the client/designer resolve their hostname and send it up to the client was. This was always a fairly fragile, "best-effort" thing, and for the sake of performance and correctness we swapped to an explicit enumeration of local interfaces meeting certain criteria. You can run this in the script console and see if that's the source of the different results: ```python from java.net import InetAddress, NetworkInterface, Inet4Address def getHostName(): interfaces = NetworkInterface.getNetworkInterfaces() while interfaces.hasMoreElements(): iface = interfaces.nextElement() addresses = iface.getInetAddresses() while addresses.hasMoreElements(): addr = addresses.nextElement() if (not addr.isAnyLocalAddress() and not addr.isLoopbackAddress() and not addr.isMulticastAddress() and isinstance(addr, Inet4Address)): return addr.getHostName() return InetAddress.getLocalHost().getHostName() print "8.3", getHostName() print "8.1", InetAddress.getLocalHost().getHostName() ``` ---
**Author:** ![jake.bierman](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@jake.bierman](https://forum.inductiveautomation.com/u/jake.bierman)\ **Post date:** [July 16, 2026, 12:01am UTC](https://forum.inductiveautomation.com/t/hostnames-on-8-1-to-8-3/116409/4 "2026-07-16T00:01:22Z")
> [@paul-griffith](#): > > Resolve Client Hostnames Hi Paul, I have tried with 'Resolve Client Hostnames' on and off, and did not seem to affect anything, at least for what I was looking at in hostnames. I tried that function and the print out matches the difference between them, I think I may move forward using system.vision.getClientId() and system.util.getSessionInfo() to find the session hostname that will always match the hostname required for the sendmessage to reach it again. The below snippet seems to work well and should be backwards compatible and going forward if it changes for any reason should keep the hostname consistent with what sendMessage will expect ```python hostName = '' clientId = system.vision.getClientId() sessions = system.util.getSessionInfo() for s in sessions: if s['clientId'] == clientId: hostName = s['address'] ``` ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 16, 2026, 12:25am UTC](https://forum.inductiveautomation.com/t/hostnames-on-8-1-to-8-3/116409/5 "2026-07-16T00:25:32Z")
Consider not using host names. If the client is supplying anything to be used to guide a later `.sendMessage()`, it should be the client ID. No need to involve DNS at all. ---
**Author:** ![jake.bierman](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@jake.bierman](https://forum.inductiveautomation.com/u/jake.bierman)\ **Post date:** [July 16, 2026, 12:31am UTC](https://forum.inductiveautomation.com/t/hostnames-on-8-1-to-8-3/116409/6 "2026-07-16T00:31:16Z")
I also tried this and was simple enough and also agree this would be the most reliable method, but the implementation will end up with multiple sessions on a single host, and this will be used to limit control to a single point hence using user/host such that it targets all sessions for that user on that host. Haven't thought of another idea to achieve this but will be keeping my thoughts open as we test for any improvements. ---
**Author:** ![jake.bierman](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@jake.bierman](https://forum.inductiveautomation.com/u/jake.bierman)\ **Post date:** [July 16, 2026, 3:52am UTC](https://forum.inductiveautomation.com/t/hostnames-on-8-1-to-8-3/116409/7 "2026-07-16T03:52:37Z")
@paul-griffith We have it working now, but I do have a follow up question. Should both the '[System]Client/Network/Hostname' tag and system.net.getHostName() not return the same hostname required by sendMessage? Regardless of how it its resolved, I would expect these two to be aligned, or at least be have this documented in the sendMessage documentation that it requires a fully qualified name and that the tag/function does not return a fully qualified name. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [July 16, 2026, 9:37pm UTC](https://forum.inductiveautomation.com/t/hostnames-on-8-1-to-8-3/116409/8 "2026-07-16T21:37:25Z")
That's a fair question. One answer is that we consider the return value of `system.net.getHostName()` (and the system tag, which internally actually calls in to the same code as the scripting function) sacrosanct public API, subject to a backwards compatibility contract, but we don't consider the hostname the client/designer self-reports to the gateway to be stable public API. And while that's true, a more honest answer is that we probably just didn't realize the discrepancy. I will say that in general, what Phil suggested is the best advice. Using Ignition's internal identifiers is definitely going to be more future-proof. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 16, 2026, 10:03pm UTC](https://forum.inductiveautomation.com/t/hostnames-on-8-1-to-8-3/116409/9 "2026-07-16T22:03:24Z")
I will add that when I was studying how to implement my Integration Toolkit's [@system.util.runInClient](https://www.automation-pros.com/toolkit/doc/utility.html#runinclient) decorator, I explicitly rejected attempting to implement anything other than client ID targetting. IA may be stuck maintaining support for something that depends on the environment's DNS implementation, but _ **I'm** _ not putting my hand into that meat grinder. FWIW. ---
**Author:** ![jake.bierman](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@jake.bierman](https://forum.inductiveautomation.com/u/jake.bierman)\ **Post date:** [July 17, 2026, 12:52am UTC](https://forum.inductiveautomation.com/t/hostnames-on-8-1-to-8-3/116409/10 "2026-07-17T00:52:31Z")
Thanks, will keep this in mind moving forward and reassess to see if we want/need to change anything.