OpenVZ Forum


Home » Mailing lists » Users » Dns resolution failure..
Dns resolution failure.. [message #3736] Mon, 12 June 2006 23:49 Go to next message
Aaron Stewart is currently offline  Aaron Stewart
Messages: 3
Registered: June 2006
Junior Member
Hey all,

We're seeing a problem where within one particular VE on a host we can
nslookup or "host" a hostname and everything works.

But when we try running yum update or wget (even to www.google.com) we
get "Temporary failure in name resolution."

We've dug around on the lists and tried solutions posted there with no
luck (w.r.t setting forwarding on the main system, etc).

We're also seeing the following in the logs (not sure if it's a
red-herring or not):

Jun 12 15:48:19 FOO sysctl: net.ipv4.ip_forward = 0
Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
'net.ipv4.conf.default.rp_filter'
Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
'net.ipv4.conf.default.accept_source_route'
Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
'kernel.sysrq'
Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
'kernel.core_uses_pid'


I should mention that all other VE's running on the host work without a
problem.

Any ideas?
  • Attachment: aaron.vcf
    (Size: 0.28KB, Downloaded 494 times)
Re: Dns resolution failure.. [message #3737 is a reply to message #3736] Tue, 13 June 2006 09:36 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

You need to check with tcpdump in the host whether your packets go ok
from VE to host system.
Does networking work correctly from VE when IP addresses are used?

Kirill

> Hey all,
>
> We're seeing a problem where within one particular VE on a host we can
> nslookup or "host" a hostname and everything works.
>
> But when we try running yum update or wget (even to www.google.com) we
> get "Temporary failure in name resolution."
>
> We've dug around on the lists and tried solutions posted there with no
> luck (w.r.t setting forwarding on the main system, etc).
>
> We're also seeing the following in the logs (not sure if it's a
> red-herring or not):
>
> Jun 12 15:48:19 FOO sysctl: net.ipv4.ip_forward = 0
> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
> 'net.ipv4.conf.default.rp_filter'
> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
> 'net.ipv4.conf.default.accept_source_route'
> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
> 'kernel.sysrq'
> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
> 'kernel.core_uses_pid'
>
>
> I should mention that all other VE's running on the host work without a
> problem.
>
> Any ideas?
>
Re: Dns resolution failure.. [message #3742 is a reply to message #3737] Tue, 13 June 2006 18:14 Go to previous messageGo to next message
Aaron Stewart is currently offline  Aaron Stewart
Messages: 3
Registered: June 2006
Junior Member
Hey Kirill,

We've gone down that route with no results.

What's bugging me (and I can't wrap my brain around it) is that we can
ping the outside world, wget to IP addresses, and ssh into external
hosts. The only thing that seems to be failing is DNS at the
application level.. Again, nslookup and host both work without issue.

-=Aaron

Kirill Korotaev wrote:
> You need to check with tcpdump in the host whether your packets go ok
> from VE to host system.
> Does networking work correctly from VE when IP addresses are used?
>
> Kirill
>
>> Hey all,
>>
>> We're seeing a problem where within one particular VE on a host we
>> can nslookup or "host" a hostname and everything works.
>>
>> But when we try running yum update or wget (even to www.google.com)
>> we get "Temporary failure in name resolution."
>>
>> We've dug around on the lists and tried solutions posted there with
>> no luck (w.r.t setting forwarding on the main system, etc).
>>
>> We're also seeing the following in the logs (not sure if it's a
>> red-herring or not):
>>
>> Jun 12 15:48:19 FOO sysctl: net.ipv4.ip_forward = 0
>> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
>> 'net.ipv4.conf.default.rp_filter'
>> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
>> 'net.ipv4.conf.default.accept_source_route'
>> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
>> 'kernel.sysrq'
>> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
>> 'kernel.core_uses_pid'
>>
>>
>> I should mention that all other VE's running on the host work without
>> a problem.
>>
>> Any ideas?
>>
  • Attachment: aaron.vcf
    (Size: 0.28KB, Downloaded 505 times)
