I actually get the same error on every single file I tried downloading, including OpenWRT for yun. I also tried just saving the file (rightclick and so on), but the download of the file failed for some reason.
Get this error now. Trying to download the 1.6.0 IDE. Tried FF, Chrome and IE. Same error on all. Took a remote desktop into a server at work (different network, never been to arduino pages before) but got the same error.
Hello,
Resolution of downloads.arduino.cc is 5.254.114.221
As you can simply verify with http://tracert.com/resolver or any other resolver. Users like Markus1811 who are having a different ip should try flushing their own dns cache and try again.
We cannot solve bugs in operating systems or Internet providers who do not respect DNS Ttl values.
I strongly suggest a router restart in some hard to solve cases.
Hey guys, (#mastrolinux)
i do not want to offend anyone, but i have to respond to this...
What is it that u want to tell us? Does the ip address for downloads.arduino.cc switched?
No static ip address? TTL for downloads.arduino.cc is, queried against the nameserver from arduino.cc, 900sec which is really short...
So why are you doing thinks like this?
We cannot solve bugs in operating systems or Internet
providers who do not respect DNS Ttl values
Where do you see a bug? Even if you set your TTL to such a low value, why do you think every dns server around will update their caches within this amount of time for your domains. Respecting TTLs is nice, but as long as i know this is not higher mathematics or rocket sience, it's more like a "it would be nice".
And, last but not least, if DNS changes and TTL for downloads.arduino.cc is such an important subject, why don't you write down a quick note to everyone, short instructions for WIN, LIN, MAC and pin it to the top of this forum...
The server was switched 4 days ago. For a while we kept the old and new server up and running.
From DNS specs:
When the authoritative server creates this record its TTL
is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
This TTL decrements in a similar manner to a normal cached answer and
upon reaching zero (0) indicates the cached negative answer MUST NOT
be used again.
I think the words “must not” are clear enough and authoritative servers are giving the right value in the last 4 days already.
This is a clear bug in user operating system or configuration. I gave a suggestion
on clearing DNS cache. Next time we will keep both servers up and running for more time to help our users but please report the bug to the Os developer or your network administrators.