DNS lookup failed on host - Error

Need help configuring your VPN? Just post here and you'll get that help.

Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech

Forum rules
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
Post Reply
winter.tal
OpenVpn Newbie
Posts: 1
Joined: Tue Nov 01, 2016 7:03 pm

DNS lookup failed on host - Error

Post by winter.tal » Tue Nov 01, 2016 7:08 pm

Hey,

I have been trying to log in to my VPN from mac, and been getting the following error:
Unexpected error: DNS lookup failed on host ' ' [Errno 8] nodename nor servname provided, or not known

Can anyone advise ?

TinCanTech
OpenVPN Protagonist
Posts: 11137
Joined: Fri Jun 03, 2016 1:17 pm

Re: DNS lookup failed on host - Error

Post by TinCanTech » Tue Nov 01, 2016 8:29 pm

winter.tal wrote:nodename nor servname provided, or not known
Check your server name.

john.skinner@iostudio.com
OpenVpn Newbie
Posts: 1
Joined: Tue Feb 17, 2015 10:33 pm

Re: DNS lookup failed on host - Error

Post by john.skinner@iostudio.com » Fri Nov 18, 2016 4:10 pm

I would assume TinCanTech's answer didn't help, as we are having issues with this among our users.

OpenVPN support has informed me that they have seen issues reported from others, with their current Mac OpenVPN Connect client for Mac OS X and Comcast DNS. You can get around this issue if you do not use Comcast DNS on your router or computer. OpenVPN support has had my ticket about this unresolved since October 3rd.

The strange issue is, the computer that the OpenVPN Connect client is installed on has no problem resolving DNS to connect to the OpenVPN Access Server's client web interface. But when you start the OpenVPN Connect client and attempt to connect to the OpenVPN Access Server, the client has DNS errors resolving the DNS to the OpenVPN Access Server. There is no logs on the Access Server for this because the client can not even resolve the Access Servers address. It seems like something is wrong with the OpenVPN Connect client if it can not resolve the DNS correctly.
Frustrated and puzzled.

TinCanTech
OpenVPN Protagonist
Posts: 11137
Joined: Fri Jun 03, 2016 1:17 pm

Re: DNS lookup failed on host - Error

Post by TinCanTech » Fri Nov 18, 2016 6:58 pm

john.skinner@iostudio.com wrote:OpenVPN support has informed me that they have seen issues reported from others, with their current Mac OpenVPN Connect client for Mac OS X and Comcast DNS. You can get around this issue if you do not use Comcast DNS on your router or computer. OpenVPN support has had my ticket about this unresolved since October 3rd.
If you think this is a bug with Openvpn-Connect then should report it on the bug trac, where you can also follow any progress.

If you think it is a bug with Comcast DNS then please report to them .. and let us know if you get a ticket ID that we can also link to and follow.

zedd45
OpenVpn Newbie
Posts: 1
Joined: Wed Jan 04, 2017 4:17 pm

Re: DNS lookup failed on host - Error

Post by zedd45 » Wed Jan 04, 2017 4:21 pm

I encountered this issue after upgrading to Mac OSX Sierra.

My coworkers did not encounter this issue. Two things to note here that may have contributed to this problem, but which I was unable to confirm where the root cause of the issue:
1. my DNS was provided through AT&T / default ISP settings
2. The DNS for AT&T used an IP6 address


I switched to Google DNS using the following tutorial, and I was able to login again:
https://developers.google.com/speed/pub ... docs/using

jwilmot
OpenVpn Newbie
Posts: 1
Joined: Thu Jan 12, 2017 10:03 pm

Re: DNS lookup failed on host - Error

Post by jwilmot » Thu Jan 12, 2017 10:05 pm

