Re: Server stopped DNS name resolution

[Gabor Szabo]

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/mailman/listinfo/linux-il

Re: HOW to prevent DNS resolver from going into revert lookup (record of PTR type)?

[Amos Shapira]

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 relation between them).

If you want to "prevent reverse lookup" then you should tell the client not
to do this.

On 22 March 2015 at 22:31, Lev Olshvang  wrote:

>  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 instead of  host name in  authentication
> realm and fail.
>
> When I add address –hostname pairs in /etc/hosts,  ldap succeeds. (it uses
> name in the realm claim)
>
>
>
>
>
>
>
> I did not yet find a way to change nsswitch.conf to some resolver that
> prevents reverse lookup,
>
> Please give me some ideas if it is possible.
>
>
>
>
>
> Lev.
>
> ___
> Linux-il mailing list
> Linux-il@cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>


-- 

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

RE: Server stopped DNS name resolution

[Lev Olshvang]

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 [mailto:linux-il-boun...@cs.huji.ac.il] On Behalf Of Gabor Szabo
Sent: Sunday, March 22, 2015 1:14 PM
To: guy keren
Cc: linux-il
Subject: Re: Server stopped DNS name resolution

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 add this to the resolve.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

and that seemed to do the trick.

Gabor

On Sun, Mar 22, 2015 at 1:00 PM, guy keren 
mailto:guy.choo.ke...@gmail.com>> wrote:

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-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, but I cannot ping anything with a hostname.

this is what I have in resolv.conf

# cat /etc/resolv.conf

domain members.linode.com 

search members.linode.com 

nameserver 72.14.179.5

nameserver 72.14.188.5

options rotate


I tried to replace the nameservers with others that are listed in
another of my servers, but that did not make a change.

How can I track down what has the server stopped resolving hostnames?

Accessing the server via HTTP work as expected.

Gabor

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

HOW to prevent DNS resolver from going into revert lookup (record of PTR type)?

[Lev Olshvang]

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 instead of  host name in  authentication realm 
and fail.
When I add address -hostname pairs in /etc/hosts,  ldap succeeds. (it uses name 
in the realm claim)



I did not yet find a way to change nsswitch.conf to some resolver that prevents 
reverse lookup,
Please give me some ideas if it is possible.


Lev.
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: Server stopped DNS name resolution

[Amos Shapira]

"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 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 the ssh server is configured to
> try to reverse-resolve the incoming client ip address for logging. Look for
> "UseDNS" in your SERVER config (/etc/sshd_config). The default is usually
> "no" but perhaps in your case it's on.
>
> 3. Telnet is not a good indicator of reachability of DNS servers, DNS is
> UDP based and usually even the TCP port 53 is blocked because no one is
> supposed to have to access it. On the other hand, traceroute (yes, good old
> traceroute, as opposed to ping and tcptraceroute) uses UDP packets and you
> can tell it to use port 53 as destination so perhaps try that (again - pass
> "-n" flag to it to stop it from failing to reverse-resolve the ip address
> of each response).
>
> Good luck.
>
> On 22 March 2015 at 22:13, Gabor Szabo  wrote:
>
>> 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 add this to the resolve.conf
>>
>> nameserver 8.8.8.8
>>
>> nameserver 8.8.4.4
>>
>> and that seemed to do the trick.
>>
>> Gabor
>>
>> On Sun, Mar 22, 2015 at 1:00 PM, guy keren 
>> wrote:
>>
>>>
>>> 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-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, but I cannot ping anything with a hostname.

 this is what I have in resolv.conf

 # cat /etc/resolv.conf

 domain members.linode.com 

 search members.linode.com 

 nameserver 72.14.179.5

 nameserver 72.14.188.5

 options rotate


 I tried to replace the nameservers with others that are listed in
 another of my servers, but that did not make a change.

 How can I track down what has the server stopped resolving hostnames?

 Accessing the server via HTTP work as expected.

 Gabor



>> ___
>> Linux-il mailing list
>> Linux-il@cs.huji.ac.il
>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>
>>
>
>
> --
> 
>



