It appears that Comcast Cable and Verizon FIOS have blocked the DNS entry for the English version of Hamas’ news site.
With the Middle East Peace Talks getting underway, I thought it would be interesting to see how Hamas is characterizing the events surrounding the negotiations; so I tried accessing their semi-official news agency http://palestine-info.info/
The first thing that appears is a flash-based, language selection page, which displays fine. However, it seems that if one clicks “English” while using Verizon FIOS or Comcast Cable, a “page cannot be displayed” message appears.
Pinging/tracerting attempts are unable to resolve. Users on other ISPs trying to access the English page, have been successful. I got the IP address and was able to view the page using that.
The French language section also appears to be blocked.
Update: Qwest DSL may also be blocking the domain.
Update: While the ISPs were responsible for the improper DNS handling, it appears that the issue may have been caused by simple error, where the DNS records of the ISPs were not updated properly, which apparently is typical of the the laziness of large ISP’s. Therefore, it is prudent not to jump to any conclusions about the DNS issues possibly being the result of deliberate action or political motivation on the part of the ISPs in question. I apologize for the confusion that this may have caused. Thanks to all who helped.
 The Edification Of Sarah Palin On The English Language By Roger Ebert |
 The Tea Party Defined |
 Hamas’ Stand |
Hamas and Fatah: They Are Both Losers |
Explore the PBH Network! More funny, faster.
{ 9 comments… read them below or add one }
Not just Verizon FIOS- I have Verizon DSL (Tuckerton, NJ) and I too am having the same problem. Is It Up (http://isitup.org/www.palestine-info.co.uk) states that the website is up and I too can get to the website through the direct IP address.
Could this just be a situation of the DNS servers not updating quickly?
It seems just a problem of (now) lame DNS delegation (but I don’t know if any changes have been motivated by something else previously):
DNS service for the domain palestine-info.co.uk is delegated to ns1.palestine-info.com and ns2.palestine-info.com
and from whois for palestine-info.com one can see these were supposed to be 62.149.0.82 & 62.149.0.196. The second one is not replying, and the first one doesn’t know those ‘ns1′ and ‘ns2′ names, although from it one can see that the only name server with authority for palestine-info.com is now supposed to be ns.palestine-info.com=62.149.0.82 and the one for palestine-info.co.uk is now supposed to be ns.palestine-info.co.uk=62.149.0.119. Meanwhile, previous identical results for the address of http://www.palestine-info.co.uk (also 62.149.0.119) may be cached in some name servers, explaining why some people can easily access the web while others can’t.
Thanks for the level headed and detailed comment. Do you know if there a reason why the issue seemed to be isolated to certain ISPs? Is it just that ISPs that resolved the domain successfully used name severs that were cached with the 62.149.0.119 IP?
More than likely, the good information is still cached in your local nameservers. There are various tools you can use to retrieve that sort of information, but they are somewhat advanced. If you are on a unix/macos, you can probably use the dig command to investigate your local DNS server’s cache settings, and when it’s likely to attempt to renew.
Update: Prosepeforehos poster StiflyStiferson proves he has no clue about how DNS and the Internet work.
The internet is a series of tubes. Its not a big truck.
Qwest DSL has not blocked this website. (Northern Minnesota)
Never ascribe to malice what can be easily ascribed to uncaring arse-holery. This is another case. As an DNS/Network admin for many years, I can confidently declare a few things:
1) Big ISPs rarely follow the rules for DNS, and
2) They don’t care.
There’s a value called “TTL” (or Time To Live) for any DNS record, which is the value for how long a DNS record is supposed to be cached. This value is important because if you move your site to a new location, you want to set a short TTL because you want the old (wrong) values to expire quickly so that your customers can see your new location. If you are in a stable location, you’ll want to set this to a higher (longer) value so that your end users see your site more quickly.
Typical admins set this value to anywhere from about 8 hours to a week or so for stable sites, and reduce this to maybe an hour or less when preparing for a site move. Gonna move your site?
1) Cut the TTL down from the higher value down to a much lower value.
2) Wait 1.5x the old TTL so that everybody is working on the shorter TTL,
3) Change the servers to the new site, leave the TTL short for a day or two to make sure everything works out,
4) Change the TTL to a longer value for long-term use.
Sounds pretty simple, doesn’t it?
But larger ISPs ignore whatever you publish for this value, and instead substitute their own value that can be as long as 2 weeks. So if you move your servers, you’ll be swamped with “I can’t see your site!” support requests (if they know your number) or sharply reduced traffic for a few weeks. And the complaints all come from a few BIG ISPs – Verizon, SBC, Comcast, etc.
Smaller ISPs usually have more of a stock (read: RFC compliant) setup and don’t have problems like this. Being closer to the customer, their support lines will take un-necessary calls otherwise. Why do the big boys do it? Perhaps it’s worth the savings of 0.005% of the network bandwidth that’s typical for DNS.
To compensate, whenever I move servers, I have to either have a duplicate server arrangement, with some equipment at the old site serving the same stuff as the new site, or hjave a port forwarding arrangement, where connection attempts to the old site are proxied to the new location. And if the primary location is down due to technical failure, I have no answer for getting things back up except to provide compliant DNS, bypassing the ISP-provided DNS. (tell customers to use OpenDNS, perhaps) No matter how you slice it, this makes life much more difficult, but saves $$BIG_ISP$$ a few bucks so they do it.
(shrug)
I have Comcast, and it works just fine for me.
{ 3 trackbacks }