Re: Dns resolution failure.. [message #3746 is a reply to message #3742] Wed, 14 June 2006 09:16 Go to previous messageGo to next message
rkagan is currently offline  rkagan
Messages: 11
Registered: May 2006
Location: Moscow
Junior Member
On Tue, Jun 13, 2006 at 11:14:05AM -0700, Aaron Stewart wrote:
> What's bugging me (and I can't wrap my brain around it) is that we can ping the outside world, wget to IP addresses, and ssh into external hosts. The only thing that seems to be
> failing is DNS at the application level.. Again, nslookup and host both work without issue.

Check that you have 'dns' among the services for 'hosts' map in
/etc/nsswitch.conf, e.g.

# grep hosts /etc/nsswitch.conf
hosts: files dns

The point is that 'nslookup' and 'host' do DNS lookups (only) while the
applications use (through standard libc functions) whatever is
configured for NSS (Name Service Switch).

Roman.
Re: Dns resolution failure.. [message #3751 is a reply to message #3742] Wed, 14 June 2006 10:53 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

Hello Aaron,

> We've gone down that route with no results.
>
> What's bugging me (and I can't wrap my brain around it) is that we can
> ping the outside world, wget to IP addresses, and ssh into external
> hosts.
from VPS, correct?

> The only thing that seems to be failing is DNS at the
> application level.. Again, nslookup and host both work without issue.
does dig <some domain> works correctly?
does ping <some domain> works?

do tcpdump (both in VPS and host) and check why UDP packets from
applications DNS request fail.

Also check that you have no any firewalls in host/VPS.

I feel that there is something simple, but can't say what is wrong
yet... :)

Thanks,
Kirill