-- 

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: Server stopped DNS name resolution

[Shachar Shemesh]

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 whether DNS is
resolving properly.

In theory, there is a reason ssh requires reverse DNS lookup. I never
managed to find out what it was (except making the logs more pretty,
which is a very small reward for such a huge price to pay).

Shachar
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: Server stopped DNS name resolution

[Amos Shapira]

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 the ssh server is configured to
try to reverse-resolve the incoming client ip address for logging. Look for
"UseDNS" in your SERVER config (/etc/sshd_config). The default is usually
"no" but perhaps in your case it's on.

3. Telnet is not a good indicator of reachability of DNS servers, DNS is
UDP based and usually even the TCP port 53 is blocked because no one is
supposed to have to access it. On the other hand, traceroute (yes, good old
traceroute, as opposed to ping and tcptraceroute) uses UDP packets and you
can tell it to use port 53 as destination so perhaps try that (again - pass
"-n" flag to it to stop it from failing to reverse-resolve the ip address
of each response).

Good luck.

On 22 March 2015 at 22:13, Gabor Szabo  wrote:

> 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 add this to the resolve.conf
>
> nameserver 8.8.8.8
>
> nameserver 8.8.4.4
>
> and that seemed to do the trick.
>
> Gabor
>
> On Sun, Mar 22, 2015 at 1:00 PM, guy keren 
> wrote:
>
>>
>> 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-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, but I cannot ping anything with a hostname.
>>>
>>> this is what I have in resolv.conf
>>>
>>> # cat /etc/resolv.conf
>>>
>>> domain members.linode.com 
>>>
>>> search members.linode.com 
>>>
>>> nameserver 72.14.179.5
>>>
>>> nameserver 72.14.188.5
>>>
>>> options rotate
>>>
>>>
>>> I tried to replace the nameservers with others that are listed in
>>> another of my servers, but that did not make a change.
>>>
>>> How can I track down what has the server stopped resolving hostnames?
>>>
>>> Accessing the server via HTTP work as expected.
>>>
>>> Gabor
>>>
>>>
>>>
> ___
> Linux-il mailing list
> Linux-il@cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
>


-- 

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: Server stopped DNS name resolution

[E.S. Rosenberg]

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
>
> 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 add this to the resolve.conf
>
> nameserver 8.8.8.8
>
> nameserver 8.8.4.4
>
>
> and that seemed to do the trick.
>
> Gabor
>
> On Sun, Mar 22, 2015 at 1:00 PM, guy keren  wrote:
>>
>>
>> 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-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, but I cannot ping anything with a hostname.
>>>
>>> this is what I have in resolv.conf
>>>
>>> # cat /etc/resolv.conf
>>>
>>> domain members.linode.com 
>>>
>>> search members.linode.com 
>>>
>>> nameserver 72.14.179.5
>>>
>>> nameserver 72.14.188.5
>>>
>>> options rotate
>>>
>>>
>>> I tried to replace the nameservers with others that are listed in
>>> another of my servers, but that did not make a change.
>>>
>>> How can I track down what has the server stopped resolving hostnames?
>>>
>>> Accessing the server via HTTP work as expected.
>>>
>>> Gabor
>>>
>>>
>
> ___
> Linux-il mailing list
> Linux-il@cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>

___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: Server stopped DNS name resolution

[Gabor Szabo]

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 add this to the resolve.conf

nameserver 8.8.8.8

nameserver 8.8.4.4

and that seemed to do the trick.

Gabor

On Sun, Mar 22, 2015 at 1:00 PM, guy keren  wrote:

>
> 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-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, but I cannot ping anything with a hostname.
>>
>> this is what I have in resolv.conf
>>
>> # cat /etc/resolv.conf
>>
>> domain members.linode.com 
>>
>> search members.linode.com 
>>
>> nameserver 72.14.179.5
>>
>> nameserver 72.14.188.5
>>
>> options rotate
>>
>>
>> I tried to replace the nameservers with others that are listed in
>> another of my servers, but that did not make a change.
>>
>> How can I track down what has the server stopped resolving hostnames?
>>
>> Accessing the server via HTTP work as expected.
>>
>> Gabor
>>
>>
>>
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: Server stopped DNS name resolution

