Using just www to bring up site when on campus network
June 22, 2015 8:44 AM Subscribe
Our university site used to be hosted on the campus servers. While it was there, people on the campus network were able to type just "www" and it would redirect to the full site. We've recently changed to hosting on wpengine, and now www brings up a 404 page.
I'm guessing this has to do with how our dns is set up - the domain is at godaddy. Can someone explain to me how to set up dns so that, when on the campus network, www redirects to the full www.nmhu.edu? I'm not really a network person, but due to odd campus restructuring, this has fallen in my lap. (or, if its not dns, let me know what it is?)
I'm guessing this has to do with how our dns is set up - the domain is at godaddy. Can someone explain to me how to set up dns so that, when on the campus network, www redirects to the full www.nmhu.edu? I'm not really a network person, but due to odd campus restructuring, this has fallen in my lap. (or, if its not dns, let me know what it is?)
If you ping "www" from the command line of your PC, does the displayed IP address match the real, external IP of www.nmhu.edu?
If it doesn't, you'll need to address it in DNS. One way to do this would be to have your campus DHCP admin push out a host file entry for "www" which points to the external IP address of the www.nmhu.edu website. If the address changes, though, it'd be stuck on everyone's PC until their DHCP lease refreshes, which might be too long of a dwell time.
If it matched up like it's supposed to, then I'd second jozxyqk's suggestion to check the host configuration of your website.
posted by jquinby at 9:00 AM on June 22, 2015 [1 favorite]
If it doesn't, you'll need to address it in DNS. One way to do this would be to have your campus DHCP admin push out a host file entry for "www" which points to the external IP address of the www.nmhu.edu website. If the address changes, though, it'd be stuck on everyone's PC until their DHCP lease refreshes, which might be too long of a dwell time.
If it matched up like it's supposed to, then I'd second jozxyqk's suggestion to check the host configuration of your website.
posted by jquinby at 9:00 AM on June 22, 2015 [1 favorite]
Best answer: As jozxyqk mentioned, this almost definitely isn't an issue with DNS. This is a configuration concern with wpengine. If DNS were not available for www, you would get a "can't find the server error," not a 404.
If an unbound domain - say, www - is given for a site, DNS on that machine will go through the list of search domains listed in its configuration trying to resolve the site. For example, if machines on nmhu.edu's networks are configured with nmhu.edu as the search domain, as they likely are, the machine will resolve www to www plus the search domain, www.nmhu.edu. This is likely still working.
This probably worked fine on the old server, which likely was a dedicated server that responded to any web request with the NMHU web site. However, that's not the case with wpengine, who have to serve web sites from the same servers for many clients.
When you contact a web site that serves multiple sites and domains, the web browser will pass the URL that was entered to the remote web site for processing. As such, when you visit www.nmhu.edu, the web browser tells wpengine that you're trying to view "www.nmhu.edu". When you visit www (and it gets resolved to www.nmhu.edu in DNS, which is almost definitely happening), the web browser just tells wpengine to serve a web page for "www".
The issue is, it's likely that the vast majority of wpengine customers also use www as the top level domain - so wpengine can't configure its servers to serve a web page (other than the 404 error you got) for that domain. They need the full domain to determine which customer's page to serve. You wouldn't want people entering www and then getting some other wpengine customer's site that also starts with www.
It is possible that wpengine could perform some sort of configuration magic where visits to www without a domain from a particular IP range would get redirected to www.nmhu.edu, but it's sort of unlikely that their configuration management system allows that. You'll need to talk to wpengine about that - they're the only ones who can ultimately answer this question.
As a workaround, a way that you could implement a fix yourself is to have only nmhu.edu (without the www) resolve to wpengine. Then, set up www.nmhu.edu to resolve to a web site that has been configured exclusively to redirect all requests to nmhu.edu, without the www in front. That way, someone entering www would have their request expanded to www.nmhu.edu, hit the server that redirects them to nhmu.edu, which is then resolved and served by wpengine.
posted by eschatfische at 9:11 AM on June 22, 2015 [5 favorites]
If an unbound domain - say, www - is given for a site, DNS on that machine will go through the list of search domains listed in its configuration trying to resolve the site. For example, if machines on nmhu.edu's networks are configured with nmhu.edu as the search domain, as they likely are, the machine will resolve www to www plus the search domain, www.nmhu.edu. This is likely still working.
This probably worked fine on the old server, which likely was a dedicated server that responded to any web request with the NMHU web site. However, that's not the case with wpengine, who have to serve web sites from the same servers for many clients.
When you contact a web site that serves multiple sites and domains, the web browser will pass the URL that was entered to the remote web site for processing. As such, when you visit www.nmhu.edu, the web browser tells wpengine that you're trying to view "www.nmhu.edu". When you visit www (and it gets resolved to www.nmhu.edu in DNS, which is almost definitely happening), the web browser just tells wpengine to serve a web page for "www".
The issue is, it's likely that the vast majority of wpengine customers also use www as the top level domain - so wpengine can't configure its servers to serve a web page (other than the 404 error you got) for that domain. They need the full domain to determine which customer's page to serve. You wouldn't want people entering www and then getting some other wpengine customer's site that also starts with www.
It is possible that wpengine could perform some sort of configuration magic where visits to www without a domain from a particular IP range would get redirected to www.nmhu.edu, but it's sort of unlikely that their configuration management system allows that. You'll need to talk to wpengine about that - they're the only ones who can ultimately answer this question.
As a workaround, a way that you could implement a fix yourself is to have only nmhu.edu (without the www) resolve to wpengine. Then, set up www.nmhu.edu to resolve to a web site that has been configured exclusively to redirect all requests to nmhu.edu, without the www in front. That way, someone entering www would have their request expanded to www.nmhu.edu, hit the server that redirects them to nhmu.edu, which is then resolved and served by wpengine.
posted by eschatfische at 9:11 AM on June 22, 2015 [5 favorites]
Best answer: Is it possible for you to distribute a memo across campus that says "entering www in your browser will no longer redirect to www.nmhu.edu"?
Really, properly, that's the right answer to move forward. Teach people to use fully qualified domain names to visit exactly the site they are trying to visit.
Nobody should expect "www" to resolve to their campus website. What if an innocent student moves on, types "www" in a browser somewhere off campus, and gets directed who-knows-where?
Once upon a time, it was a convenient side effect, but the web has evolved to the point where it seems like generally a bad idea.
</rant>
posted by jozxyqk at 9:17 AM on June 22, 2015 [6 favorites]
Really, properly, that's the right answer to move forward. Teach people to use fully qualified domain names to visit exactly the site they are trying to visit.
Nobody should expect "www" to resolve to their campus website. What if an innocent student moves on, types "www" in a browser somewhere off campus, and gets directed who-knows-where?
Once upon a time, it was a convenient side effect, but the web has evolved to the point where it seems like generally a bad idea.
</rant>
posted by jozxyqk at 9:17 AM on June 22, 2015 [6 favorites]
eschatfische is generally right- the "fix" is to add enable WP to respond to requests for "www". I believe this isn't core WP functionality, and needs an extension at the very least. Here is one.
That said, I agree with jozxyqk that DNS Search Domains are terrible and should be excised from your tech infrastructure. It's a relic of a time where most "internet" use happened within one's own network because there wasn't much else out there, and has no business as a de facto utility in a time of mobile tech.
posted by mkultra at 9:33 AM on June 22, 2015 [1 favorite]
That said, I agree with jozxyqk that DNS Search Domains are terrible and should be excised from your tech infrastructure. It's a relic of a time where most "internet" use happened within one's own network because there wasn't much else out there, and has no business as a de facto utility in a time of mobile tech.
posted by mkultra at 9:33 AM on June 22, 2015 [1 favorite]
I think a number of you are missing the fact that by "www" OP means ONLY "www," not www.example.com.
posted by Mo Nickels at 10:18 AM on June 22, 2015 [1 favorite]
posted by Mo Nickels at 10:18 AM on June 22, 2015 [1 favorite]
Yeah, this is a webserver configuration problem, not a DNS problem.
I doubt shared hosting will be able to accomodate this (since you don't seem to have access to the webserver config). You'd need a dedicated server (like a VPS) to do it.
If you have your own hosting, it's a pretty simple change to the server config.
(My attempt at an explanation for this: Shared hosting means many websites being hosted at the same IP address. Because there's more than one website, for each request the webserver has to look at the HTTP headers and check what site the user "really" wanted to load. When someone goes to your site by entering "www", that's all the server sees in the headers, and it doesn't know that the user was trying to get to your site, so you get the default result, which is apparently a 404 error.)
posted by neckro23 at 10:23 AM on June 22, 2015
I doubt shared hosting will be able to accomodate this (since you don't seem to have access to the webserver config). You'd need a dedicated server (like a VPS) to do it.
If you have your own hosting, it's a pretty simple change to the server config.
(My attempt at an explanation for this: Shared hosting means many websites being hosted at the same IP address. Because there's more than one website, for each request the webserver has to look at the HTTP headers and check what site the user "really" wanted to load. When someone goes to your site by entering "www", that's all the server sees in the headers, and it doesn't know that the user was trying to get to your site, so you get the default result, which is apparently a 404 error.)
posted by neckro23 at 10:23 AM on June 22, 2015
I agree with eschatfische's diagnosis.
The school I netadmin runs a squid proxy cache, so if that were my problem I'd just add a rule to rewrite http://www as http://www.nmhu.edu (I'm already using jesred with squid to do a bunch of other rewrites for other purposes, so this would be a trivial fix).
If you're not already using a local proxy, consider installing squid; properly configured, it will save you a heap of upstream bandwidth as well as allowing easy fixes like this.
If you don't want to use a proxy, you could just turn your old on-campus web server back on and configure it to do 301 redirects to the new one for all requests.
posted by flabdablet at 11:33 AM on June 22, 2015
The school I netadmin runs a squid proxy cache, so if that were my problem I'd just add a rule to rewrite http://www as http://www.nmhu.edu (I'm already using jesred with squid to do a bunch of other rewrites for other purposes, so this would be a trivial fix).
If you're not already using a local proxy, consider installing squid; properly configured, it will save you a heap of upstream bandwidth as well as allowing easy fixes like this.
If you don't want to use a proxy, you could just turn your old on-campus web server back on and configure it to do 301 redirects to the new one for all requests.
posted by flabdablet at 11:33 AM on June 22, 2015
As many have said before this is absolutely a web server configuration issue.
So I managed to tweak my /etc/hosts file to alias www to the IP address of the linode box from which www.nmhu.edu is hosted.
When typing just www in my browser address line in both firefox and chrome they interpreted that as a search string. I had to explicitly type http://www to get the behavior you described. Frankly I think that right there tells you that using www as a shortcut probably isn't so short since you have to add the http://, where as if you use the fqdn most browsers are smart enough to add the protocol for you.
Anyway, so with this new configuration I got the 404 page you described. One of the items listed on that page is:
"Did you add this domain to your install?"
Which is a clickable link to the wpengine's help documentation. If you follow the instructions there and add www to your domains list that should fix the problem (assuming that wpengine would allow you to this).
That being said, you should probably heed jozxyqk's comments. This is bad practice.
posted by NormieP at 11:38 AM on June 22, 2015 [1 favorite]
So I managed to tweak my /etc/hosts file to alias www to the IP address of the linode box from which www.nmhu.edu is hosted.
When typing just www in my browser address line in both firefox and chrome they interpreted that as a search string. I had to explicitly type http://www to get the behavior you described. Frankly I think that right there tells you that using www as a shortcut probably isn't so short since you have to add the http://, where as if you use the fqdn most browsers are smart enough to add the protocol for you.
Anyway, so with this new configuration I got the 404 page you described. One of the items listed on that page is:
"Did you add this domain to your install?"
Which is a clickable link to the wpengine's help documentation. If you follow the instructions there and add www to your domains list that should fix the problem (assuming that wpengine would allow you to this).
That being said, you should probably heed jozxyqk's comments. This is bad practice.
posted by NormieP at 11:38 AM on June 22, 2015 [1 favorite]
prove, via nslookup, which webserver you're actually hitting by IP address
If you're on Windows, be aware that the default behavior of Windows nslookup for bare hostnames is to append whatever domain name was handed out by the DHCP server. If you want nslookup to send a genuinely bare hostname to the DNS server, as your browser would typically do, you will need to add a trailing dot: nslookup www. will ask your DNS server to resolve www while nslookup www will probably ask it to resolve www.nmhu.edu.
Or you can use the ping command, which uses the same rules for DNS resolution that a browser would.
posted by flabdablet at 11:41 AM on June 22, 2015
If you're on Windows, be aware that the default behavior of Windows nslookup for bare hostnames is to append whatever domain name was handed out by the DHCP server. If you want nslookup to send a genuinely bare hostname to the DNS server, as your browser would typically do, you will need to add a trailing dot: nslookup www. will ask your DNS server to resolve www while nslookup www will probably ask it to resolve www.nmhu.edu.
Or you can use the ping command, which uses the same rules for DNS resolution that a browser would.
posted by flabdablet at 11:41 AM on June 22, 2015
Ack, so for some reason I thought that the linode machine this is hosted on was dedicated. I poked around, it is not (crazy88mma.com, for example, is also hosted from the same IP). There is essentially no chance that your shared hosting provider would allow you to make this configuration change since it would impact all of the domains hosted via that IP.
eschatfische, I think, nailed it in terms of a workaround. But with that, if your campus machine drops, then the shared hosting won't be reachable as www.nmhu.edu.
posted by NormieP at 12:00 PM on June 22, 2015
eschatfische, I think, nailed it in terms of a workaround. But with that, if your campus machine drops, then the shared hosting won't be reachable as www.nmhu.edu.
posted by NormieP at 12:00 PM on June 22, 2015
Response by poster: Thank you all so much - I feel like I have a better understanding of all this, that at least I didn't break things with DNS, and more importantly, that this is bad practice, and we shouldn't be trying to replicate it. One reason we're hosting off campus is concern for the local machine dropping, so probably we should skip all of the workaround. Thank you!
posted by korej at 12:22 PM on June 22, 2015 [1 favorite]
posted by korej at 12:22 PM on June 22, 2015 [1 favorite]
Eschatfiche's asnwer is correct. A particular server can host web pages for many sites. Requests for all of these sites typically come in on the same IP address, and the browser sends the host name it wants (e.g. www.nmhu.edu or www.example.com) along as a "host header". When you were hosting this on a dedicated machine, receiving just "www" in the host header didn't cause any confusion; now it's not enough to let the server determine whether you wanted www.nmhu.edu or www.example.com.
If there are no other sites hosted on this server it's just a matter of configuring it properly. I can tell you're hosting on Linode, but I'm not involved enough in this part of the industry to know if this would be a shared host or what.
posted by Horselover Fat at 9:29 PM on June 23, 2015
If there are no other sites hosted on this server it's just a matter of configuring it properly. I can tell you're hosting on Linode, but I'm not involved enough in this part of the industry to know if this would be a shared host or what.
posted by Horselover Fat at 9:29 PM on June 23, 2015
This thread is closed to new comments.
What I think you need to do on the webserver side is have a "VirtualHost" with the name "www" or a nameless "default" that directs to the root of your site.
I'm not familiar with wpengine, but I've done similar things with my own Apache configuration.
posted by jozxyqk at 8:57 AM on June 22, 2015 [1 favorite]