You are viewing limited content. For full access, please sign in.



Invalid host name. [782]

asked on February 10, 2014

 Our network users randomly get this error when trying to connect with the LaserFiche Client 9.0 from their desktop. It only seems to be one user affected at a time and restarting the PC seems to fix the issue. 


Does anyone have an advice on solving the issue? There is nothing popping up in the Event Viewer indicating a problem. I have also temporally disabled any port blocking done by Windows or Endpoint Protection...

0 0


replied on August 7, 2015

If you're getting an "invalid hostname", it doesn't mean your DNS isn't responding... it (in all likelihood) means your DNS is responding to your DNS query with an NXDOMAIN which means no record for that hostname exists in the DNS zone.  "that can't be possible, I do an nslookup immediately after and it resolves, so I know it's in DNS".  Read on... 


You'll need to understand two things... what's an NXDOMAIN response, and then how does your DNS client/resolver handle using multiple DNS servers.  


First, and NXDOMAIN response.  This is a valid response... it's different than a timeout.  An NXDOMAIN is a DNS server saying "I host a DNS zone for (I'm authoritative), and there is no record in that zone for", and your DNS client/resolver will CACHE that in your local DNS cache (this is sometimes referred to as negative caching) just like it would cache it if there was a response from the DNS server saying " resolves to".  


Usually, a DNS zone's administrator (or the DNS server software's defaults) will set the negative caching TTL lower than the standard TTL... so your DNS cache might hold a " resolves to" for 2 hours, but holds a "there's no record for" for only 5 minutes.   This explains why a scenario like this can seem so random and transient.   It also explains why an "ipconfig /flushdns" can resolve the issue. 


An aside... also remember that APPLICATIONS will cache DNS as well... so even if you flush your PC's DNS cache, if the application process is still running, it may be holding that negative cached value without checking back in the DNS cache, and it in all likelihood isn't observing TTL values.  Closing the app and relaunching it is the only way to definitively clear it. 


But the real question is why is your DNS infrastructure returning two conflicting sets of results, one time getting the IP, and one time getting an NXDOMAIN response.    This is where you need to understand how your PC's DNS resolver works.   Check your TCP/IP settings and you'll probably find you're configured to use 2 DNS servers for DNS resolution.  One is primary, the other secondary.  This means your DNS resolver will ALWAYS query the primary first and ONLY query the secondary when the primary is unresponsive.  So here's a real life scenario of what we've seen happen with a County government client...


Their PC's were configured to use two DNS servers:

- primary was one managed by the county

- secondary was one managed by the state


On the primary DNS server, managed by the county, a DNS zone for was hosted, and had an A record for resolving to  98% of the time this DNS server was perfectly responsive, user's PC's queried this server and got the information resolving to the IP address. 


2% of the time, that server did not response (for load/performance reasons).  In that scenario, a user's PC would then query the secondary DNS server, the state's.  It had a DNS zone for but it did not have a record for within that zone, so it replied with an NXDOMAIN response, i.e. I'm authoritative for this domain, and I can say authoritatively that no such hostname record exists in this domain/zone. 


The symptoms... randomly, intermittently, and seldomly (but enough to get everyone's attention), a user would get this invalid hostname error.  Different user every time.  Lasting only for a short duration.  Fixable by rebooting the PC or flushing the DNS cache (because on their next connection attempt, the primary DNS server would actually respond).  


How to prove this is happening? A couple ways:

  1. perform a DNS query directly to both the primary and secondary DNS servers configured for the affected user's PC and see if you get a   you can do this using nslookup, i.e.: 
    • nslookup primarydnsserverIP
    • nslookup secondarydnsserverIP
  2. presumably, you'll get the IP back you're expecting from the primary, but you'll get a different response from the secondary. 
  3. Another approach is to record what's in your DNS cache the moment it happens.  Remember, negative caching TTLs are generally very short, so this is a narrow window.  We armed our client's IT staff with a batch file that would dump the DNS cache to a txt file, and told them the moment a user reported the issue, email them the batch and have them run it immediately.  The DNS cache can be large, so dump it to a TXT file makes reviewing it easier.  The contents of our batch file was a single line:
    • ipconfig /displaydns > dnscachecontents.txt
  4. Then look through that TXT file for the entry for your server...


An entry for a DNS record that returned an IP address will look like this:
    Record Name . . . . . :
    Record Type . . . . . : 1
    Time To Live  . . . . : 8853
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . :


An entry for a DNS record that does not exist within the DNS zone, i.e. an NXDOMAIN response, will be recorded like this:
    Name does not exist.


And bingo... now just figure out why your particular DNS infrastructure is responding with this NXDOMAIN and you'll have this wrapped up in no time. 


5 0
replied on January 27, 2015

I have found that a quick first step solution for this error is to clear the user's available repositories and re-establish the link.

  1. From the Client Start page, select the affected repository
  2. Right click the mouse inside of the Available Repositories box
  3. Click Remove Selected Repository
  4. Once cleared, right click the mouse inside of the Available Repositories box
  5. Click Scan Network for Repositories
  6. Log into the appropriate repository for the user


1 0
replied on February 10, 2014

It sounds like a dns problem. When you get this error, can you ping the server from that same workstation? Does ping or nslookup return the correct current ip address for the server?

0 0
replied on February 10, 2014

I don't think it's DNS, we can still ping the server by name. We also tried writing the server directly into the host file and this has no barring on the functionality.

0 0
replied on February 10, 2014

Maybe try enabling WinHTTP tracing on the Client (Help > About Laserfiche > Tracing) to see there are any more clues revealed that way?  Could point you in the right direction.

0 0
replied on February 10, 2014

I will try it out over the next few days.

0 0
replied on February 24, 2014

I got the same thing this morning, what we did was click Attach and enter the Laserfiche server and choose the repository name.

0 0
replied on February 24, 2014

I've yet to narrow this down. Turns out there may be 2 issues as it seemingly does have something to do with DNS on some PCs where others are not so straight forward..


doing a quick ipconfig /flushdns will fix this issue some of the time. When I get tim ein the future I will do some further investigation

0 0
replied on February 11, 2014

The other option would be to try this?

0 0
replied on January 29, 2015

We are having this problem at 2 customer sites now with Laserfiche 9.2.  Intermittent connectivity issues and they lose the server name.  Reattaching works for awhile but it comes back.  It is only a few computers and not everyone within the domain.


0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.