Why is this page redirect happening?

Jphillips · 2022-11-02 10:23:12

When I visit the page http://infolab.stanford.edu/~backrub/google.html, it displays briefly, then redirects to

http://net.domain.name/?terms=Google%20Server%20Cloud,Free%20Host%20Server,%20Create%20an%20Ecommerce%20Website%
20for%20Free,Email%20Server%20Hosting%20Services&subid1=stanford.edu?ref=http://infolab.stanford.edu/~backrub/google.html

This happens on Firefox, Chromium, and Brave browser. But.... it *doesn't* happen if I am running through a VPN or inside of a virtualbox running Windows. It does, however, still redirect inside of a virtualbox running Manjaro.

I'm also behind a university firewall on this computer, so it seems like it's either something with my DNS or perhaps something with the firewall? But I'm also a bit concerned it's something nefarious. However, the fact that the redirect doesn't happen under Windows is really confusing me.

Any suggestions on why this redirect is happening or how to troubleshoot things?

EDIT: It seems to be a script issue -- NoScript for firefox stops the redirect. But why would this only be on firefox for linux, and not Windows?

Last edited by Jphillips (2022-11-02 12:32:30)

seth · 2022-11-02 13:00:42

Browser useragent discrimination?
What if you just pretend to be some browser on windows?
https://www.whatismybrowser.com/guides/ … nt/firefox

Jphillips · 2022-11-02 13:21:35

Thanks -- It still happens if I spoof the user agent.

The fact that it doesn't happen if I use a VPN and/or when I disable scripts is just so confusing. I can't figure out what sort of script would allow this combination to happen.

seth · 2022-11-02 13:36:03

If I curl the page it only has

<script src="http://tags.stanford.edu/tags.js" type="text/javascript"></script>

and "tags.stanford.edu" isn't resolvable.
Also I don't get redirected anywhere.
But your target url kicks me forward to ww01.de-nxd-domain.com

Are you sure it's about JS?
What if you put tags.stanford.edu into /etc/hosts and resolve it to 127.0.0.1 (explicitly not 0.0.0.0)?

Edit: also check

dig tags.stanford.edu

- you might be using your ISPs DNS and they often pull shit where they redirect unresolvable urls to some internal/promo/partner stuff.

Last edited by seth (2022-11-02 13:37:32)

Jphillips · 2022-11-02 13:50:59

If I go to http://tags.stanford.edu/tags.js it resolves for me and just shows:

window.location='http://net.domain.name/?terms=Google%20Server%20Cloud,Free%20Host%20Server,%20Create%20an%20Ecommerce%20Website%20for%20Free,Email%20Server%20Hosting%20Services&subid1=stanford.edu?ref=' + window.location.href;

Here's the output of my dig command:

$ dig tags.stanford.edu

; <<>> DiG 9.18.8 <<>> tags.stanford.edu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5197
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;tags.stanford.edu.		IN	A

;; AUTHORITY SECTION:
stanford.edu.		1717	IN	SOA	argus.stanford.edu. hostmaster.stanford.edu. 2022181612 1200 600 1296000 1800

;; Query time: 0 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Wed Nov 02 14:47:06 CET 2022
;; MSG SIZE  rcvd: 99

If I ping it I get a somewhat odd kickback (I'm in Zurich, perhaps that's the .de result?):

$ ping tags.stanford.edu
PING tags.stanford.edu.domain.name (85.10.194.207) 56(84) bytes of data.
64 bytes from static.85-10-194-207.clients.your-server.de (85.10.194.207): icmp_seq=1 ttl=49 time=10.8 ms
64 bytes from static.85-10-194-207.clients.your-server.de (85.10.194.207): icmp_seq=2 ttl=49 time=10.8 ms
64 bytes from static.85-10-194-207.clients.your-server.de (85.10.194.207): icmp_seq=3 ttl=49 time=10.8 ms
64 bytes from static.85-10-194-207.clients.your-server.de (85.10.194.207): icmp_seq=4 ttl=49 time=10.9 ms

Jphillips · 2022-11-02 14:01:59

