Cyclegear Website Not Available In Thailand.

[ScubaBuddha]

For the past several weeks I have noticed that www.cyclegear.com is not accessible for me using TOT here in Phuket, but is accessible from servers outside Thailand. Is it working for others in Thailand? Any ideas why it wouldn't be accessible here?

I can't think of a reason why it would be blocked. Maybe a big motorcycle accessories importer has a cousin working for MICT?

[gotlost]

I'm on AIS 3G Chiang Mai. It's a no go for me.

[Supernova]

Seems to be a DNS issue. Connect using IP address instead of domain name (works for me).

hxxp://174.132.18.82/

[gotlost]

Seems to be a DNS issue. Connect using IP address instead of domain name (works for me).

hxxp://174.132.18.82/

That is the problem. Thanks for the info.

[ScubaBuddha]

Seems to be a DNS issue. Connect using IP address instead of domain name (works for me).

So this means the domain name has not been mated to the IP address on Thailand servers? I remember this happening to another site here. I think I recall there being a way to report it to the ISP's so it can be fixed?

I just ran a little program called DNS Benchmark. It's results:

DNS Benchmark Conclusions & Recommendations

What the results you have just obtained mean to YOU

The results summary, conclusions, and recommendations from your most recent run of this DNS benchmark are provided below. Please carefully consider the implications of making any changes to your system's current configuration before doing so.

ý System has only ONE (router based) nameserver configured.

It appears that only one local (router gateway) DNS nameserver, with the IP address of [192.168.1.1], is currently providing all DNS name resolution services to this system. This configuration is not recommended because most consumer-grade routers provide inefficient and under-powered DNS resolution services.

Unless the DNS resolvers your router is using is under your control, it may not be providing the best or complete name resolution services. For example, is it using multiple redundant DNS nameservers?

Users of GRC's DNS Spoofability system have determined that consumer-grade routers can be crashed by the receipt of specific DNS reply packets from the Internet. This opens the possibility that Internet-based criminals could acquire access to your router from the Internet as well as to the private network in controls.

Many consumer-grade routers fail to provide the full range of DNS lookup services. This may have been detected by the benchmark and noted below.

Recommended Actions:

Unless you have some specific reason not to, you should give serious thought to disabling your router's provisioning of DNS services (which it is providing for all computers on your local network). After this is done, a fresh reboot of your computers will likely reveal the multiple DNS nameservers provided by your ISP. This is a superior configuration, without an under-powered router acting as a incompetent middleman and impeding all DNS access.

Note that if you can determine the IP addresses of your ISP-provided nameservers (which may be visible in your router's web configuration) you could manually add them to the nameservers being tested by this benchmark, while also leaving your router providing DNS. This would allow you to compare the performance when running through your router versus "going direct".

þ System's sole nameserver is alive and replying to queries.

Although this system has only one DNS resolving nameserver, at least it is alive and replying to DNS queries. (If it were not, you would likely be painfully aware, since it would be difficult to accomplish anything requiring Internet access.)

þ System nameserver is faster than ALL public alternatives.

The DNS resolver your system is using is responding faster than any of the 100% reliable publicly available alternative DNS nameservers this benchmark utility just tested. Therefore, there would be no performance benefit from switching to any of those publicly available nameservers. However, since you only have a single system nameserver configured, it might be useful to use some of the fastest public nameservers as backups if that's possible in your situation. Please also note that this best performance appraisal assumes that this system's nameserver is 100% reliable. See the next item below for an appraisal of your nameserver's reliability.

Note: If there appeared to be one or more faster public alternative nameservers, there was enough uncertainty created by the spread of benchmark timing results that it was not possible to be at least 95% confident that any of those faster seeming nameservers really were reliably faster than the nameserver this system is currently using. So it made no sense to alarm you about the need to change things when there was insufficient evidence.

ý One or more system nameservers is NOT 100% reliable!

DNS reliability is extremely important, since lookup requests that are dropped and ignored by nameservers cause significant delays in Internet access while the querying system waits for a reply. The system is then finally forced to reissue the query to the same or to backup nameservers. While your system is patiently waiting for a reply, you are impatiently waiting to get on with your Internet access.

During this benchmark test, the nameserver being tested did not reply to some of the DNS queries it was sent.

So the question now is: Did the benchmark discover alternative nameservers having superior performance and reliability to which you could switch in order to obtain more performance and reliability?

Important Note:

Incorrect warnings of low reliability nameservers can arise if (1) DNS benchmarking is being performed while the local network is busy performing other work such as file downloading, or (2) the benchmark is running over a wireless (WiFi) link with low signal strength or high interference. Please try to minimize any other local network activity while the benchmark is running, and use a wired (not wireless) LAN connection if possible.

Recommended Actions:

Before you make any changes, you should probably run the benchmark a few more times at differing times of day to make sure that the troubling reliability is an ongoing problem and not just a brief occurrence.

You may also wish to consult the "Tabular Data" page which summarizes all benchmark results in numeric tables. The numbers make it easier to see exactly how unreliable your system's nameserver is compared with the available alternatives. (And also how the alternatives' performance compares.)