[guy keren]

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-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, but I cannot ping anything with a hostname.

this is what I have in resolv.conf

# cat /etc/resolv.conf

domain members.linode.com 

search members.linode.com 

nameserver 72.14.179.5

nameserver 72.14.188.5

options rotate


I tried to replace the nameservers with others that are listed in
another of my servers, but that did not make a change.

How can I track down what has the server stopped resolving hostnames?

Accessing the server via HTTP work as expected.

Gabor







___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il




___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Server stopped DNS name resolution

[Gabor Szabo]

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, but I cannot ping anything with a hostname.

this is what I have in resolv.conf

# cat /etc/resolv.conf

domain members.linode.com

search members.linode.com

nameserver 72.14.179.5

nameserver 72.14.188.5

options rotate


I tried to replace the nameservers with others that are listed in another
of my servers, but that did not make a change.

How can I track down what has the server stopped resolving hostnames?

Accessing the server via HTTP work as expected.

Gabor
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: Something is injecting malware into my HTTP traffic

[shimi]

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 tests the behaviour seems to be consistent with other
> sites as well. Too bad not everyone provides secure versions...
>
>
Not too surprising. Nodejs uses Joyent as a provider. Likely they have
ample bandwidth capacity and common-use objects (and I am guessing the main
downloadables of latest versions are THE most commonly downloaded file from
NodeJS's servers) which are likely in RAM cache of the server. Compare with
an Israeli ISP that would try to squeeze any cent it can when utilizing
their international links (which is why I left them) and just put
everything on some huge cache machine, likely with not-so-fast-disks (i.e.
disks with notiacable seek time, i.e. not SSDs) because they're trying to
save money, remember, and the fact that while 'all the cool kids use
node.js', comparing to the rest of your ISP customers, it is likely not a
popular choice as compared to things like Torrent sites, etc, so likely not
in RAM cache, so it must load from a busy disk, and... there you have it :)

Your solution is to switch ISP, so they'll learn not to mess with their
customers.
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

Re: Something is injecting malware into my HTTP traffic

[Roman Ovseitsev]

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. Too bad not everyone provides secure versions...


On Sat, Mar 21, 2015 at 10:44 PM, Amos Shapira 
wrote:

