At 22:43 02-06-2009, Jeff Chan wrote:
This December 2007 paper "The Great DNS Wall of China" suggests that Chinese ISPs are (being forced to) distort DNS results for domains that contain certain strings:
David Funk posted a message about a stale configuration causing bogus responses. On the surface, that may explain the behavior. However, it does not explain the malformed packets. We could theorize that the incorrect results are due to some corruption (broken nameserver, etc.). Based on other rough tests I conducted, I don't think so.
Regards, -sm
On 6/2/09, SM sm@resistor.net wrote:
At 22:43 02-06-2009, Jeff Chan wrote:
This December 2007 paper "The Great DNS Wall of China" suggests that Chinese ISPs are (being forced to) distort DNS results for domains that contain certain strings:
David Funk posted a message about a stale configuration causing bogus responses. On the surface, that may explain the behavior. However, it does not explain the malformed packets. We could theorize that the incorrect results are due to some corruption (broken nameserver, etc.). Based on other rough tests I conducted, I don't think so.
The specific IPs being returned correspond exactly to the paper:
flickr.com.multi.surbl.org has address 202.106.1.2 flickr.com.multi.surbl.org has address 209.145.54.50 ;; Got bad packet: bad label type 86 bytes e7 f7 85 80 00 01 00 01 00 00 00 00 06 66 6c 69 63 6b 72 03 63 6f 6d 05 6d 75 6c 74 69 05 73 75 72 62 6c 03 6f 72 67 00 00 0f 00 01 06 66 6c 69 63 6b 72 03 63 6f 6d 05 6d 75 6c 74 69 05 73 75 72 62 6c 03 6f 72 67 00 00 0f 00 01 00 01 51 80 00 04 d8 ea b3 0d
twitter.com.multi.surbl.org has address 209.145.54.50 twitter.com.multi.surbl.org has address 216.234.179.13 twitter.com.multi.surbl.org has address 64.33.88.161
flickr.com.multi.surbl.org has address 4.36.66.178 flickr.com.multi.surbl.org has address 203.161.230.171 flickr.com.multi.surbl.org has address 202.181.7.85
Which suggests deliberate DNS distortion, as opposed to a misconfiguration.
rbldnsd version 0.996a should be fine.
Jeff C.
On 3-06-2009 10:46, SURBL Role wrote:
David Funk posted a message about a stale configuration causing bogus responses. On the surface, that may explain the behavior. However, it does not explain the malformed packets. We could theorize that the incorrect results are due to some corruption (broken nameserver, etc.). Based on other rough tests I conducted, I don't think so.
The specific IPs being returned correspond exactly to the paper:
flickr.com.multi.surbl.org has address 202.106.1.2 flickr.com.multi.surbl.org has address 209.145.54.50
Which suggests deliberate DNS distortion, as opposed to a misconfiguration.
rbldnsd version 0.996a should be fine.
Any idea about why this happens only with older rbldnsd versions?
I'd expect this to happen based only on geographic location of the SURBL mirror (does the query pass through the great firewall or not?), not on the software version...
Couldn't be "they" just "improved" the DNS hijacking stuff in order to have replies to subdomain queries (flickr.com.multi.surbl.org) managed the same way of 2nd level queries (flickr.com), in oder to -say- block mirrors and proxies too, so we're observing this issue just now?
On 6/3/09, Emanuele Balla skull@spin.it wrote:
Any idea about why this happens only with older rbldnsd versions?
They may produce slightly different results by default. For example, future versions of rbldnsds may have long answers turned off by default. Or it may not be an issue.
I'd expect this to happen based only on geographic location of the SURBL mirror (does the query pass through the great firewall or not?), not on the software version...
Couldn't be "they" just "improved" the DNS hijacking stuff in order to have replies to subdomain queries (flickr.com.multi.surbl.org) managed the same way of 2nd level queries (flickr.com), in oder to -say- block mirrors and proxies too, so we're observing this issue just now?
The paper talks about DNS modification based on substring matching. That was in 2007. Not sure why it would start applying now. Could be proxies, or maybe someone is trying to bypass China's DNS firewall by offering a DNS service like:
twitter.com.bypassthegreatwall.com
which resolves to the real IP for twitter.com
Jeff C.
On 3-06-2009 11:16, SURBL Role wrote:
The paper talks about DNS modification based on substring matching. That was in 2007. Not sure why it would start applying now. Could be proxies, or maybe someone is trying to bypass China's DNS firewall by offering a DNS service like:
twitter.com.bypassthegreatwall.com
which resolves to the real IP for twitter.com
Roland Dobbins pointed me to this:
http://www.usatoday.com/tech/news/2009-06-02-china-twitter-tiananmen-protest...
I guess Chinese hijacking is now being applied to all queries related to twitter, flickr, etc. in order to inhibit the chance of bypassing the block.
Hi!
rbldnsd version 0.996a should be fine.
Any idea about why this happens only with older rbldnsd versions?
Its not depending on the rbldnsd version.
mirror (does the query pass through the great firewall or not?), not on the software version...
Correct.
Couldn't be "they" just "improved" the DNS hijacking stuff in order to have replies to subdomain queries (flickr.com.multi.surbl.org) managed the same way of 2nd level queries (flickr.com), in oder to -say- block mirrors and proxies too, so we're observing this issue just now?
I personally feel we should withdraw them completely there. What if they all off the sudden feel they should return 127.0.0.2 for any surbl lookup. The colleteral damage would be inmense.
Bye, Raymond.
On 3-06-2009 11:19, Raymond Dijkxhoorn wrote:
I personally feel we should withdraw them completely there. What if they all off the sudden feel they should return 127.0.0.2 for any surbl lookup. The colleteral damage would be inmense.
I sadly agree. I think SURBL cannot give out DNS-based services from places were there is no control on what is going to be really replied to queries.
On 6/3/09, Emanuele Balla skull@spin.it wrote:
On 3-06-2009 11:19, Raymond Dijkxhoorn wrote:
I personally feel we should withdraw them completely there. What if they all off the sudden feel they should return 127.0.0.2 for any surbl lookup. The colleteral damage would be inmense.
I sadly agree. I think SURBL cannot give out DNS-based services from places were there is no control on what is going to be really replied to queries.
I tend to agree. An unreliable network is an unhappy one.
Jeff C.
I think SURBL cannot give out DNS-based services from places were there is no control on what is going to be really replied to queries.
I tend to agree. An unreliable network is an unhappy one.
Jeff,
Jumping in here after a long chain but I'm gathering that people are saying DNS lookups are being altered by a firewall intended to keep Chinese citizens from browsing the web.
I've been working with a sha1 hash system to block bad images using DNSBL as the lookup method. This got me thinking what about a hash of the URL so it's more like b14b18da529769a503201357ac224c32857d1e69.multi-hash.uribl.org?
This would fix the issue, would it not if SA had code to do the same hash prior to lookup?
Regards, KAM
On 3-06-2009 15:41, Kevin A. McGrail wrote:
I've been working with a sha1 hash system to block bad images using DNSBL as the lookup method. This got me thinking what about a hash of the URL so it's more like b14b18da529769a503201357ac224c32857d1e69.multi-hash.uribl.org?
This would fix the issue, would it not if SA had code to do the same hash prior to lookup?
Even if this surely solve *this* issue avoiding the domain to be clear-text, this is not a solution for this problem.
What is going to happen when that hijacking stuff starts replying SURBL queries positively no matter what's being asked?
Hi!
Jumping in here after a long chain but I'm gathering that people are saying DNS lookups are being altered by a firewall intended to keep Chinese citizens from browsing the web.
I've been working with a sha1 hash system to block bad images using DNSBL as the lookup method. This got me thinking what about a hash of the URL so it's more like b14b18da529769a503201357ac224c32857d1e69.multi-hash.uribl.org?
This would fix the issue, would it not if SA had code to do the same hash prior to lookup?
Its a nice suggestion but i tend to say why would we change things since someone deliberately messes things up. If i would setup anything for/with CN gouvernment it would be a method to report CN spams. CN is doing a lot of blocking and crap but on the other hand they are one of the top domains -used- in spams. Kinda sucks. Fast flux is somehow .CN nowdays.
bye, Raymond.
-
Emanuele Balla -
Kevin A. McGrail -
Raymond Dijkxhoorn -
SM -
SURBL Role