Comcast/Verizon Blocking English Domain Of Hamas’ News Site

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.