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?
>>>
|
|
|