> So there might be your answer - I guess "nv" stands for "netvision" - give
> them the URL and ask them to clear the cache for it.
>
> On 22 March 2015 at 05:56, Michael Tewner  wrote:
>
>> I'm seeing the same thing, that is, the downloaded files start to differ
>> at byte #4101
>>
>>- The HTTPS version downloaded quite fast on my 5Mbps connection. The
>>HTTP one is taking forever, quite literally; it's "stalled"
>>- I've tried adding "Cache-Control: no-cache" and "Pragma: no-cache",
>>but still getting the alternate file.
>>
>> tcptraceroute shows that the HTTP is most probably being cached; First
>> using HTTP, then using HTTPS:
>>
>> MacBook-Air:tmp $ tcptraceroute nodejs.org 80
>> Selected device en0, address 192.168.1.107, port 57585 for outgoing
>> packets
>> Tracing the path to nodejs.org (165.225.133.150) on TCP port 80 (http),
>> 30 hops max
>>  1  192.168.1.1  4.144 ms  1.739 ms  1.139 ms
>>  2  lo10.cab2.hfa.nv.net.il (212.143.205.233)  15.141 ms  12.162 ms
>>  11.659 ms
>>  3  core1-cab1-hfa.hfa.nv.net.il (212.143.207.16)  15.204 ms  13.932 ms
>>  12.857 ms
>>  4  gw2-0-2-0-1-core1.hfa.nv.net.il (212.143.7.25)  11.599 ms  12.655 ms
>>  16.048 ms
>>  5  165.225.133.150 [open]  157.406 ms  157.195 ms  168.028 ms
>>
>> MacBook-Air:tmp $ tcptraceroute nodejs.org 443
>> Selected device en0, address 192.168.1.107, port 57586 for outgoing
>> packets
>> Tracing the path to nodejs.org (165.225.133.150) on TCP port 443
>> (https), 30 hops max
>>  1  192.168.1.1  3.398 ms  1.755 ms  1.230 ms
>>  2  lo10.cab2.hfa.nv.net.il (212.143.205.233)  11.704 ms  16.318 ms
>>  11.138 ms
>>  3  core1-cab1-hfa.hfa.nv.net.il (212.143.207.16)  14.981 ms  13.580 ms
>>  17.064 ms
>>  4  gw2-0-3-0-0-core1.hfa.nv.net.il (212.143.7.53)  12.450 ms  14.393 ms
>>  10.653 ms
>>  5  10.10.40.1  12.454 ms  18.778 ms  14.951 ms
>>  6  gw2-fra-0-3-0-3-200-gw2.hfa.nv.net.il (212.143.12.12)  67.772 ms
>>  68.099 ms  110.025 ms
>>  7  10.10.70.1  70.582 ms  76.711 ms  66.120 ms
>>  8  xe-4-3-2-302.fra23.ip4.gtt.net (77.67.94.5)  67.824 ms  66.694 ms
>>  97.753 ms
>>  9  xe-1-2-3.was14.ip4.gtt.net (89.149.180.198)  154.917 ms  167.244 ms
>>  168.940 ms
>> 10  internap-gw.ip4.gtt.net (77.67.69.254)  164.903 ms  175.436 ms
>>  158.257 ms
>> 11  border10.pc2-bbnet2.wdc002.pnap.net (216.52.127.73)  156.724 ms
>>  153.793 ms  164.227 ms
>> 12  joyent-3.border10.wdc002.pnap.net (64.94.31.202)  166.082 ms
>>  163.434 ms  163.415 ms
>> 13  165.225.143.105  163.860 ms  169.177 ms  154.384 ms
>> 14  165.225.143.15  178.280 ms  152.575 ms  159.958 ms
>> 15  165.225.133.150 [open]  157.337 ms  162.811 ms  164.262 ms
>>
>>
>>
>> On Sat, Mar 21, 2015 at 7:48 PM, E.S. Rosenberg > > wrote:
>>
>>> Depending on the version of windows and it's network environment you
>>> freshly installed rootkits could be likely, but that is OT here.
>>>
>>> Note that different ISP in Israel is a fairly relative statement since
>>> there are basically just a few major players who own a bunch of the smaller
>>> ISPs and could have caching proxies on their international lines...
>>>
>>> Did you traceroute the connection both from working and non-working
>>> settings?
>>>
>>> Regards,
>>> Eliyahu - אליהו
>>>
>>> 2015-03-21 8:30 GMT+02:00 Amos Shapira :
>>>
 Just speculating, but could it be that your ISP uses a caching
 transparent proxy (which would explain why it doesn't happen on SSL) and
 its cache got corrupted?
 The "other ISP" case could be explained if it's actually
 upstream/downstream from your ISP, or they share a proxy cache for other
 reasons.


 On 21 March 2015 at 04:07, Roman Ovseitsev  wrote:

> Please forgive the slight off-topic, but I am experiencing a rather
> strange issue while downloading a certain file over HTTP.
>
> Instead of getting node.js installer as expected from here
> http://nodejs.org/dist/v0.12.0/node-v0.12.0-x86.msi I am receiving a
> completely different executable - an installer for Elcomsoft's Advanced 
> EFS
> Password Recovery whatever that is.
>
> Both files are exactly the same size but SHA sums obviously don't
> match.
>
> SSL version of the link -
> https://nodejs.org/dist/v0.12.0/node-v0.12.0-x86.msi works as
> expected. i.e. downloads the correct node.js installer.
>
>
> I have verified this on three different machines running Fedora,
> CentOS, and Windows. None of these machines ever exchanged any files or
> used anything else but the default repos. In fact the windows machine is a
> 13 years