> -=Aaron
>
> Kirill Korotaev wrote:
>
>> You need to check with tcpdump in the host whether your packets go ok
>> from VE to host system.
>> Does networking work correctly from VE when IP addresses are used?
>>
>> Kirill
>>
>>> Hey all,
>>>
>>> We're seeing a problem where within one particular VE on a host we
>>> can nslookup or "host" a hostname and everything works.
>>>
>>> But when we try running yum update or wget (even to www.google.com)
>>> we get "Temporary failure in name resolution."
>>>
>>> We've dug around on the lists and tried solutions posted there with
>>> no luck (w.r.t setting forwarding on the main system, etc).
>>>
>>> We're also seeing the following in the logs (not sure if it's a
>>> red-herring or not):
>>>
>>> Jun 12 15:48:19 FOO sysctl: net.ipv4.ip_forward = 0
>>> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
>>> 'net.ipv4.conf.default.rp_filter'
>>> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
>>> 'net.ipv4.conf.default.accept_source_route'
>>> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
>>> 'kernel.sysrq'
>>> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
>>> 'kernel.core_uses_pid'
>>>
>>>
>>> I should mention that all other VE's running on the host work without
>>> a problem.
>>>
>>> Any ideas?
>>>
Re: Dns resolution failure.. [message #3754 is a reply to message #3751] Wed, 14 June 2006 12:26 Go to previous messageGo to next message
kir is currently offline  kir
Messages: 1645
Registered: August 2005
Location: Moscow, Russia
Senior Member

I suggest to turn on the dump mode and check that /etc/resolv.conf in a
VE contains the same as on the hardware node. If not, use vzctl set VEID
--nameserver x.x.x.x --save command.

Next step is to try pinging the nameserver from inside a VE.

Kirill Korotaev wrote:

> Hello Aaron,
>
>> We've gone down that route with no results.
>>
>> What's bugging me (and I can't wrap my brain around it) is that we
>> can ping the outside world, wget to IP addresses, and ssh into
>> external hosts.
>
> from VPS, correct?
>
> > The only thing that seems to be failing is DNS at the
>
>> application level.. Again, nslookup and host both work without issue.
>
> does dig <some domain> works correctly?
> does ping <some domain> works?
>
> do tcpdump (both in VPS and host) and check why UDP packets from
> applications DNS request fail.
>
> Also check that you have no any firewalls in host/VPS.
>
> I feel that there is something simple, but can't say what is wrong
> yet... :)
>
> Thanks,
> Kirill
>
>> -=Aaron
>>
>> Kirill Korotaev wrote:
>>
>>> You need to check with tcpdump in the host whether your packets go
>>> ok from VE to host system.
>>> Does networking work correctly from VE when IP addresses are used?
>>>
>>> Kirill
>>>
>>>> Hey all,
>>>>
>>>> We're seeing a problem where within one particular VE on a host we
>>>> can nslookup or "host" a hostname and everything works.
>>>>
>>>> But when we try running yum update or wget (even to
>>>> www.google.com) we get "Temporary failure in name resolution."
>>>>
>>>> We've dug around on the lists and tried solutions posted there with
>>>> no luck (w.r.t setting forwarding on the main system, etc).
>>>>
>>>> We're also seeing the following in the logs (not sure if it's a
>>>> red-herring or not):
>>>>
>>>> Jun 12 15:48:19 FOO sysctl: net.ipv4.ip_forward = 0
>>>> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
>>>> 'net.ipv4.conf.default.rp_filter'
>>>> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
>>>> 'net.ipv4.conf.default.accept_source_route'
>>>> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
>>>> 'kernel.sysrq'
>>>> Jun 12 15:48:19 FOO sysctl: error: unknown error 1 setting key
>>>> 'kernel.core_uses_pid'
>>>>
>>>>
>>>> I should mention that all other VE's running on the host work
>>>> without a problem.
>>>>
>>>> Any ideas?
>>>>
Re: Dns resolution failure.. [message #3764 is a reply to message #3746] Wed, 14 June 2006 09:25 Go to previous messageGo to next message
Aaron Stewart is currently offline  Aaron Stewart
Messages: 3
Registered: June 2006
Junior Member
Right. nsswitch is unmodified, and its set up for files dns as you have
below.

Still no resolution. I figured it's probably some issue with the system
gethostbyname() call, but I can't figure for the life of me what could
cause it.

Thanks,
-=Aaron

Roman Kagan wrote:
> On Tue, Jun 13, 2006 at 11:14:05AM -0700, Aaron Stewart wrote:
>
>> What's bugging me (and I can't wrap my brain around it) is that we can ping the outside world, wget to IP addresses, and ssh into external hosts. The only thing that seems to be
>> failing is DNS at the application level.. Again, nslookup and host both work without issue.
>>
>
> Check that you have 'dns' among the services for 'hosts' map in
> /etc/nsswitch.conf, e.g.
>
> # grep hosts /etc/nsswitch.conf
> hosts: files dns
>
> The point is that 'nslookup' and 'host' do DNS lookups (only) while the
> applications use (through standard libc functions) whatever is
> configured for NSS (Name Service Switch).
>
> Roman.
>
  • Attachment: aaron.vcf
    (Size: 0.28KB, Downloaded 500 times)
