I would like to know if it is possible using IIS and ASP.NET (and ideally something that might be employed on a shared hosting account, but this isn't required) to mimic WordPress.com's ability to allow end users to use their own domain names.
WordPress has users who own their own domains change the domain's DNS settings to point to WordPress's own DNS. My guess is this is not something that would be able to be done on a shared hosting account since it would involve adding an entry to the DNS server's table for each custom user domain.
However, for future reference, is this something that might be automated programmatically on perhaps a VPS?
My guess is this is not something that would be able to be done on a shared hosting account
You're nearly correct. The default site in IIS listens to all connections on port 80 for the default IP address.
You can add more sites in 3 ways:
Add new sites listening on different ports. This is not entirely practical if you want "ordinary" sites litening on port 80.
Add more IP addresses to the box (not too eaisly done) and set up new IIS sites to listen to the new IP addresses independently.
Add new sites to the server listening to different "host headers" (domain names to you and I) but on the same (default) IP address .
So called "Shared hosting" usually uses options 3, because a hosting company can get away with only using a single IP address for possibly hundreds of sites.
Therefore you would have to go through the tedious process of adding each host header to the box, and while I'm almost certian this could be done with Wscript, I'm no expert in that area.
If you really wanted to get into it, you could write an ISAPI module to intercept the calls and set up some clever (ish) database/hash table of domain names and target folders to server as the different sites.
Bottom line is, there are various ways to achieve this on Windows. Probably none quite as easy as on a *nix platform where everything is super-scriptable.
What we do is have a wildcard DNS entry set up for our domain. That way, whatever domain the user types will resolve to our website as long as it ends with ".mydomain.com". Then our .Net code just looks at the "HOST" header coming in and serves up the content that matches that domain name.
Related
I have two websites running on IIS 7. Both require SSL. Ports for the websites are http:8080/https:443 and http:8087/https:443 respectively. I've created self signed certificate and put them into the Trusted Root. Contents of the both websites are the same. Here are my questions:
Do I have to make some changes to the hosts file as well? If so, what changes exactly, both on
server and clients
What do I have to type in the address bar in order to be able to open them? (Like 172.16.10.1/website1?) Do I have to specify the port numbers?
For http traffic, you can have many websites which can differ by IP or Port or Host Headers or a combination.
So in your case it is simple. For website1, you have site binding on port 8080, so the url becomes http://172.16.10.1:8080. Ditto for website2: http://172.16.10.1:8087 .
To make things simple, you can do a sitebinding on host header. So, bind the IP 172.16.10.1 with default port 80 to a host header say "www.website1.com" for the first website. Simlary for the other make the same combination bind to "www.website2.com". Now you don't need to specify port in the url. You can simply open both the websites by their respective names.
However, in case of https, it becomes a bit tricky. The certificates are installed on a per server basis. So, you have to specify different IP-Port combinations and host header binding won't work.
One option you have is to use a wildcard certificate which you can then secure-bind to each host-header.
The other option is to get a SAN Certificate (Subject Alternative Name Certificate). This will allow you to do a binding on different host headers with the same IP-port combination.
This excellent article on MSDN will help you understand it better: http://blogs.msdn.com/b/varunm/archive/2013/06/18/bind-multiple-sites-on-same-ip-address-and-port-in-ssl.aspx
Regarding the first part of your question:
You don't need to do anything with the hosts file. If you have a proper third-party certificate, it only needs to be registered on the server. The Intermediate and Trusted roots are already available on the clients. So nothing to be done on the client-side. You can open up "options" in IE and then check "certificates" under the "content" tab to see that a list of publishers is already there.
However, if you are using a self-cert, then the client-part is tricky. Because, the clients will keep on getting the "certificate is invalid" warning every time. One way out of this is to manually install the certificate on each client. Another way is to deploy the certificates to all clients using group policy.
We have a local instance of IIS 7 running with a website. Instead of the default "localhost" we have something like, mysite.compname.com. This is a separate entry into IIS 7 and the default website was removed to prevent confusion.
Then in our host file we an entry like this:
127.0.0.1 mysite.compname.com
Now when I try to hit this url, http://127.0.0.1/ApplicationName/Project/AddProject.aspx technically it should work, but instead I get a 404. I can vouch that this isn't a problem with the application, because if I navigate to http://mysite.compname.com/ApplicationName/Project/AddProject.aspx it works fine.
My end goal is to be able to give someone my computer name, so that they can visit a test page, so the url above I think would get turned into this http://computername/ApplicationName/Project/AddProject.aspx. Any help or at least links to understanding would help because I'm not sure where my issue is coming from.
It sounds like the IIS site / application is configured using a Host Header.
This means that the site will only respond if the host header sent by the browser matches the one configured for the site.
This is a standard method to allow one server to host sites for many host and domain names.
If you wish to allow others to view the site on your computer you will need to either have a local DNS server which you can edit, or, probably the easiest option, get them to edit their host files to include
<your IP> mysite.compname.com.
Remember to open the requisite ports (probably only 80, maybe 443 for https) in your firewall.
Or, you can try to edit the site config to remove or modify the Host Header requirement. See the first link for details, but be careful, it's easy to break things if you don't know the entire architecture of the site.
I'm running five wordpress sites (#EC2) all having it's own elastic IP tied to a proper domain name. I reached the max limit when wanted to launch another site (another domain).
Besides of the obvious; asking for more EIPs, can I use route 53 and pointing to the dynamic EC2 hostname?
As far as I understand this will destroy/mess-up all internal links of the wordpress instance, the moment I reboot or stop/start the instance, because it gets a new IP/hostname and all image-links of wordpress by default are absolute for SEO reasons.
Has anybody found a solution to this, or is my only option to ask for more EIPs?
In my opinion, requesting more EIP's is going to be the easier way to go.
You can set up your DNS to point the public ip of any instance, if its not an eip, it will change if the instance ever stop/started again. In which case you need to update DNS.
Wordpress doesn't really care what the hostname or ip address is of the instance. It cares what hostname you want it to respond to. Even if the underlying ip changes, as long as the hostname records are updated to the new IP, you wont have any issues.
I am currently building an web app which also utilizes websockets. (Rails for webserver and Nodejs for socket.io)
I have structured my application to use subdomains to separate between connection to the Nodejs server and the Rails webserver. I have "socket.mysite.com" redirected to the Node server and everything else to the webserver.
I am able to test this functionality on localhost. I simply modified my /etc/hosts to include the following:
127.0.0.1 socket.mysite.com
127.0.0.1 mysite.com
I know that on production I simply have to generate a CNAME record for socket.mysite.com and this will also work on my users' computers.
However, I am accustomed to testing my application by passing an IP address around. My team typically set up the server on our own machines and do development. When we want to test our individual servers, we just pass around an IP like "http://123.45.123.45".
With the new subdomain hack, this is no longer possible without modifying each of my tester's /etc/hosts. I honestly don't expect my testers to modify their /etc/hosts on the spot. What I can do is have each member of my team have their own domain and create the appropriate CNAME records for each individual team member.
Is there an easier way to allow me to run my app on an IP and just pass that IP around?
It sounds like your needs have scaled beyond the days of just simply editing a host file. While you could continue to have everyone on your team continue to edit host files, there are two main risks that I see here:
For your idea to just use IP Addresses, you risk missing something in testing that you wouldn't see unless you were on production, as the issue may be dependent on something in the domain configuration.
For using host entries, you introduce a lot of complexity and unnecessary changes to each developer and tester's configuration, which of course leaves the door open for mistakes, and it also takes time that will add-up over the long term.
Setting up a DNS server may be helpful in your case. You could map a set of domains for each developer that match a certain pattern so that your application will still run correctly. This would allow you to share the URLS without having to constantly reconfigure each person's computer. Additionally, marketing and sales stakeholders can easily view product demos as well, without needing to learn what the elusive host file is for.
If you have an IT department, they can help you setup the DNS. However, if you are a small team without a real IT department, some users have found success using DNS systems designed for home or small office networks.
How to efficiently create subdomains dynamically that are resolved to different IP than the original domain?
Most dynamic subdomain creation solutions I've found here would add a *.domain.com A-record to the DNS server (usually using BIND), but that's not what I want.
Does that mean the zone file needs to be set to always Expire? Wouldn't that tax our DNS server heavily?
However, what if the client ISP doesn't go and fetch the new zone file I just dynamically changed? Wouldn't they not able to resolve our new sub-domain entry?
Would setting up DDNS in BIND be the logical path for implementing such system? DDNS would allow me dynamically insert A-record without restarting BIND, right?
I'm sure there are some way to do this, since most large blogging service that doesn't point all account to the same IP as the blogging engine, are doing something similar to what I need.
Thank you!
Yes, you could use dynamic DNS updates to push zone file changes into your zone without having to put them into a text zone file and reloading BIND each time.
Many large domain name registries use exactly that technique whenever a domain name is registered.
That doesn't mean, though, that it's the right technique for your application. As recommended yesterday to your other question, there's really no reason not to go with the wildcard option.
A low-end server running Apache would be more than enough to front-end reverse proxy your first few thousand sites, and better still you don't even need to deploy it until you get enough users to set up your second partitioned cluster.
I would imagine that most services that do this have their wildcard (*.) DNS entry setup for these accounts, and probabley point it to a load balancer, that distributes requests based on host name etc. They then have the non-standard entrys setup as normal A records in DNS.