|
|
|
|
|
|
|
|
| Re: Dns resolution failure.. [message #3751 is a reply to message #3742] |
Wed, 14 June 2006 10:53   |
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 |
|
|
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 |
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 547 times)
|
|
|
|
| Re: Dns resolution failure.. [message #3767 is a reply to message #3764] |
Wed, 14 June 2006 22:20 |
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 #24980 is a reply to message #3768] |
Wed, 12 December 2007 17:29 |
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
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
