Investigation Report on DNS Pollution Prevention Solution

What should I do if my website is hijacked?

Whether the domain name is walled.

How to detect DNS pollution. Website hijacking Detection

Website opening speed detection.

Checks whether a website is hacked, hacked, changed its title, or hacked.

 

I encountered DNS problems on G +, so today I tested the status quo of DNS. The entire process is very simple. You only need one command: NSLookup

In a Windows command prompt, the basic format is:

nslookup DOMAIN DNS_IP

DNS Problems in China are basically divided into two types:

1. DNS record hijacking

DNS record Hijacking means that DNS records on the DNS server are maliciously set to incorrect content. DNS hijacking is long-term and will not be repaired without manual changes.

One is that the domestic DNS will hijack some sites due to policy issues, GFW, you know. Another type:

DNS hijacking by ISPs for their own interests (preventing access to competitor WZ, advertisement placement, etc.) is common in domestic ISPs and all have the ability to hijack DNS. The feature is that the domain name resolution result is directed to the same IP address. Next we will try the default DNS of Qingdao Unicom (202.102.128.68). We will get the following two types of results:

C: userscokebar> NSLookup Baidu.com 202.102.128.68 server: ns.sdjnptt.net. cnaddress: 202.102.128.68 unauthoritative response: Name: Baidu.com. lanaddress: 220.250.64.228c: userscokebar> NSLookup Facebook.com 202.102.128.68 server: ns.sdjnptt.net. cnaddress: 202.102.128.68 unauthoritative response: Name: Facebook.com. lanaddress: 220.250.64.228c: userscokebar> NSLookup duowan.com 202.102.128.68 server: ns.sdjnptt.net. cnaddress: 202.102.128.68 unauthoritative response: Name: duowan.com. lanaddress: 220.250.64.228c: userscokebar> NSLookup taobao.com 202.102.128.68 server: ns.sdjnptt.net. cnaddress: 202.102.128.68 unauthoritative response: Name: taobao.com. lanaddress: 123.129.254.19

One is to hijack 123.129.254.18/123.129.254.19.

Another type is hijacking to the address 220.250.64.228.

At the same time, a ". Lan" is added at the end of the domain name"

So far, it is concluded that the DNS 202.102.128.68 is not the actual DNS server, but the mission of DNS hijacking. The following describes the entire process:

If you access Google.com through a browser, then 202.102.128.68 returns 123.129.254.18 to you, so you send a request to this IP address to open the Google.com homepage, and this request is received by the server 123.129.254.18, he will judge based on the preset rules. If the rule says no interference to this domain name, your access request will be forwarded to the real Google.com server, this may be the case for most websites. The whole process is not much slower than directly returning real IP addresses, and the latency cannot be determined.

If the domain name you want to access is on the blacklist, Or you enter a wrong domain name that does not exist, the server can handle the problem in a variety of ways:

1. For a domain name that does not exist, directly return a webpage pre-defined by China Unicom prompting you that "the entered domain name does not exist". When prompted to the user, it can be said that some advertisement can be implanted, this is also benign, for example, I will change the DNS to China Unicom DNS, random knock a domain name, get the following page: http://nfdnserror17.wo.com.cn: 8080/sdjc/self0.jsp? Userurl =

We can ping the following nonexistent domain name to see where it is pointed:

C: userscokebar> Ping dfslaw343412.com. Ping dfslaw343412.com [220.250.64.228] with 32 bytes of data: reply from 220.250.64.228: byte = 32 time = 21 Ms TTL = 247

Ping nfdnserror17.wo.com.cn.

C: userscokebar> Ping slave is pinging nfdnserror17.wo.com.cn [220.250.64.228] with 32 bytes of data: reply from 220.250.64.228: byte = 32 time = 20 ms TTL = 247

The result is the IP address 220.250.64.228. As mentioned above, some domain names are hijacked to this IP address.

2. forward to an incorrect IP address, leading to the inability to connect to the server or other strange phenomena. Generally, it is only for a very small number of foreign sites that are specially taken care of. For example, Twitter is the focus, facebook and YouTube are not as comprehensive as DNS hijacking + pollution, IP address blocking, and tcp_reset as Twitter do.

We can try to ping the following Twitter to see where the connection is:

C: userscokebar> Ping Twitter.com. Ping Twitter.com [59.24.3.173] data with 32 bytes: The request times out.

You can see that it is directed to the inaccessible IP address 59.24.3.173. We use the NSLookup-V parameter to query Google DNS through TCP. We can see that the real address is three addresses of 199.59.x.x:

C: userscokebar> NSLookup-V Twitter.com 8.8.8.8 server: google-public-dns-a.google.comAddress: 8.8.8.8 unauthoritative response: Name: Twitter. comaddresses: 199.59.148.82199.59.150.7199.59.149.198

G + is also hijacked by China Unicom, and IPv4 is resolved to the IP addresses of other Google servers. As a result, G + cannot be opened, the iron Tong network in the house is not hijacked:

C: userscokebar> Ping plus.google.com. Pinging plus.google.com [74.125.39.102] with 32 bytes of data: the request times out. Request timeout.

However, IPv6 is spared in connecting and enabling G + normally:

C: userscokebar> Ping plus.google.com is pinging plus-china.l.google.com [2404: 6800: 4005: 806: 1009] data with 32 bytes: From 2404: 6800: 4005: 806 :: 1009 reply: time = 288ms from 2404: 6800: 4005: 806: 1009 reply: time = 288 Ms

3. Advertisement placement. Return to a webpage with an advertisement and nest the original webpage. It looks like an advertisement on the site you visited. This is actually illegal. In the past, this situation was quite a lot, there are not so many ISPs.

 

To sum up, after such a shutdown in the DNS, the actual hijacking depends on the ISP itself, although it will not happen in most cases (except for some foreign websites that are specially taken care ), however, some domain names are hijacked in some provinces and cities, affecting normal access to some sites or advertisement placement.

Solution needless to say, for most ISPs, such as China Unicom Telecom, the use of 114dns is usually no problem, change the DNS to 114.114.114.114/114.114.115.115, And the 114dns backs up DNS records for major operators, however, some websites are still hijacked, such as Twitter, but G + is still intact.
[2014.2.27] Today, I used a campus network test and found that 114dns has different policies for CERNET, and does not resolve some Google domain names or hijack websites such as Facebook. 114dns is not the best solution, it is better for these sites to be honestly mounted to the proxy.

Ii. DNS record contamination

DNS record contamination refers to the provision of false DNS records to users or other DNS servers by maliciously forging identities and exploiting vulnerabilities. Because the DNS record has a TTL, during the lifetime, DNS is stored in the cache, unless it takes more than one TTL, or the DNS cache is refreshed manually, fake records will continue to exist, and if the DNS server is contaminated, this pollution is also contagious. Remote Desktop Connection Software

DNS pollution is temporary. After the TTL period, if it is not contaminated, the pollution will disappear.

DNS record contamination is different from hijacking in that pollution is a tampering of the originally correct DNS query results, while hijacking is a DNS server's own modification of records into wrong content. For GFW, DNS hijacking is used on domestic servers, while GFW cannot modify its content on foreign servers. Therefore, DNS contamination is used to tamper with the information received by users.

The DNS contamination process of GFW is that when you query DNS records from foreign DNS servers, these traffic will be reviewed by the GFW keyword when it goes abroad. If it is blacklisted, GFW will immediately return you a false DNS record. Because the default DNS query method is UDP, And the DNS query result only recognizes the fastest returned results, you must first receive the false DNS records that GFW returns to you; even if you receive a real foreign DNS response ms later, it will be ignored by your system. If GFW wants to completely pollute a domain name, it is not just a common user. Even all DNS servers in China will receive fake DNS records, resulting in nationwide DNS pollution.

In the previous paragraph, a large-scale DNS pollution incident occurred in China for unknown reasons. Most sites and some regions in China were affected and could not be accessed through domain names. This must be related to the powerful DNS pollution capability of GFW.

However, it is not only the DNS records at the exit of foreign countries that may be contaminated, but also the ISP of various provinces and cities may use the existing GFW technology to conduct their own DNS pollution. This pollution scope is smaller and is also a part of GFW.

The method to prevent DNS pollution is to use the TCP protocol instead of UDP for DNS query, because the TCP protocol is a connection protocol that requires both parties to shake hands to communicate, this avoids GFW, a simple DNS contamination method. Currently, GFW can block TCP-based DNS queries, but it is not deployed on a large scale. Currently, only dl.dropbox.com is blocked by TCP:

C: userscokebar> NSLookup-v-D release 8.8.8.8 ------------ got answer: Header: opcode = query, id = 1, RCODE = noerrorheader flags: Response, want recursion, recursion avail. questions = 1, answers = 1, authority records = 0, additional = questions: 8.8.8.8.in-ADDR. arpa, type = PTR, class = inanswers:-> 8.8.8.8.in-ADDR. arpaname = google-public-dns-a.google.comttl = 15619 (4 hours 20 mins 19 SECs) ------------ server: google-public-dns-a.google.comAddress: 8.8.8.8read failed: result too largeread failed: result too large *** the google-public-dns-a.google.com cannot find dl.dropbox.com: unspecified error