Re: Dns resolution failure.. [message #3767 is a reply to message #3764] Wed, 14 June 2006 22:20 Go to previous messageGo to next message
Jonathan is currently offline  Jonathan
Messages: 10
Registered: September 2005
Junior Member
We'd still like to know what's causing this, if anyone has a clue!

We're moving the account over to XEN 3.0 in the meantime, as we just can't
find the problem and the customer account has been down several days. ;(

I'm totally bummed. This is weirdness!

Jonathan


On 6/14/06 2:25 AM, "Aaron Stewart" <aaron@firebright.com> wrote:

> Right. nsswitch is unmodified, and its set up for files dns as you have
> below.
>
> Still no resolution. I figured it's probably some issue with the system
> gethostbyname() call, but I can't figure for the life of me what could
> cause it.
>
> Thanks,
> -=Aaron
>
> Roman Kagan wrote:
>> On Tue, Jun 13, 2006 at 11:14:05AM -0700, Aaron Stewart wrote:
>>
>>> What's bugging me (and I can't wrap my brain around it) is that we can ping
>>> the outside world, wget to IP addresses, and ssh into external hosts. The
>>> only thing that seems to be
>>> failing is DNS at the application level.. Again, nslookup and host both work
>>> without issue.
>>>
>>
>> Check that you have 'dns' among the services for 'hosts' map in
>> /etc/nsswitch.conf, e.g.
>>
>> # grep hosts /etc/nsswitch.conf
>> hosts: files dns
>>
>> The point is that 'nslookup' and 'host' do DNS lookups (only) while the
>> applications use (through standard libc functions) whatever is
>> configured for NSS (Name Service Switch).
>>
>> Roman.
>>
>
--
Re: Dns resolution failure.. [message #3768 is a reply to message #3754] Wed, 14 June 2006 17:26 Go to previous messageGo to next message
Jonathan is currently offline  Jonathan
Messages: 10
Registered: September 2005
Junior Member
Hey everyone:

Thanks for the suggestions below. I tried both of them, but neither helped
(we had tried both before). Just to show you, here is the command line test
for them:

[root@tamarancho ~]# vzctl set 12002 --nameserver 216.218.131.2 --save
File resolv.conf was modified
Saved parameters for VPS 12002
[root@tamarancho ~]# vzctl set 12002 --nameserver 216.218.132.2 --save
File resolv.conf was modified
Saved parameters for VPS 12002
[root@tamarancho ~]# vzctl set 12002 --nameserver 216.218.130.2 --save
File resolv.conf was modified
Saved parameters for VPS 12002
[root@tamarancho ~]# vzctl enter 12002
entered into VPS 12002
bash-3.00# ping google.com
c
bash-3.00# traceroute yahoo.com
traceroute: unknown host yahoo.com
bash-3.00# wget google.com
--10:19:52-- http://google.com/
=> `index.html'
Resolving google.com... failed: Temporary failure in name resolution.
bash-3.00# grep hosts /etc/nsswitch.conf
#hosts: db files ldap nis dns
hosts: files dns

I'm using he.net's name servers, which should work fine. This doesn't
appear to be a "standard error" or we would have fixed it by now. ;-)

Any other suggestions?

Jonathan


On 6/14/06 5:26 AM, "Kir Kolyshkin" <kir@openvz.org> wrote:

> I suggest to turn on the dump mode and check that /etc/resolv.conf in a
> VE contains the same as on the hardware node. If not, use vzctl set VEID
> --nameserver x.x.x.x --save command.
>
> Next step is to try pinging the nameserver from inside a VE.

# grep hosts /etc/nsswitch.conf
hosts: files dns
Re: Dns resolution failure.. [message #3770 is a reply to message #3764] Thu, 15 June 2006 07:56 Go to previous messageGo to next message
rkagan is currently offline  rkagan
Messages: 11
Registered: May 2006
Location: Moscow
Junior Member
On Wed, Jun 14, 2006 at 02:25:22AM -0700, Aaron Stewart wrote:
> Still no resolution. I figured it's probably some issue with the
> system gethostbyname() call, but I can't figure for the life of me
> what could cause it.

No, the message you receive is from getaddrinfo(). Do you by any chance
have IPv6 enabled for this VPS?

Can you please try and run

# getent ahostsv4 www.google.com

and

# getent ahostsv6 www.google.com

? Also, should any of the above fail, can you please run it through
strace -v and post the trace?

Roman.
Re: Dns resolution failure.. [message #24980 is a reply to message #3768] Wed, 12 December 2007 17:29 Go to previous message
Cliff Wells is currently offline  Cliff Wells
Messages: 30
Registered: June 2006
Member
On Wed, 2006-06-14 at 10:26 -0700, Jonathan Lambert wrote:

> Any other suggestions?

I hate to ask the obvious, but are there any failures
in /proc/user_beancounters?  I was getting sporadic DNS failures when
tcprcvbuf was too low (I could ping, but yum would consistently fail).

Cliff
Previous Topic: Reasonable expectations
Next Topic: Network configuration
Goto Forum:
  


Current Time: Tue Mar 19 06:05:32 GMT 2024

Total time taken to generate the page: 0.02444 seconds