Ok, so If add the line "127.0.0.1 tags.stanford.edu" to my /etc/hosts file, it fixes this issue.

So that's at least a step in the right direction. But still unclear what's going on.

EDIT: If I go to "static.85-10-194-207.clients.your-server.de" which is what is kicked back in the ping, I get that same initial net.domain.name redirect. So the question is why is this redirect happening in the first place?

Last edited by Jphillips (2022-11-02 14:10:55)

Trilby · 2022-11-02 14:08:55

FWIW, I can visit the original url in a browser or via curl and I get the intended article content titled "The Anatomy of a Large-Scale Hypertextual Web Search Engine".

I get that with curl with no redirects or other funny business. The url returns simple html-only code of an article with just one script tag at the very end (to the unresolvable tags.standford.edu url noted above). But as this script url is unresolvable, it does nothing.

Last edited by Trilby (2022-11-02 14:11:41)

seth · 2022-11-02 14:11:09

whois 85.10.194.207 shows that it's a hetzner server, nb. that

ping wrote:

PING tags.stanford.edu.domain.name

edu.domain.name is btw. 185.38.110.118, "Serverhousing in Prague DC"

And dig

;; AUTHORITY SECTION:
stanford.edu.		1717	IN	SOA	argus.stanford.edu. hostmaster.stanford.edu. 2022181612 1200 600 1296000 1800

does NOT resolve an IP (also not AAAA) so (i assume) your ISP is just generously redirecting the traffic [edit: for] an unresolvable domain.
Explains why that's not happening on a VPN; windows might shortcut the traffic or you may be using some adblocker?

I could not immediately figure who or what net.domain.name is.

Last edited by seth (2022-11-02 14:11:45)

Jphillips · 2022-11-02 14:29:57

seth wrote:

so (i assume) your ISP is just generously redirecting the traffic for an unresolvable domain.

Alright, so this seems to be exactly what's going on. If I go to any non-existent URL, like http://www.ThisIsAMadeUpURL123.com, it also redirects me to some http://net.domain.name garbage.

I guess my big concern here is whether this is something on my end, or if this would have to be an ISP issue? I.e., can I change my domain name servers or something to prevent this redirect? Or should I be concerned that there is some potential vulnerability or exploit happening on my local machine?

EDIT: Tried changing my DNS servers but didn't change anything, even after a restart.

Last edited by Jphillips (2022-11-02 14:41:58)

seth · 2022-11-02 14:42:01

What do you get for

getent hosts www.ThisIsAMadeUpURL123.com

Do you use resolved?

resolvectl status