þ This system nameserver returns errors.

This is a GOOD thing! Some DNS providers, such as OpenDNS and even the Earthlink, Roadrunner and Comcast ISPs, redirect incorrectly entered URLs to their own advertising-laden marketing-driven interception page instead of simply returning an error to the web browser. But this system's nameserver is returning errors when asked to lookup non-existent domain names.

þ System nameserver is replying to all query types.

During the development of this DNS Benchmark we discovered that the routers used by some pre-release testers were not returning results for the benchmark's Uncached and/or Dotcom testing queries. Even though these queries are admittedly unusual, they are completely valid. So the only conclusion was that those few routers were inherently defective. The good news here is that your nameserver is replying to these unusual but valid queries.

[siamect]

So this means the domain name has not been mated to the IP address on Thailand servers? I remember this happening to another site here. I think I recall there being a way to report it to the ISP's so it can be fixed?

It's on their primary DNS the record is wrong:

---------------------------------------

whois cyclegear.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered

with many different competing registrars. Go to http://www.internic.net

for detailed information.

Domain Name: CYCLEGEAR.COM

Registrar: GODADDY.COM, INC.

Whois Server: whois.godaddy.com

Referral URL: http://registrar.godaddy.com

Name Server: NS51.DOMAINCONTROL.COM

Name Server: NS52.DOMAINCONTROL.COM

Status: clientDeleteProhibited

Status: clientRenewProhibited

Status: clientTransferProhibited

Status: clientUpdateProhibited

Updated Date: 20-aug-2009

Creation Date: 14-dec-1996

Expiration Date: 13-dec-2014

------------------------------------------------------

nslookup www.cyclegear.com NS51.DOMAINCONTROL.COM

Server: NS51.DOMAINCONTROL.COM

Address: 216.69.185.26#53

www.cyclegear.com canonical name = www.cyclegear.com.akadns.net.

------------------------------------------------------

nslookup www.cyclegear.com.akadns.net

Server: 192.168.0.100

Address: 192.168.0.100#53

Non-authoritative answer:

www.cyclegear.com.akadns.net canonical name = blackhole.cyclegear.com.akadns.net.

Name: blackhole.cyclegear.com.akadns.net

Address: 127.0.0.1

------------------------------------------------------

nslookup cyclegear.com NS51.DOMAINCONTROL.COM

Server: NS51.DOMAINCONTROL.COM

Address: 216.69.185.26#53

Name: cyclegear.com

Address: 174.132.18.82

[ScubaBuddha]

So this means the domain name has not been mated to the IP address on Thailand servers? I remember this happening to another site here. I think I recall there being a way to report it to the ISP's so it can be fixed?

It's on their primary DNS the record is wrong:

Sorry...idiot here. Who's record is wrong? I assume that you mean my Thai ISP since it works using a proxy.

