Change:
4.3. <del> DNS Cache Poisoning refers to a mechanism where a censor interferes with the response sent by a DNS resolver to the requesting device by </del> <ins> There are a variety of mechanisms that censors can use to block or filter access to content by altering responses from the DNS ICANN- SSAC-2012, including blocking the response, replying with an error message, or responding with an incorrect address (potentially to a server that can communicate to the end-user a reason for blocking access to that resource, for example using HTTP Status Code 451 RFC7725). DNS poisoning refers to a mechanism where a censor interferes with the response sent by a DNS server to the requesting device by </ins> injecting an alternative IP address into the response message on the <del> return path.  Cache poisoning occurs after the requested site's name servers resolve the request and attempt to forward the IP back to the requesting device; on the return route the resolved IP is recursively cached by each DNS server that initially forwarded the request. During this caching process if an undesirable keyword is recognized, the resolved IP is poisoned and an alternative IP is returned.  These alternative IPs usually direct to a nonsense domain or a warning page ViewDNS-2011.  Alternatively, Iranian censorship appears to prevent the communication en-route, preventing a response from ever being sent Aryan-2012. Trade-offs: DNS Cache Poisoning is one of the rarer forms of prevention due to a number of shortcomings.  DNS Cache Poisoning requires the censor to force a user to traverse a controlled DNS resolver for the mechanism to be effective, it is easily circumvented by a technical savvy user that opts to use alternative DNS resolvers, such as the 8.8.8.8/8.8.4.4 public DNS resolvers provided by Google. DNS Cache Poisoning also implies returning an incorrect IP to those attempting to resolve a domain name, but the site is still technically unblocked if the user has another method to acquire the IP address of the desired site.  Blocking overflow has also been a </del> <ins> return path ViewDNS-2011.  Cache poisoning occurs after the requested site's name servers resolve the request and attempt to forward the IP back to the requesting device; on the return route the resolved IP is recursively cached by each DNS server that initially forwarded the request.  During this caching process if an undesirable keyword is recognized, the resolved IP is "poisoned" and an alternative IP (or NXDOMAIN error) is returned.  The alternative IPs usually direct to a nonsense domain or a warning page.  Alternatively, Iranian censorship appears to prevent the communication en-route, preventing a response from ever being sent Aryan-2012. Trade-offs: DNS interference requires the censor to force a user to traverse a controlled DNS hierarchy (or intervening network on which the censor serves as a Active Pervastive Attacker RFC7624 to rewrite DNS responses) for the mechanism to be effective.  It can be circumvented by a technical savvy user that opts to use alternative DNS resolvers (such as the public DNS resolvers provided by Google or OpenDNS) or Virtual Private Network technology.  DNS poisoning also implies returning an incorrect IP to those attempting to resolve a domain name, but in some cases the destination may be technically acessible; over HTTP, for example, the user may have another method of obtaining the IP address of the desired site and may be able to access it if the site is configured to be the defualt server listening at this IP address.  Blocking overflow has also been a </ins> problem, as occasionally users outside of the censors region will be <del> directed through a DNS server controlled by a censor, causing the request to fail.  The ease of circumvention paired with the large risk of overblocking and blocking overflow make DNS Cache Poisoning a partial, difficult, and less than ideal censorship mechanism. Empirical Evidence: DNS Cache Poisoning, when properly implemented, is easy to identify based on the shortcomings identified above. Turkey relied on DNS Cache Poisoning for its country-wide block of websites such Twitter and Youtube for almost week in March of 2014 but the ease of circumvention resulted in an increase in the popularity of Twitter until Turkish ISPs implementing an IP blacklist to achieve the governmental mandate Zmijewki-2014.  To drive proverbial "nail in the coffin" Turkish ISPs started hijacking all requests to Google and Level 3's international DNS resolvers Zmijewki-2014.  DNS Cache Poisoning, when incorrectly implemented, has as has resulted in some of the largest "censorship disasters". In January 2014 China started directing all requests passing through the Great Fire Wall to a single domain, dongtaiwang.com, due to an improperly configured DNS Cache Poisoning attempt; this incident is thought to be the largest internet-service outage in history Anon- SIGCOMM12.  Countries such as China, Iran, Turkey, and the United States have discussed blocking entire TLDs as well, but only Iran has acted by blocking all Israeli (.il) domains Albert-2011. </del> <ins> directed through a DNS servers or DNS-rewriting network equipment controlled by a censor, causing the request to fail.  The ease of circumvention paired with the large risk of overblocking and blocking overflow make DNS interference a partial, difficult, and less than ideal censorship mechanism. Empirical Evidence: DNS interference, when properly implemented, is easy to identify based on the shortcomings identified above.  Turkey relied on DNS interference for its country-wide block of websites such Twitter and Youtube for almost week in March of 2014 but the ease of circumvention resulted in an increase in the popularity of Twitter until Turkish ISPs implementing an IP blacklist to achieve the governmental mandate Zmijewki-2014.  Ultimately, Turkish ISPs started hijacking all requests to Google and Level 3's international DNS resolvers Zmijewki-2014.  DNS interference, when incorrectly implemented, has resulted in some of the largest "censorship disasters".  In January 2014 China started directing all requests passing through the Great Fire Wall to a single domain, dongtaiwang.com, due to an improperly configured DNS poisoning attempt; this incident is thought to be the largest internet-service outage in history Anon-SIGCOMM12.  Countries such as China, Iran, Turkey, and the United States have discussed blocking entire TLDs as well, but only Iran has acted by blocking all Israeli (.il) domains Albert-2011. </ins> 4.4.

