This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||
|
What about a section listing work arounds such as redirect blockers, alternative DNS's such as Google's, and "https everywhere". -- Bequw ( talk) 22:01, 29 August 2011 (UTC)
For example, the version of IE that I have here automatically redirects me to my search provider: the version of FF that I have here automatically redirects single-word urls to www. .com for example fred is redirected to www.fred.com — Preceding unsigned comment added by 203.206.162.148 ( talk) 08:04, 13 March 2012 (UTC)
The claim in this article that NXDOMAIN hijacking disables local networking is dubious because it ignores the functionality of most residential gateways (home routers), and similar SOHO products, that either (a) obviate the need for DNS resolution within LANs or (b) capture & divert DNS requests before they can even reach external DNS servers where NXDOMAIN hijacking occurs.
Generally, IPv4 home routers have their own DHCP servers that allocate IP addresses to LAN devices from a private network block, with NAT used to translate LAN IPv4 addresses to the customer's single external IPv4 address for Internet access. Most LAN applications use private IPv4 addresses obtained from the router directly, and thus do not need DNS resolution at all. ( IPv6 home routers aren't common enough yet to make similar generalizations, but they should operate similarly.)
Also, IPv4 home routers usually have their own built-in DNS server for the entire LAN, which is connected to the DHCP-server application. During the DHCP allocation process, the router provides each client with its own IP address as the default (usually sole) DNS server; it also typically captures the client's hostname. Both hostname and IP address are stored in the router's DNS cache, along with the results of previous requests to the external DNS server (usually obtained via DHCP or PPPoE from the WAN, but may be entered into some routers manually). Only DNS requests that aren't resolved via either the client's built-in lookup functions (i.e., hosts file) *or* the router's DNS cache (i.e., LAN & previously-requested WAN addresses) are sent to the external DNS server (and thus are subject to NXDOMAIN hijacking).
Generally, the *only* way NXDOMAIN hijacking can disable local networking is if the LAN isn't configured properly--most commonly if an external DNS server is hard-coded into the LAN client AHEAD of (or in place of) the home router's DNS server--and then only if the client looks for other LAN clients using DNS. NXDOMAIN hijacking can lead to other problems, but normally it should *not* disable LANs as this article suggests. -- RBBrittain ( talk) 17:17, 6 July 2012 (UTC)
I removed the link to the Charter not found page as it does not appear to be a valid link. I am not connecting from a Charter network, so it may be valid on their network, but if that is the case a screenshot should be taken, as this link would provide no benefit for anyone not on Charter. Here is the original text of the link:
(as exemplified by charter here. Notice the "Manage Opt-In settings" link) Crazyburns ( talk) 16:50, 22 March 2013 (UTC)
I can confirm that the Charter link does not work for users outside of Charter's network. I agree that any sample "ISP Redirect Page" should be included as a screenshot rather than a link.
I also don't see anywhere in this thread for discussing the proposed merger of the ISP Redirect Page article into the DNS hijacking article. The content already in this article, specifically within the Manipulation By ISPs section, is of higher quality and more exhaustive than that found in the ISP Redirect Page article. Therefore, I support the merger.
- Bigmantonyd ( talk) 22:13, 2 December 2013 (UTC)
- Removed Comcast from the list since this function was turned off in 2012, per [1] — Preceding unsigned comment added by Jlivingood ( talk • contribs) 18:28, 29 March 2019 (UTC)
Would it be informative to include a reference to the "attacks" that were reported 20130327? SamHahn ( talk) 17:34, 28 March 2013 (UTC)
Google chrome has 'Browse By Name' functionality so makes queries to non-existent random 10 character domains e.g. nzysobeays then makes HEAD requests to them. This allows chrome to detect and prevent ISPs hijacking. This could go into the mitigations section, but some more research and citations are needed (also would need to be typed more eloquently than I can). — Preceding unsigned comment added by 222.153.147.60 ( talk) 23:03, 23 October 2013 (UTC)
Hello fellow Wikipedians,
I have just modified 4 external links on DNS hijacking. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 20:34, 4 December 2016 (UTC)