Jump to content

Sprint redirecting NXDOMAIN to search-error.com?


kevinkrueger

Recommended Posts

I just noticed that Sprint is redirecting my browser to search-error.com for NXDOMAIN results (i.e. if I enter a domain that doesn't exist).

 

Is this new? I have a few concerns about this:

 

1. The search-error.com domain is suspicious looking. I generally associate hyphenated domain names with the less savory corners of the Internet.

2. There's no Sprint branding anywhere on the page. The colors don't even match Sprint's branding. The only clue that this might be related to Sprint is that the "Customer Care" link links to Sprint customer care. Edit: I guess there's a small Sprint.com copyright message on the bottom of the page as well.

3. It uses my metered data and exposes me to advertising I didn't ask for.

4. It violates Internet standards.

5. There's no apparent way to opt out

 

Given how fishy looking the page is, I'm not entirely convinced this is Sprint's doing. My Google searches for search-error.com only turned up one Tweet where someone was complaining to Sprint about this just a few days ago.

 

I just did a whois on this domain, and it was registered on August 6. It's not even registered in Sprint's name. It's a private "Domains by Proxy" registration.

  • Like 1
Link to comment
Share on other sites

Try setting your DNS to the Google DNS servers https://developers.google.com/speed/public-dns/

 

or to OpenDNS

 

http://wdgfstatus.com/opendns-win7/

 

Or do you mean your phone's browser?

 

Yeah, this is with Chrome on Android. I don't believe I can change the DNS servers on it without root?

 

Also, when I connected to my home wifi with my phone, Chrome stopped redirecting NXDOMAINs.

 

The fact that search-error.com mentions and links to Sprint tells me that this is somehow related to Sprint, whether or not it's Sprint's doing.

Link to comment
Share on other sites

Yeah, this is with Chrome on Android. I don't believe I can change the DNS servers on it without root?

 

Also, when I connected to my home wifi with my phone, Chrome stopped redirecting NXDOMAINs.

 

The fact that search-error.com mentions and links to Sprint tells me that this is somehow related to Sprint, whether or not it's Sprint's doing.

Really weird. Perhaps a tower your phone is connecting to has bad DNS settings? I'd give Sprint a call as I have never heard of this outside using AT&T/TWC/Comast's DNS settings and seeing a spammy page for search results when it can't connect to a website (which is why I use the Google DNS).

Link to comment
Share on other sites

Really weird. Perhaps a tower your phone is connecting to has bad DNS settings? I'd give Sprint a call as I have never heard of this outside using AT&T/TWC/Comast's DNS settings and seeing a spammy page for search results when it can't connect to a website (which is why I use the Google DNS).

 

Yeah, it's definitely concerning. Could it be a hack of Sprint's infrastructure?

 

I'm very curious if anyone else can reproduce this. I just tried it on my wife's phone, and got redirected to search-error.com as well. So it's not just my phone, anyway.

Link to comment
Share on other sites

Yeah, it's definitely concerning. Could it be a hack of Sprint's infrastructure?

 

I'm very curious if anyone else can reproduce this. I just tried it on my wife's phone, and got redirected to search-error.com as well. So it's not just my phone, anyway.

Does it happen just where you are or is it in other areas around town? If it is just where you are I am 99% sure it is just something misconfigured on Sprint's end rather than something malicious.

Link to comment
Share on other sites

I don't like it one bit. I've seen it on multiple towers. The first time I saw it, I thought for sure I had some malware on my phone. It's such a cheap and fishy looking web page. At a minimum, Sprint should make it clearer that this page is affiliated with them, document it on their website, and offer a way to opt out (as many other ISPs which do NXDOMAIN hijacking do).

 

As further evidence of how shady this site is, the "Make this My Homepage" link at the top of it is broken. It throws a javascript exception.

 

Oddly, the Sprint copyright message and link to Sprint customer care only appear on the desktop version of the site. These links aren't visible on the mobile version. So there's NO sprint branding that I can see when viewing the mobile version of the site.

 

After looking through the page source, I found the search-help.sprint.com also goes to the same site. It seems most likely to me that some firm offered Sprint some money to redirect NXDOMAINs to this site. But if Sprint won't own up to this, it's simply open to speculation, I guess. The fact that a sprint.com subdomain goes to this site tells me that Sprint has some involvement in this.

  • Like 2
Link to comment
Share on other sites

 tells me that Sprint has some involvement in this.

 

no doubt they do.  this is usually done by the ISP as another revenue stream.  Although, an opt-out is usually provided for the end user but i am not sure how this could be done on a cell device / connection.

Link to comment
Share on other sites

I really hate this behavior because it really assumes that the internet begins and ends with the web. What happens when an app or other program that isn't looking for a webpage sends out a DNS request and gets this Spammy site's IP instead of being told the requested domain doesn't exist.

  • Like 1
Link to comment
Share on other sites

Breaking NXDOMAIN is evil.  

 

I just verified the same behavior over here.  I use 'adb shell' to connect to my phone and try the following:

 

When on WiFi (correct behavior):

root@jewel:/ # nslookup klasjdfkljasdf.com                                     
Server:    192.168.0.1
Address 1: 192.168.0.1

nslookup: can't resolve 'klasjdfkljasdf.com': hostname nor servname provided, or not known 

After turning off WiFi, on Sprint 4G LTE (broken behavior):

root@jewel:/ # nslookup klasjdfkljasdf.com
Server:    68.28.68.132
Address 1: 68.28.68.132 ngns1a.chcgibr05.spcsdns.net

Name:      klasjdfkljasdf.com
Address 1: 2620:118:7008::1064
Address 2: 2620:118:7002::1064
Address 3: 198.105.254.64
Address 4: 198.105.244.64
 
And mozamcrew is right:  although tolerable for the web browser, it can easily break other applications.
Link to comment
Share on other sites

Since I have root on my HTC EVO LTE, I worked around this problem with the following steps:

 

1. "adb shell" from my computer (requires android SDK installation and USB connection to PC)

2. mount -o remount,rw /

3. Edit /init.rc (I used vi)

4. Find the end of the "on init" section.  For me it was right after the "#htc sensorhub" lines.  Add the following lines to the end:

    # Hack to force use of google DNS to fix domain/NXDOMAIN hijacking by Sprint
    /system/bin/iptables -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination 8.8.4.4:53
    /system/bin/iptables -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 8.8.4.4:53

5. Save and remount / as read-only:  mount -o remount,ro /

Link to comment
Share on other sites

Since I have root on my HTC EVO LTE, I worked around this problem with the following steps:

 

1. "adb shell" from my computer (requires android SDK installation and USB connection to PC)

2. mount -o remount,rw /

3. Edit /init.rc (I used vi)

4. Find the end of the "on init" section.  For me it was right after the "#htc sensorhub" lines.  Add the following lines to the end:

    # Hack to force use of google DNS to fix domain/NXDOMAIN hijacking by Sprint
    /system/bin/iptables -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination 8.8.4.4:53
    /system/bin/iptables -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 8.8.4.4:53

5. Save and remount / as read-only:  mount -o remount,ro /

 

Interesting. I had read somewhere else that Sprint redirects port 53 requests to their own DNS servers regardless of the destination IP address, but apparently that's not the case. This might motivate me to root my phone.

Link to comment
Share on other sites

Interesting. I had read somewhere else that Sprint redirects port 53 requests to their own DNS servers regardless of the destination IP address, but apparently that's not the case. This might motivate me to root my phone.

 

Yeah, I'm not big on rooting phones to flash fancy ROMs or anything, since in my experience they tend to have unpredictable quality with respect to device drivers and stability.  But I do use rooted stock ROMs so I can have control over things like this.

 

And it does not appear that Sprint redirects port 53 requests in my area at least (Wisconsin).  I verified that bogus domain names still returned NXDOMAIN while on 4G LTE after applying my hack.

Link to comment
Share on other sites

Since I have root on my HTC EVO LTE, I worked around this problem with the following steps:

 

1. "adb shell" from my computer (requires android SDK installation and USB connection to PC)

2. mount -o remount,rw /

3. Edit /init.rc (I used vi)

4. Find the end of the "on init" section. For me it was right after the "#htc sensorhub" lines. Add the following lines to the end:

# Hack to force use of google DNS to fix domain/NXDOMAIN hijacking by Sprint    /system/bin/iptables -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination 8.8.4.4:53    /system/bin/iptables -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 8.8.4.4:53
5. Save and remount / as read-only: mount -o remount,ro /

Yeah, I'm not big on rooting phones to flash fancy ROMs or anything, since in my experience they tend to have unpredictable quality with respect to device drivers and stability. But I do use rooted stock ROMs so I can have control over things like this.

 

And it does not appear that Sprint redirects port 53 requests in my area at least (Wisconsin). I verified that bogus domain names still returned NXDOMAIN while on 4G LTE after applying my hack.

The init files are not stored on disk as you see them in the file structure. In order to properly set the iptables rules you have to extract the boot image from its partition, unpack it, unpack the ramdisk, edit the init file, repack the boot image, and flash it. Alternatively, if you have init.d support you can make a script in /system/etc/init.d containing the iptables rules.

 

Regardless, it won't work. Sprint does redirect all DNS requests. If you try "nslookup sjifiejfbd.com 8.8.8.8" to force nslookup to use google dns, you still get the same IP as "nslookup sjifiejfbd.com" without forcing.

Link to comment
Share on other sites

The init files are not stored on disk as you see them in the file structure. In order to properly set the iptables rules you have to extract the boot image from its partition, unpack it, unpack the ramdisk, edit the init file, repack the boot image, and flash it. Alternatively, if you have init.d support you can make a script in /system/etc/init.d containing the iptables rules.

 

Regardless, it won't work. Sprint does redirect all DNS requests. If you try "nslookup sjifiejfbd.com 8.8.8.8" to force nslookup to use google dns, you still get the same IP as "nslookup sjifiejfbd.com" without forcing.

 

You are correct on the first point, but incorrect on the second.  For the first point, I must have been sloppy and missed that, since I was sure I rebooted to test.  Thanks!

 

For the second point, as mentioned before, Sprint is definitely not redirecting DNS requests in my area.  See adb shell log below:

 

(this was while connected to Sprint 4G LTE with WiFi disabled;  using a different cell site than the previous test even)

root@jewel:/ # nslookup alksjdfklj.com
Server:    68.28.68.132
Address 1: 68.28.68.132 ngns1a.chcgibr05.spcsdns.net

Name:      alksjdfklj.com
Address 1: 2620:118:7008::1064
Address 2: 2620:118:7002::1064
Address 3: 198.105.244.64
Address 4: 198.105.254.64
root@jewel:/ # nslookup alksjdfklj.com 8.8.4.4                                 
Server:    8.8.4.4
Address 1: 8.8.4.4 google-public-dns-b.google.com

nslookup: can't resolve 'alksjdfklj.com': hostname nor servname provided, or not known
 

Maybe Sprint's DNS redirection behavior varies by region.

Link to comment
Share on other sites

You are correct on the first point, but incorrect on the second.  For the first point, I must have been sloppy and missed that, since I was sure I rebooted to test.  Thanks!

 

For the second point, as mentioned before, Sprint is definitely not redirecting DNS requests in my area.  See adb shell log below:

 

(this was while connected to Sprint 4G LTE with WiFi disabled;  using a different cell site than the previous test even)

root@jewel:/ # nslookup alksjdfklj.com
Server:    68.28.68.132
Address 1: 68.28.68.132 ngns1a.chcgibr05.spcsdns.net

Name:      alksjdfklj.com
Address 1: 2620:118:7008::1064
Address 2: 2620:118:7002::1064
Address 3: 198.105.244.64
Address 4: 198.105.254.64
root@jewel:/ # nslookup alksjdfklj.com 8.8.4.4                                 
Server:    8.8.4.4
Address 1: 8.8.4.4 google-public-dns-b.google.com

nslookup: can't resolve 'alksjdfklj.com': hostname nor servname provided, or not known
 

Maybe Sprint's DNS redirection behavior varies by region.

Mine is always redirected so it must.

Link to comment
Share on other sites

Mine is always redirected so it must.

 

If that's the case for you, that's especially evil of Sprint.  The only ways I can think of to workaround that would be to use something like OpenDNS which serves on port 5353 in addition to 53.  Then you'd use a local caching nameserver on 127.0.0.1 or use a similar iptables rule to redirect outgoing port 53 traffic to OpenDNS on 5353.  It's a shame that DNS hijacking has become so common.

Link to comment
Share on other sites

If that's the case for you, that's especially evil of Sprint.  The only ways I can think of to workaround that would be to use something like OpenDNS which serves on port 5353 in addition to 53.  Then you'd use a local caching nameserver on 127.0.0.1 or use a similar iptables rule to redirect outgoing port 53 traffic to OpenDNS on 5353.  It's a shame that DNS hijacking has become so common.

OpenDNS does redirection for NXDOMAIN returns as well...

Link to comment
Share on other sites

It's by IP though and mobile IP isn't static.

True enough, thanks for the reminder. I use OpenDNS for our home network, and that has a sticky "dynamic" IP. I have it set on the router so it covers all of our devices without needing to configure any of them.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • large.unreadcontent.png.6ef00db54e758d06

  • gallery_1_23_9202.png

  • Posts

    • Fury Gran Coupe (My First Car - What a Boat...)
    • Definite usage quirks in hunting down these sites with a rainbow sim in a s24 ultra. Fell into a hole yesterday so sent off to T-Mobile purgatory. Try my various techniques. No Dish. Get within binocular range of former Sprint colocation and can see Dish equipment. Try to manually set network and everybody but no Dish is listed.  Airplane mode, restart, turn on and off sim, still no Dish. Pull upto 200ft from site straight on with antenna.  Still no Dish. Get to manual network hunting again on phone, power off phone for two minutes. Finally see Dish in manual network selection and choose it. Great signal as expected. I still think the 15 minute rule might work but lack patience. (With Sprint years ago, while roaming on AT&T, the phone would check for Sprint about every fifteen minutes. So at highway speed you could get to about the third Sprint site before roaming would end). Using both cellmapper and signalcheck.net maps to hunt down these sites. Cellmapper response is almost immediate these days (was taking weeks many months ago).  Their idea of where a site can be is often many miles apart. Of course not the same dataset. Also different ideas as how to label a site, but sector details can match with enough data (mimo makes this hard with its many sectors). Dish was using county spacing in a flat suburban area, but is now denser in a hilly richer suburban area.  Likely density of customers makes no difference as a poorer urban area with likely more Dish customers still has country spacing of sites.
    • Mike if you need more Dish data, I have been hunting down sites in western Columbus.  So far just n70 and n71 reporting although I CA all three.
    • Good catch! I meant 115932/119932. Edited my original post I've noticed the same thing lately and have just assumed that they're skipping it now because they're finally able to deploy mmWave small cells.
  • Recently Browsing

    • No registered users viewing this page.
×
×
  • Create New...