Use Static IPs in Avimark Shortcuts for Safety
-
Overview: We have recently discovered an error in Covetrus’ "requirements" for AviMark that creates a fragility and is based on a misunderstanding of network name discover in Windows and Windows-based networks by the vendor. Systems can be impacted by this somewhat at random, or never, but it is an unnecessarily risky configuration and less performant than an ideal one. The vendor requirement of using hostnames in URIs for the shortcuts can be workable but only in an environment that runs a full, management DNS server that is correctly configured. Covetrus often does not recommend this configuration, however, and the majority of their deployments do not have this safety measure and even those that do have unnecessary levels of complexity and dependencies that can be avoided.
Details: Covetrus has mistakenly relied on a guessed outcome of a race condition in DHCP name assignments within automated DNS configurations that are a common configuration in small businesses. Their assumption is that the identity of the Avimark server operating system will be detected consistently by a DHCP server which will then automatically populate a DNS entry that will be used to point services to the server. This works the majority of the time, but it is not deterministic and can fail at random. If such a system does not exist (either because there is no DHCP or because auto-populating DNS is not configured) then DNS lookups of the hostname will fail and Windows will fall back to a WINS name resolution system which will pull the nbtname of the system via unconfigured WINS and attempt to rectify the name resolution in that way. This works the majority of the time, as well. But DNS hostnames and nbtnames are not actually tied together and will not necessarily work. Each piece of this assumes something will “just work” without actually being configured to do so.
Three common flaws exist in this process. The first being simply when no DNS or WINS is available at all, the system simply does not function. The second is when DNS and WINS are not configured the same and WINS is required (This one is preventable by the system administrators.) The third and most common is when DHCP and auto-populating DNS do work, but the race condition gives them a different entry in the DNS table as primary than the one expected by the Avimark configuration thus pointing the Avimark shortcuts to the wrong location. Because the Covetrus documented process is non-deterministic, this presents a sizeable risk and the race condition is actually expected to fail in cases where certain enterprise class devices are used and configured. The Avimark documentation assumption is that the race condition is uncommon in consumer devices, which is likely the only type they have tested on.
The fix is simple, instead of using Covetrus’ documentation which is demonstrably incorrect under standard conditions, CCW is manually configuring to follow standard best practices instead and using IP address entries which are static and deterministic removing the entire need for name lookups altogether. This removes many layers of fragility, removes the need for complex DNS management to overcome a gap in Avimark design, improves performance, and improves security.
Importantly, moving to static IPs in the shortcuts allows for IT departments of any skill level to reliably provide server discovery for Avimark. And it removes the need for clinics to implement and maintain additional servers and complexity only for the purpose of avoiding the use of a best practice.
-
Other processes can be used to fix this issue. Running a DNS server of any type will solve the issue, if correctly configured and if it does not fail. Using hostname entries on each workstation is an option, but creates much more work and is confusing for many IT departments. No solution is as simple, reliable, or as elegant as simply using IP addresses. As Avimark cannot be load balanced, there is little purpose to the abstraction of hostnames in the real world, but strong benefits to avoiding them.
-
As with most software vendors, it is common that a company that makes (or just sells) software to have little or no IT knowledge and to make recommendations or even requirements that are illogical or even completely dysfunctional. There is no reason for Covetrus to have recommendations around this as it is outside of their scope (and clearly, outside of their ken.) This is an IT function and has nothing to do with their software, overriding common IT knowledge and industry best practices should only be done when there is a solid understanding of the problem domain - something we would not expect from a software vendor, and something consistently not demonstrated by Covetrus (they also regularly recommend pirating Windows and violating the EULA to their customers, something they only have some legal ability to do by disavowing any IT responsibility or knowledge.)
-
I wonder if your assumptions are correct. They are probably just using gethostbyname() / getaddrinfo() to find the IP and then it's the OS (Windows) that is responsible for the behavior you're seeing.
As I'm sure you know those function are part of socket programming functions of the OS. Based on BSD originally but Microsoft must have added code to deal with netbios, wins and whatever they've been doing since the days of Wfw.
Linux by comparison only deals with name resolution by DNS and manual hosts files. I can't think of anything else right now at least.
