Talk:DNS hijacking

Computing: Networking / Security Low‑importance

This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles

Low

This article has been rated as Low-importance on the project's importance scale.

This article is supported by Networking task force (assessed as Mid-importance).

This article is supported by WikiProject Computer Security (assessed as High-importance).

Things you can help WikiProject Computer Security with:

Article alerts will be generated shortly by AAlertBot. Please allow some days for processing. More information...

Review importance and quality of existing articles
Identify categories related to Computer Security
Tag related articles
Identify articles for creation (see also: Article requests)
Identify articles for improvement
Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc.
Find editors who have shown interest in this subject and ask them to take a look here.

Work arounds

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)[reply]

also web browser redirection

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)[reply]

Dubious

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)[reply]

Some home routers do not allow the DNS settings to be changed from those supplied by the ISP, notably some cable modems that have configs locked down by the ISP, where the subscriber is thus prevented from changing the DNS settings in the DHCP leases used on the private side of the connection. In this case, a second router or host-based config is required to override the rogue DNS settings of the ISP. Socrates2008 (Talk) 10:26, 8 July 2012 (UTC)[reply]

The behavior of the vast majority of home routers is to either act as a DNS cache or give clients the DNS servers of the ISP directly through DHCP. As a result, any home router on an ISP that performs DNS hijacking will, by default, cause LAN computer name resolution for LAN clients to resolve to an incorrect IP address. The only way (in Windows) to override this is to change the DhcpNodeType parameter under the NetBT service registry key to 0x00000008, which gives LAN broadcast name resolution priority over DNS for NetBIOS purposes. The router can sometimes be configured to use a standards-compliant DNS service, but on any ISP where DNS hijacking is performed, the default behavior (the end result of the combined Windows defaults and router + ISP defaults) is to break LAN NetBIOS name resolution completely. Most home/SOHO routers ignore NetBIOS name service broadcast packets insofar as DNS resolution is concerned (usually capturing them only to display the advertised hostname on the DHCP lease status page), so any claims that the router "diverts DNS requests" or otherwise prevents the broken NXDOMAIN behavior from affecting the LAN clients is incorrect. I am removing the "dubious" tag, because the claim is not dubious and your explanation of why you believe it is dubious misunderstands the real-world DNS implementations in home routers. Daivox (talk) 06:19, 4 August 2013 (UTC)[reply]

Manipulation by ISPs

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)[reply]

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)[reply]

- 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)[reply]

20130327 incident?

Would it be informative to include a reference to the "attacks" that were reported 20130327? SamHahn (talk) 17:34, 28 March 2013 (UTC)[reply]

No, the attacks of...uh... 27th March 2013 come under the category of DNS Amplification Attacks. I think it can also be called a 'reflection' attack.

Picture: http://www.publicsafety.gc.ca/prg/em/ccirc/2013/mgs/tr02-fig02-eng.gif

It's a type of DDoS, and doesn't involve hijacking DNS lookups by changing the DNS server a computer uses. As far as I understand, it involves changing the address the DNS server is supposed to respond to. This new address will then receive a load of DNS-related packets that it never asked for. When using many DNS servers to perform this attack, it can be quite deadly to sites running on small- or medium-sized independent servers, because the initial traffic needed to generate the attack is quite small compared to the traffic the victim(s) receive(s). Additionally, to a DNS server operator, it might even look like all the DNS queries are actually coming from the victim, instead of another malicious party. Only unchecked open DNS resolvers are vulnerable to being reflectors for that kind of attack, and their numbers are shrinking, thankfully.--BurritoBazooka (talk) 23:18, 20 April 2013 (UTC)[reply]

Google chrome DNS hijack detection

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)[reply]

External links modified

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).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 20:34, 4 December 2016 (UTC)[reply]