Discussion:
Stephane Bortzmeyer provided great feedback on DNS aspects of this document, itemized in issues and . These commits should address those comments.
From Stephane: "Later in the document, there is again sloppy wording about the DNS. "As Domain Names are resolved recursively, if a TLD deregisters a domain all other DNS resolvers..." Which "other resolvers"? The TLD name servers are not resolvers. Also, the example "such as .ch or .ru" is poorly choosen since I am not aware of any case of censorship by the swiss TLD ("reference needed", as they say in Wikipedia). Better to use .com as an example (operation "In our sites" by the ICE)."
From Stephane: ""occasionally users outside of the censors region will be directed through a DNS server controlled by a censor, causing the request to fail" If you refer to the root-servers-in-China / Chile case, the requests never went "through a DNS server controlled by a censor". In China, this DNS mangling is done by network equipment, and does not require a DNS server."
From Stephane: "In the same section "the site is still technically unblocked if the user has another method to acquire the IP address of the desired site" is false for HTTP (unless the Web site is the only one listening at this IP address: otherwise, without a proper Host: field, using the IP address won't work)."
From Stephane: "Also, the section is self-contradictoy when it says "it is easily circumvented by a technical savvy user that opts to use alternative DNS resolvers" while mentioning later than Turkey solved the problem of circumvention by hijacking Google Public DNS' addresses. Unlike what you seem to imply, it was a success for the turkish government, very difficult to circumvent (Google does not use any authentication technique on Google Public DNS and, besides, there is little deployment of these techniques in the DNS.)"
From Stephane: ""DNS Cache Poisoning is one of the rarer forms of prevention" In France, it is the most common since it is mandated by law for at least two cases (illegal gambling and promotion of terrorism)."

from Stephane: "The first sentence is specially confusing: "DNS Cache Poisoning refers to a mechanism where a censor interferes with the response sent by a DNS resolver to the requesting device by injecting an alternative IP address on the return path." If it is done after the resolver, the cache will never see the alternative IP address and so won't be poisoned."
From Stephane: "the title "DNS Cache Poisoning" is very misleading since not all censorship-via-DNS target the cache. "DNS cache poisoning" describes a limited set of specific attacks and you should not use it to describe any DNS mangling. Otherwise, discussions about possible solutions would be impossible (for instance, DNSSEC fixes the problem of DNS cache poisoning but certainly not all the DNS censorship techniques)." Seems like the title needs to be fixed to "DNS Interference" or "DNS Censorship" and it be made broader to incorporate more features of DNS censorship.