[siamect]

So this means the domain name has not been mated to the IP address on Thailand servers? I remember this happening to another site here. I think I recall there being a way to report it to the ISP's so it can be fixed?

It's on their primary DNS the record is wrong:

Sorry...idiot here. Who's record is wrong? I assume that you mean my Thai ISP since it works using a proxy.

No it looks like cyclegear have screwed up their own primary dns record... That is the one that all other DNS are getting their records from. I this case it is stored on these servers:

Name Server: NS51.DOMAINCONTROL.COM

Name Server: NS52.DOMAINCONTROL.COM

[ScubaBuddha]

Ok. But then would it be normal for the site to be accessible via proxy? Because it is. Presumably it's accessible from inside the states as well. It's a huge company.

[Supernova]

Access via US proxy server is working alright -- I just tried it. However, the domain isn't accessible from Thailand for some reason.

[siamect]

Access via US proxy server is working alright -- I just tried it. However, the domain isn't accessible from Thailand for some reason.

The www.cyclegear.com resolves to a CNAME and that to another CNAME which resolves to 127.0.0.1 which is your local computer....

cyclegear.com (no www in front) resolves to the correct IP but the webserver answers with a permanently moved...

martin@MATACILT:~$ wget cyclegear.com

--2010-08-12 00:04:20-- http://cyclegear.com/

Resolving cyclegear.com... 174.132.18.82

Connecting to cyclegear.com|174.132.18.82|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: http://www.cyclegear.com/ [following]

--2010-08-12 00:04:25-- http://www.cyclegear.com/

Resolving www.cyclegear.com... 127.0.0.1

Connecting to www.cyclegear.com|127.0.0.1|:80... connected.

HTTP request sent, awaiting response... 500 Internal Server Error

2010-08-12 00:04:30 ERROR 500: Internal Server Error.

Here it goes to my local computer that has a webserver but not accepting the request

martin@MATACILT:~$ wget www.cyclegear.com

--2010-08-12 00:05:09-- http://www.cyclegear.com/

Resolving www.cyclegear.com... 127.0.0.1

Connecting to www.cyclegear.com|127.0.0.1|:80... connected.

HTTP request sent, awaiting response... 500 Internal Server Error

2010-08-12 00:05:14 ERROR 500: Internal Server Error.

Same here but with IP itself it works:

martin@MATACILT:~$ wget 174.132.18.82

--2010-08-12 00:03:47-- http://174.132.18.82/

Connecting to 174.132.18.82:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/html]

Saving to: `index.html.2'

[ <=> ] 145,958 81.9K/s in 1.7s

2010-08-12 00:03:50 (81.9 KB/s) - `index.html.2' saved [145958]

What this tells me is that the DNS record is wrong for www.cyclegear.com and the webserver is accepting only ip or maybe www.cyclegear.com but because www.cyclegear.com resolves to 127.0.0.1 in the end you never reach the webserver with that URL.

It doesn't give any clue at all why it works from other places... Th DNS record in the primary DNS is exactly the sameas what I get from True DNS....

Maybe the proxy is giving you a cached version instead of the real one, seems a little too long time but.... Have you tried with other proxies?

Martin

[Supernova]

I have every reason to believe the web page isn't a cached version. I use the same US-based proxy to access blocked sites from time to time. Content at these sites is always up to date.

[siamect]

If I force the www.cyclegear.com to the right ip in the hosts file then it works....

martin@MATACILT:~$ cat /etc/hosts

174.132.18.82 www.cyclegear.com

127.0.0.1 localhost

martin@MATACILT:~$ wget cyclegear.com

--2010-08-12 00:33:39-- http://cyclegear.com/

Resolving cyclegear.com... 174.132.18.82

Connecting to cyclegear.com|174.132.18.82|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: http://www.cyclegear.com/ [following]

--2010-08-12 00:33:40-- http://www.cyclegear.com/

Resolving www.cyclegear.com... 174.132.18.82

