Thanks to the educated response to all of you.
The Google nameservers got me a temporary solution and after a while they
have fixed their own nameservers.
regards
Gabor
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mail
I'm not sure what you are trying to achieve here - PTR records and A
records are completely separate entities living under different domains.
Both of them should be maintained separately (there are probably tons of
tools to keep them in sync if you like, but from DNS' perspective there is
no relati
Try wireshark/tcpdump to see which DNS queries goes to which server and
wheter DNS server replies back .
You can also try dig, nslookup and couple of other cmoomd line tools form:
http://serverfault.com/questions/7056/whats-the-reverse-dns-command-line-utility/7088#7088
From: Linux-il [mailt
Hi Linuxers,
I am jumping on today's DNS thread,
My Linux Debian uses DNS service some Windows server.
Linux resolver gets back IP address ( type A and AAA records), but fail to
get back PTR record.
( I am observing DNS queries and failures with Wireshark)
This cause ldap to use address in
"Google unicast public DNS servers"
s/unicast/anycast/, I keep forgetting that term.
On 22 March 2015 at 22:28, Amos Shapira wrote:
> 1. Sounds like the ip's in your resolv.conf are wrong. Where does the
> server get them from? ip's 8.8.8.8 and 8.8.4.4 are the Google unicast
> public DNS server
On 22/03/15 12:50, Gabor Szabo wrote:
> Hi,
> It takes ages to ssh to it, once I got to the machine I can ping IP
> addresses from it, but I cannot ping anything with a hostname.
>
Add to the sshd_config file the following line:
UseDNS no
This will speed up the ssh connection regardless of whethe
1. Sounds like the ip's in your resolv.conf are wrong. Where does the
server get them from? ip's 8.8.8.8 and 8.8.4.4 are the Google unicast
public DNS servers. They are reliable but it's not optimal for a server to
have to reach out to them on every query.
2. The ssh login is possibly slow because
They basically told you "use google dns servers instead/in addition to
ours", could be they were suffering problems with their DNS or they
changed IPs...
2015-03-22 13:13 GMT+02:00 Gabor Szabo :
> I tried that, and although I am not sure what should I look for in there it
> seems to be claiming
>
I tried that, and although I am not sure what should I look for in there it
seems to be claiming
rt_sigsuspend([];; connection timed out; no servers could be reached
I tried to telnet 72.14.179.5 53 (one of the DNS servers) and that did not
got a response.
Anyway, Linode support told me to ad
run this on the host:
strace host www.google.com
and scan the output.
more efficient then guessing.
--guy
On 03/22/2015 12:50 PM, Gabor Szabo wrote:
Hi,
I run an Ubuntu based VPS on Linode.
I few hours ago the machine stopped resolving hostnames.
I think it was after an "aptitude safe-upgr
Hi,
I run an Ubuntu based VPS on Linode.
I few hours ago the machine stopped resolving hostnames.
I think it was after an "aptitude safe-upgrade" and a reboot, but I am not
sure. Maybe was like this earlier.
It takes ages to ssh to it, once I got to the machine I can ping IP
addresses from it, bu
On Sun, Mar 22, 2015 at 11:10 AM, Roman Ovseitsev wrote:
> Thanks everyone! That explains it then.
>
> It interesting how the cached version is actually slower to download than
> the non-cached.
> I haven't noticed the speed difference prior to Michael mentioning it, but
> now after some random t
Thanks everyone! That explains it then.
It interesting how the cached version is actually slower to download than
the non-cached.
I haven't noticed the speed difference prior to Michael mentioning it, but
now after some random tests the behaviour seems to be consistent with other
sites as well. To
13 matches
Mail list logo