Unfortunately, the current mainstream operating systems cannot change the system's DNS query method from the default UDP to TCP without using third-party software, which is inconvenient to implement.

 

Let's test the query of Twitter.com through Google DNS: 8.8.8.8:

C: userscokebar> NSLookup-V Twitter.com 8.8.8.8 server: google-public-dns-a.google.comAddress: 8.8.8.8.8 unofficial response: Name: Twitter. comaddresses: 199.59.148.82199.59.150.7199.59.149.198c: userscokebar> NSLookup Twitter.com 8.8.8.8 server: google-public-dns-a.google.comAddress: 8.8.8.8.8 unofficial response: Name: Twitter. comaddresses: 59.24.3.173243.185.187.39

The NSLookup command with the-V parameter is queried through TCP. The default UDP query result is not added below. Different results are displayed, it proves that GFW will conduct DNS pollution on Twitter.com, and Twitter's pollution is estimated to be nationwide, which occurs at international outlets.

Similarly, DNS pollution occurs in the query of plus.google.com through 8.8.8.8.8. The resolved IP address is also a Google server, but it is not a server that provides the G + service, in this case, the most direct phenomenon is that the server cannot be connected, and this strange phenomenon may also occur. In this case, the illusion that Google servers have problems is forged.

Also: about IPv6

In the second half of last year, I tested it in Qingdao and once experienced a very strict DNS hijacking targeting IPv6. later, I joined DNS pollution and even added a very strict keyword review policy, as a result, many Google pages are subject to tcp_reset, but they are gradually consistent with IPv4 policies. I tested a graph using IPv4 and IPv6 to ping G +:

IPv6 returns an amazing IPv6 Address [10: 2222], which is out of the picture... In actual tests, IPv6 is also contaminated with DNS, and may be contaminated with a strange IP Address:

C: userscokebar> NSLookup plus.google.com 2001: 4860: 4860: 8888 server: google-public-dns-a.google.comAddress: 2001: 4860: 4860: 8888 name: plus.google.com. lanaddresses: 2001: da8: 112: 21ae1. 1.1.1c: userscokebar> NSLookup-V plus.google.com 2001: 4860: 4860 server: google-public-dns-a.google.comAddress: 8888: 2001: 4860: 4860 non-authoritative response: Name: plus-china.l.google.comAddresses: 8888: 2404: 4005: 804: Protocol: plus.google.com

However, the status of China Unicom DNS and the school DNS only hijack IPv4, and IPv6 has nothing to do with it:

C: userscokebar> NSLookup plus.google.com 2001: da8: 7007: 107: 77 server: ns2.dnscache.upc.edu. cnaddress: 2001: da8: 7007: 77 non-authoritative response: Name: plus-china.l.google.comAddresses: 107: 2404: 6800: c00: 6674.125.39.102aliases: plus.google.com

However, at present, GFW's research on IPv6 is insufficient to block YouTube and Facebook in the same way as on IPv4, and enable HTTPS. After the keyword review is avoided, it can be viewed through IPv6 normally, in IPv4, you cannot access HTTPS.

 

Summary

 

After the DNS method was designed, it left us with such security issues. It is too easy to forge DNS records, making it an effective way to block websites in the early stage of GFW. However, the risk of using DNS blocking is not small. The National DNS pollution incident not long before the country went abroad, and earlier times, GFW contaminated foreign DNS servers, leading to the failure of normal internet access in some foreign countries. DNS is also a powerful way for ISP to implant advertisements and shield competitor websites.

 

Currently, for most ISPs such as China Unicom, China Telecom, and China Mobile, the use of DNS is a good solution to avoid malicious DNS hijacking by the ISP, it ensures direct access to Google servers such as G +, and Google DNS is recommended to be discarded. It is not as useful as it was in the past few years. Now it may suffer DNS pollution, secondly, Google DNS may not provide good support for some cdns in China, and the ping from Google DNS is relatively high.

If CERNET and other users still have hijacking using 114dns, you can consider using DNS proxy to ensure direct connection to Google sites. Most of the other websites that are on the wall are not just DNS problems, still need to be resolved by Agent

 

Investigation Report on DNS Pollution Prevention Solution