Just to confirm, the workaround provided by zedd45 (using google's public DNS servers) worked for me. I was using comcast's DNS previously and saw this issue after I upgraded to OSX Sierra.

fuzzymazoid
OpenVpn Newbie
Posts: 1
Joined: Tue Feb 28, 2017 4:06 pm

Re: DNS lookup failed on host - Error

Post by fuzzymazoid » Tue Feb 28, 2017 4:11 pm

I just had a user run into the same problem. He just got a new Mac at home, and today was his first day connecting to the office VPN. Symptoms are exactly the same as above: latest Mac OS, Comcast DNS, "Unexpected error: DNS lookup failed on host xxxxxxx: [Errno 8] nodename nor servname provided, or not known"

We had him switch from Comcast DNS servers to Google DNS servers and he was able to connect without issue.

Seems unlikely that Comcast's DNS is wrong somehow. Is there a bug reported for OpenVPN Connect that we can track?

tmacpherson
OpenVpn Newbie
Posts: 1
Joined: Thu Mar 09, 2017 9:45 pm

Re: DNS lookup failed on host - Error

Post by tmacpherson » Thu Mar 09, 2017 9:52 pm

We have the same issue while on Verizonwireless network. On our MiFi's we cannot use the dns name for our vpn. The work around is to use the ipaddress, just do an nslookup on your dns name for example nslookup myvpndnsname.mydomain.com and that will give you the public IP of your VPN appliance. Hopefully this will be rectified quickly. i have comcast at home but I would never use their DNS in my router, always use a public DNS

SomeGuy
OpenVPN Power User
Posts: 64
Joined: Sat Dec 17, 2016 1:58 am

Re: DNS lookup failed on host - Error

Post by SomeGuy » Thu Mar 09, 2017 10:50 pm

Two suggestions related to this.

* IPv4 vs IPv6, DNS and resolver affinity: If running a with an openvpn client configuration that has a "server" line with a FQDN (fully-qualified-domain-name) that can resolve to IPv6 and IPv4 addresses, check to see if the OpenVPN server you are trying to connect to provides service for IPv4 and IPv6 clients. Many resolvers in OS have an affinity to resolve DNS AAAA records over A or CNAME, and will tend to favor IPv6 addresses being resolved for a name to IP if there are both IPv4 and IPv6 addresses available.

* Domains that support DNSSec : many ISP are moving to apply rules of DNSSec with name-to-IP lookups n the DNS Servers *they* run for their customers. If another domain name is poorly configured with DNSSec, or has expired keys, properly enforcing DNS Servers completing your query against DNS that have DNSSec configured will NOT pass on any IP addresses to their customers because the results can't be validated. Some ISP have experimented with partial DNSSec support, or a kludgy redirection to a web page that tells the *web* client that the attempt to resolve the name to an IP resulted in DNSSec problems. Such a web page would not be visible to "you" if your OpenVPN client is being redirected to a different IP than what is expected.

I know Comcast was early to experiment with DNSSec and adopt use of IPv6. Would anyone that encounters the problem described in this thread please check to see if any of these above items are the source of troubles? Some suggested methods to test are listed below:

DNS lookups, IPv4 vs IPv6 or some other DNS issue: If you have a linux shell with "dig" installed...

In these examples, I am using "8.8.8.8" (google's public DNS Server's IPv4 IP address) and 2001:4860:4860::8888 (google's public DNS Server's IPv6 IP address.)

The "-4" says, use my IPv4 IP address and connect to the IPv4 address of the server (useful if you use names instead of IP addresses for which DNS Server you want to use) and the "-6" says use an IPv6 IP address on my machine to talk to a DNS running with an IPv6 address. (Using an IPv4 address for DNS after the "@" already requests IPv4 implicitly, but including in case you replace the value after the "@" with a name.)

The "A" is conventionally a record for name to IPv4 address.
The "AAAA" is a record for name to IPv6 address.

Query Google's IPv6 DNS Server, and ask for an AAAA record (IPv6 address, if any) for the host name "www.google.com":

Code: Select all

$ dig +short @2001:4860:4860::8888 -6 -t AAAA www.google.com
2607:f8b0:4005:807::2004
Query Google's IPv4 DNS Server, and ask for an A record (IPv4 address, if any) for the host name "www.google.com":

Code: Select all

dig +short @8.8.8.8 -4 -t A www.google.com
216.58.195.68
An example using a case where CNAME record is used instead of A record:

Code: Select all

dig +short @8.8.8.8 -4 -t CNAME www.microsoft.com
www.microsoft.com-c-2.edgekey.net.
In this case, a CNAME resolves to a name, which you could then resolve, and follow until you find the IP address.

If any of the intermediate CNAME in the chain to your final IP address use DNSSec, then those domains may also need to be investigated for proper configuration.

Replace "www.google.com" or "www.microsoft.com" with the fully-qualified-domain-name in your client's "server ...." config line. See what results you find.

Next, try the same against your ISP's provided DNS servers and replace the valued after the "@" with your ISP's DNS Server IP. Do you get the same results?

If the results do not match what you see from google's DNS, how are they different? Does one resolve to an IP while the other does not? Do they resolve to different IP? If different, who owns the netblock of the IP address that is an unexpected result?


Next, tools for DNSSec checks... less likely as a cause, but possible:

Online, here 2 useful tools for this:
* http://dnsviz.net/ (A cached example with google.com: http://dnsviz.net/d/google.com/dnssec/ and an example for comcast.net: http://dnsviz.net/d/comcast.net/dnssec/ )
* http://dnssec-debugger.verisignlabs.com/ (An example with google.com: http://dnssec-debugger.verisignlabs.com/google.com and an example with comcast.net: http://dnssec-debugger.verisignlabs.com/comcast.net )

If your domain uses delegation with sub-domains, then you may need to check your domain name, *and* sub-domains for proper DNSSec configurations, all the way up to, but not including a hostname for each sub-domain delegation with DNSSec.

For organizations that run things other than VPN, they probably have a HOSTname.domain.TLD for their client's "server ..." config lines. Dedicated VPN service providers may not. When you complete your DNSSec checks you want to stop off the "HOSTname" (of any) from the "server ..." config line when submitting it to those two DNSSec example tools. (So, if google had an openvpn server and client config lines that looked like "server openvpn.google.com" then the domain to check with these tools would be "google.com" and almost certainly not "openvpn.google.com")

If you find that CNAME were uses to other names in the top step, you will want to check the DNSSec status of those domains and/or sub-domains until you finally reach an IP address.

If you find that the problems you are encountering are not related to these two issues (IPv6 address resolved vs IPv4 address resolved, OR DNSSec validation/configuration issues) please follow-up saying so.

If you find that one or both are the source of trouble, please also post that information.

Knowing what the source of the problem is would help to know if this is a bug or not, and if not, how to fix it or side-step it.

I have not had any problems with client resolution on Comcast or Verizon, or Sprint, or AT&T when I used them, but I use properly configured domains using DNSSec for my domains to validate hosts, support dual-stack IPv4/IPv6 with service for both for each server name and port.

teec
OpenVpn Newbie
Posts: 1
Joined: Tue May 09, 2017 12:59 pm

Re: DNS lookup failed on host - Error

Post by teec » Tue May 09, 2017 1:01 pm

@john.skinner@iostudio.com

Have you had any updates on this issue? It prevents me from accessing my work VPN from home. Yes, the Google DNS change helps, but then screws up my DNS while at work so I don't want to have to keep switching back and forth. This issue only arose for me after upgrading to OSX Sierra..

maxigs
OpenVpn Newbie
Posts: 1
Joined: Wed May 17, 2017 8:51 am

Re: DNS lookup failed on host - Error

Post by maxigs » Wed May 17, 2017 8:54 am

Another one here. I upgraded to sierra yesterday and have the same issue now trying to log on the company VPN.

I "fixed" it for now by adding the hostname to my /etc/hosts file to skip resolving it. This seems to work for now, not ideal but the IP rarely changes so i can live with it.

vcardillo
OpenVpn Newbie
Posts: 1
Joined: Mon May 22, 2017 9:00 pm

Re: DNS lookup failed on host - Error

Post by vcardillo » Mon May 22, 2017 9:03 pm

Same problem, with the Access Server product.

Gushi
OpenVpn Newbie
Posts: 2
Joined: Wed Jul 19, 2017 12:38 am

Re: DNS lookup failed on host - Error

Post by Gushi » Wed Jul 19, 2017 12:41 am

No, and we're using the appliance with a paid license (which means, in theory, that our issues should get some kind of support).

I've captured packets of my mac doing a DNS lookup and explicitly requesting a AAAA record to my local DNS server. The connection then fails, instead of falling back to asking for an A record.

lawrence.henry
OpenVpn Newbie
Posts: 1
Joined: Fri Sep 01, 2017 1:11 pm

Re: DNS lookup failed on host - Error

Post by lawrence.henry » Fri Sep 01, 2017 1:15 pm

So, following this general thread of advice -- we were experiencing this issue with some of our Mac users on certain ISPs. We disabled ipv6 on the Macs having the problem and it "fixed" the issue.

See notes below to disable and re-enable ipv6:

Turning off IPv6 support for ethernet:
networksetup -setv6off Ethernet

Disabling IPv6 for wireless:
networksetup -setv6off Wi-Fi

You can also combine both of those commands into a single string to disable both wireless and ethernet, just use the following syntax:

networksetup -setv6off Ethernet && networksetup -setv6off Wi-Fi

Be sure to enter that string onto a single line to issue the command properly.

Re-Enabling IPv6 for Wi-Fi & Ethernet in OS X

Of course, reversing the above change is also possible, and you can re-enable IPV6 support with the following command strings entered into the terminal:

networksetup -setv6automatic Wi-Fi
networksetup -setv6automatic Ethernet

You can also place this into a single command to re-enable IPv6 for Wi-Fi and ethernet like so:

networksetup -setv6automatic Wi-Fi && networksetup -setv6automatic Ethernet


-Larry

--------------


SomeGuy wrote:Two suggestions related to this.

* IPv4 vs IPv6, DNS and resolver affinity: If running a with an openvpn client configuration that has a "server" line with a FQDN (fully-qualified-domain-name) that can resolve to IPv6 and IPv4 addresses, check to see if the OpenVPN server you are trying to connect to provides service for IPv4 and IPv6 clients. Many resolvers in OS have an affinity to resolve DNS AAAA records over A or CNAME, and will tend to favor IPv6 addresses being resolved for a name to IP if there are both IPv4 and IPv6 addresses available.

* Domains that support DNSSec : many ISP are moving to apply rules of DNSSec with name-to-IP lookups n the DNS Servers *they* run for their customers. If another domain name is poorly configured with DNSSec, or has expired keys, properly enforcing DNS Servers completing your query against DNS that have DNSSec configured will NOT pass on any IP addresses to their customers because the results can't be validated. Some ISP have experimented with partial DNSSec support, or a kludgy redirection to a web page that tells the *web* client that the attempt to resolve the name to an IP resulted in DNSSec problems. Such a web page would not be visible to "you" if your OpenVPN client is being redirected to a different IP than what is expected.

I know Comcast was early to experiment with DNSSec and adopt use of IPv6. Would anyone that encounters the problem described in this thread please check to see if any of these above items are the source of troubles? Some suggested methods to test are listed below:

DNS lookups, IPv4 vs IPv6 or some other DNS issue: If you have a linux shell with "dig" installed...

In these examples, I am using "8.8.8.8" (google's public DNS Server's IPv4 IP address) and 2001:4860:4860::8888 (google's public DNS Server's IPv6 IP address.)

The "-4" says, use my IPv4 IP address and connect to the IPv4 address of the server (useful if you use names instead of IP addresses for which DNS Server you want to use) and the "-6" says use an IPv6 IP address on my machine to talk to a DNS running with an IPv6 address. (Using an IPv4 address for DNS after the "@" already requests IPv4 implicitly, but including in case you replace the value after the "@" with a name.)

The "A" is conventionally a record for name to IPv4 address.
The "AAAA" is a record for name to IPv6 address.

Query Google's IPv6 DNS Server, and ask for an AAAA record (IPv6 address, if any) for the host name "www.google.com":

Code: Select all

$ dig +short @2001:4860:4860::8888 -6 -t AAAA www.google.com
2607:f8b0:4005:807::2004
Query Google's IPv4 DNS Server, and ask for an A record (IPv4 address, if any) for the host name "www.google.com":

Code: Select all

dig +short @8.8.8.8 -4 -t A www.google.com
216.58.195.68
An example using a case where CNAME record is used instead of A record:

Code: Select all

dig +short @8.8.8.8 -4 -t CNAME www.microsoft.com
www.microsoft.com-c-2.edgekey.net.
In this case, a CNAME resolves to a name, which you could then resolve, and follow until you find the IP address.

If any of the intermediate CNAME in the chain to your final IP address use DNSSec, then those domains may also need to be investigated for proper configuration.

Replace "www.google.com" or "www.microsoft.com" with the fully-qualified-domain-name in your client's "server ...." config line. See what results you find.

Next, try the same against your ISP's provided DNS servers and replace the valued after the "@" with your ISP's DNS Server IP. Do you get the same results?

If the results do not match what you see from google's DNS, how are they different? Does one resolve to an IP while the other does not? Do they resolve to different IP? If different, who owns the netblock of the IP address that is an unexpected result?


Next, tools for DNSSec checks... less likely as a cause, but possible:

Online, here 2 useful tools for this:
* http://dnsviz.net/ (A cached example with google.com: http://dnsviz.net/d/google.com/dnssec/ and an example for comcast.net: http://dnsviz.net/d/comcast.net/dnssec/ )
* http://dnssec-debugger.verisignlabs.com/ (An example with google.com: http://dnssec-debugger.verisignlabs.com/google.com and an example with comcast.net: http://dnssec-debugger.verisignlabs.com/comcast.net )

If your domain uses delegation with sub-domains, then you may need to check your domain name, *and* sub-domains for proper DNSSec configurations, all the way up to, but not including a hostname for each sub-domain delegation with DNSSec.

For organizations that run things other than VPN, they probably have a HOSTname.domain.TLD for their client's "server ..." config lines. Dedicated VPN service providers may not. When you complete your DNSSec checks you want to stop off the "HOSTname" (of any) from the "server ..." config line when submitting it to those two DNSSec example tools. (So, if google had an openvpn server and client config lines that looked like "server openvpn.google.com" then the domain to check with these tools would be "google.com" and almost certainly not "openvpn.google.com")

If you find that CNAME were uses to other names in the top step, you will want to check the DNSSec status of those domains and/or sub-domains until you finally reach an IP address.

If you find that the problems you are encountering are not related to these two issues (IPv6 address resolved vs IPv4 address resolved, OR DNSSec validation/configuration issues) please follow-up saying so.

If you find that one or both are the source of trouble, please also post that information.

Knowing what the source of the problem is would help to know if this is a bug or not, and if not, how to fix it or side-step it.

I have not had any problems with client resolution on Comcast or Verizon, or Sprint, or AT&T when I used them, but I use properly configured domains using DNSSec for my domains to validate hosts, support dual-stack IPv4/IPv6 with service for both for each server name and port.

jlightfoot
OpenVpn Newbie
Posts: 1
Joined: Fri Nov 03, 2017 6:34 pm

Re: DNS lookup failed on host - Error

Post by jlightfoot » Fri Nov 03, 2017 8:16 pm

I had this problem also, but I was already using Google DNS. I believe I figured out why this is happening.

The problem occurs when you use ipv6 for your DNS lookup, and DNS returns an A record (i.e. ipv4 address). In my original DNS Server list in Network Preferences, I had 2001:4860:4860::8888 and 2001:4860:4860::8844 (Google's public ipv6 DNS) as my first two DNS servers, then 8.8.8.8 and 8.8.4.4 (Google's public ipv4 DNS). When I switched the DNS search order so the ipv4 DNS servers were first, OpenVPN worked fine with no issues. When I reverse the order so the ipv6 DNS servers are first, I get DNS Lookup Failed on Host, [Errno 8]. My vpn server only has an ipv4 address, but looking up ipv4 addresses via an ipv6 call to DNS is a valid use case. This also explains why it's happening to folks on Comcast, since Comcast has native ipv6 for its customers, and why switching to the ipv4 Google DNS fixes it for them.

Post Reply