OpenDNS blocks https requests, but not http

[drickcanada]

I'm facing a weird problem with OpenDNS. It blocks successfully https requests to, say, xvideos.com; the browser complains about the certificate and doesn't let me go through, which is fine with me. But If I try to open http://xvideos.com, the request goes through normally.

My network has its own DNS server that points to OpenDNS. And it resolves xvideos IP as expected:

$ nslookup xvideos.com

Server: 192.168.0.3

Address: 192.168.0.3#53

Non-authoritative answer:

Name: xvideos.com

Address: 146.112.61.106

What am I missing? Thanks!

[rotblitz]

I do not see any evidence that you're using OpenDNS at all.  I rather doubt it.  It's the browser complaining, not OpenDNS, and you didn't say you got an OpenDNS block page.  What does http://welcome.opendns.com/ come up with?

You may also post the complete plain text output of the following diagnostic command:

   nslookup -type=txt debug.opendns.com.

[drickcanada]

Thanks for the response. Although I'm pretty sure I'm using OpenDNS, I'm no DNS expert. 

http://welcome.opendns.com comes up with the expected OpenDNS message:

Welcome to OpenDNS!

Your Internet is safer, faster, and smarter
because you’re using OpenDNS.

Thank you!

Here's the output of nslookup:

$ nslookup -type=txt debug.opendns.com.

Server: 192.168.0.3

Address: 192.168.0.3#53

Non-authoritative answer:

debug.opendns.com text = "server 1.mia"

debug.opendns.com text = "flags 20 0 50 19500027F0071189EF3"

debug.opendns.com text = "originid 42187080"

debug.opendns.com text = "actype 2"

debug.opendns.com text = "bundle 8450146"

debug.opendns.com text = "source 131.255.81.24:63564"

Authoritative answers can be found from:

[rotblitz]

This looks promising.  Ensure that your IP address 131.255.81.24 is registered at https://dashboard.opendns.com/settings/ - i.e. that 42187080 is your network ID and not another user's, else you would use the other user's settings.

Did you flush your caches?  https://support.opendns.com/entries/26336865
Else you may be served out of these caches with outdated stuff.

Still problems?  Post the complete plain text output of the following commands:

   nslookup whoami.akamai.net.

   nslookup www.xvideos.com.

[rotblitz]

This looks promising.  Ensure that your IP address 131.255.81.24 is registered at https://dashboard.opendns.com/settings/ - i.e. that 42187080 is your network ID and not another user's, else you would use the other user's settings.

[rotblitz]

Did you flush your caches?  https://support.opendns.com/entries/26336865

Else you may be served out of these caches with outdated stuff.

Still problems?  Post the complete plain text output of the following commands:

   nslookup whoami.akamai.net.

   nslookup www.xvideos.com.

[rotblitz]

Also, did you flush your caches?  https://support.opendns.com/entries/26336865
Else you may be served out of these caches with outdated stuff.

Still problems?  Post the complete plain text output of the following commands:

   nslookup whoami.akamai.net.

   nslookup xvideos.com.

[drickcanada]

Yes, those are my IP address and network ID. I tried flushing the DNS cache. I also tried getting rid of my local DNS and pointed my machine's DNS directly to OpenDNS. This is really weird. It looks like I'm resolving the expected IP for xvideos (146.112.61.106 is an OpenDNS IP), but my computer still fetches the contents from said website. The only other thing I can think of is that my ISP is caching requests and serving me whatever they have cached for xvideos. That would explain why https gets blocked properly as it doesn't get cached. I will get in touch with them to see if that's a possibility.

$ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

$ nslookup whoami.akamai.net

Server: 192.168.0.3

Address: 192.168.0.3#53

Non-authoritative answer:

Name: whoami.akamai.net

Address: 204.194.239.17

$ nslookup xvideos.com

Server: 192.168.0.3

Address: 192.168.0.3#53

Non-authoritative answer:

Name: xvideos.com

Address: 146.112.61.106

Just so no browser cache would throw me off, I tried to fetch xvideos with curl and it worked normally:

$ curl -v xvideos.com

* Rebuilt URL to: xvideos.com/

*   Trying 146.112.61.106...

* Connected to xvideos.com (146.112.61.106) port 80 (#0)

> GET / HTTP/1.1

> Host: xvideos.com

> User-Agent: curl/7.43.0

> Accept: */*

> 

* HTTP 1.0, assume close after body

< HTTP/1.0 301 Moved Permanently

< Server: nginx

< Date: Tue, 23 Feb 2016 12:04:22 GMT

< Content-Type: text/html; charset=iso-8859-1

< Location: http://www.xvideos.com/

< Content-Length: 231

< Connection: close

< 

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

...

[rotblitz]

Yes, this 204.194.239.17 is related to OpenDNS' Miami location: Miami, US     NAP of the Americas     NAP of the Americas     204.194.239.0/24
as of https://www.opendns.com/data-center-locations/
And 146.112.61.106 is hit-adult.opendns.com indicating that the domain is blocked by category.  So, all is fine from a DNS perspective.

And also cURL resolves to hit-adult.opendns.com.  But surprisingly it HTTP GETs their real data which is a HTTP 301 webhop to http://www.xvideos.com/ indicating that this must be cached somewhere, as you correctly said.

Perform this cache check to see if there's stealthed transparent proxy caching by your ISP: http://www.lagado.com/tools/cache-test