(though this would be a new one and it's far more likely your ISP, maybe some mdns responder misconfig?)

Jphillips · 2022-11-02 15:00:41

Here's the output:

$ getent hosts www.ThisIsAMadeUpURL123.com
85.10.194.207   www.ThisIsAMadeUpURL123.com.domain.name

I (unfortunately) use NetworkManager. I tried switching back to systemd before, but that's what I really messed things up and had to revert back. Perhaps worth trying again.

Last edited by Jphillips (2022-11-02 15:01:09)

seth · 2022-11-02 15:14:40

getent resolves this…
NM or networkd doesn't matter - both can use resolved, but for NM it's optional

resolvectl status

https://wiki.archlinux.org/title/Networ … management
https://wiki.archlinux.org/title/Networ … openresolv (or https://wiki.archlinux.org/title/Networ … esolv.conf - /etc/resolv.conf will then not be touched )

As a quick test, you could remove "resolve" from the hosts line in /etc/nsswitch.conf and re-test "getent hosts www.ThisIsAMadeUpURL123.com"

Jphillips · 2022-11-02 15:50:18

OK, I fixed this issues. I switched from NetworkManager to systemd-networkd, and things are now working fine. I guess this makes me think it's something either with the NetworkManager configuration, perhaps the fallback DNS? Still makes me a bit uneasy about why this was happening with NetworkManager....

seth · 2022-11-02 16:02:03

Your 1st dig reply is from 8.8.8.8 (googles DNS) - what does "dig tags.stanford.edu" now respond?

Jphillips · 2022-11-03 08:37:57

I was able to fix the issue by switching from NetworkManager to systemd. I realize that doesn't help diagnose the issue, but at least it's a workaround. This weekend I'll try switching back to NetworkManager and going down the rabbit hole a bit more.

stingA0815 · 2022-11-03 21:40:34

Jphillips wrote:

I was able to fix the issue by switching from NetworkManager to systemd. I realize that doesn't help diagnose the issue, but at least it's a workaround. This weekend I'll try switching back to NetworkManager and going down the rabbit hole a bit more.

This reminds me of an experience from the past when the developers set up the servers and used the Ubunutu desktop image!

The network manager does not necessarily respect the /etc/network/interfaces".

Last edited by stingA0815 (2022-11-03 21:44:49)

seth · 2022-11-04 07:39:15

The network manager does not necessarily respect the /etc/network/interfaces

Of course it doesn't - /etc/network/interfaces is debians proprietary way to configure the network. It's not relevant to arch nor networkmanager.
You also don't expect vim to respect the emacs configs.

However, this thread isn't really a configuration ignorance issue - something in the previous resolver chain redirected unresolvable domains.
This isn't something that happens through any network configuration directly, but through some configured resolver (or iptables, but that would have stuck against the NM/networkd change)

@Jphillips, the .name tld is traditionally used for a lot of shady stuff because the whois is "privacy protected"; net.domain.name in particular is registered in Prague
Does "Gransy, s.r.o." ring a bell (ie. relation to your ISP)?
https://webwhois.nic.name/DotNameWhois/

   Registry Domain ID: 134596651_DOMAIN_NAME-VRSN
   Domain Name: NET.DOMAIN.NAME
   Registrar: Gransy, s.r.o.
   Registrar IANA ID: 1505
   Registrar Abuse Contact Email: abuse@regtons.com
   Registrar Abuse Contact Phone: +420.734 463 373
   Domain Status: ok https://icann.org/epp#ok
   Registry Registrant ID: REDACTED FOR PRIVACY
   Registry Admin ID: REDACTED FOR PRIVACY
   Registry Tech ID: REDACTED FOR PRIVACY
   Registry Billing ID: REDACTED FOR PRIVACY
   Name Server: DNS1.DOMAIN.NAME
   Name Server ID: 85492319_HOST_NAME-VRSN
   Name Server: DNS2.DOMAIN.NAME
   Name Server ID: 85492320_HOST_NAME-VRSN
   Created On: 2017-11-26T17:32:09Z
   Expires On: 2022-11-26T17:32:09Z
   Updated On: 2021-11-09T21:10:55Z

Arch Linux

#1 2022-11-02 10:23:12

Why is this page redirect happening?

#2 2022-11-02 13:00:42

Re: Why is this page redirect happening?

#3 2022-11-02 13:21:35

Re: Why is this page redirect happening?

#4 2022-11-02 13:36:03

Re: Why is this page redirect happening?

#5 2022-11-02 13:50:59

Re: Why is this page redirect happening?

#6 2022-11-02 14:01:59

Re: Why is this page redirect happening?

#7 2022-11-02 14:08:55

Re: Why is this page redirect happening?

#8 2022-11-02 14:11:09

Re: Why is this page redirect happening?

#9 2022-11-02 14:29:57

Re: Why is this page redirect happening?

#10 2022-11-02 14:42:01

Re: Why is this page redirect happening?

#11 2022-11-02 15:00:41

Re: Why is this page redirect happening?

#12 2022-11-02 15:14:40

Re: Why is this page redirect happening?

#13 2022-11-02 15:50:18

Re: Why is this page redirect happening?

#14 2022-11-02 16:02:03

Re: Why is this page redirect happening?

#15 2022-11-03 08:37:57

Re: Why is this page redirect happening?

#16 2022-11-03 21:40:34

Re: Why is this page redirect happening?

#17 2022-11-04 07:39:15

Re: Why is this page redirect happening?

Board footer