Connecting to www.cyclegear.com|174.132.18.82|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/html]

Saving to: `index.html.4'

[ <=> ] 145,958 69.5K/s in 2.1s

2010-08-12 00:33:43 (69.5 KB/s) - `index.html.4' saved [145958]

[siamect]

oops double

[siamect]

I have every reason to believe the web page isn't a cached version. I use the same US-based proxy to access blocked sites from time to time. Content at these sites is always up to date.

I believe you.... there a possibility that the DNS servers can give a record based on the location (IP) of the requester...That's the last thing that I can come up with and I don't know that part well at all...

It is still so that the DNS records are screwed up... Are there any experts on geo-aware DNS out there?

Martin

[Supernova]

If I force the www.cyclegear.com to the right ip in the hosts file then it works....

martin@MATACILT:~$ cat /etc/hosts

174.132.18.82 www.cyclegear.com

127.0.0.1 localhost

martin@MATACILT:~$ wget cyclegear.com

--2010-08-12 00:33:39-- http://cyclegear.com/

Resolving cyclegear.com... 174.132.18.82

Connecting to cyclegear.com|174.132.18.82|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: http://www.cyclegear.com/ [following]

--2010-08-12 00:33:40-- http://www.cyclegear.com/

Resolving www.cyclegear.com... 174.132.18.82

Connecting to www.cyclegear.com|174.132.18.82|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: unspecified [text/html]

Saving to: `index.html.4'

[ <=> ] 145,958 69.5K/s in 2.1s

2010-08-12 00:33:43 (69.5 KB/s) - `index.html.4' saved [145958]

It works indeed.

Never thought of using the hosts file for anything other than to block sites. Thanks for the tip!

[siamect]

It works indeed.

Never thought of using the hosts file for anything other than to block sites. Thanks for the tip!

But I have problems with the pictures... they don't load...

When I use the IP directly that works fine...

------------------------------------------------------------------

martin@MATACILT:~$ wget http://cyclegear.com/images/streetapparel/firstgear_wms_glacier_glvs_blk_SM.jpg

--2010-08-12 11:24:20-- http://cyclegear.com...glvs_blk_SM.jpg

Resolving cyclegear.com... 174.132.18.82

Connecting to cyclegear.com|174.132.18.82|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: http://www.cyclegear...glvs_blk_SM.jpg [following]

--2010-08-12 11:24:21-- http://www.cyclegear...glvs_blk_SM.jpg

Resolving www.cyclegear.com... 174.132.18.82

Connecting to www.cyclegear.com|174.132.18.82|:80... connected.

HTTP request sent, awaiting response... No data received.

Retrying.

--2010-08-12 11:24:56-- (try: 2) http://www.cyclegear...glvs_blk_SM.jpg

Connecting to www.cyclegear.com|174.132.18.82|:80... connected.

HTTP request sent, awaiting response... No data received.

Retrying.

-------------------------------------------------------------------------------

With IP it works:

martin@MATACILT:~$ wget http://174.132.18.82...glvs_blk_SM.jpg

--2010-08-12 11:25:42-- http://174.132.18.82...glvs_blk_SM.jpg

Connecting to 174.132.18.82:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 1577 (1.5K) [image/jpeg]

Saving to: `firstgear_wms_glacier_glvs_blk_SM.jpg'

100%[==========================================================================================================================================>] 1,577 --.-K/s in 0.001s

2010-08-12 11:25:42 (1.60 MB/s) - `firstgear_wms_glacier_glvs_blk_SM.jpg' saved [1577/1577]

Martin

[astral]

Yes a DNS issue.

The domain name does not work from here in the Middle East, but the IP address does.

[Supernova]

It works indeed.

Never thought of using the hosts file for anything other than to block sites. Thanks for the tip!

But I have problems with the pictures... they don't load...

When I use the IP directly that works fine...

No issues here. Everything working the way it should.

[dollarman]

the site did not work last time I tried from Thailand. And it is not working in Malaysia either. Just a blank cyclegear site.