RE: IP assignment for virtual webhosting

But surely www.big-importantco.com would have their own machine and wouldn't share with www.my-little-home-page.org ? We try to apply the rule that you should only have unique addresses for ssl servers that can't do IP-less or some other server protocol that can't support it. Many of our customers grumble at first but soon realise that they can add their own IP-less virtuals without need to involve our admin department. All that's needed is a little DNS and the whole job can be completed in a day! My two pence Cheers Matthew -----Original Message----- From: Robert Kiessling [mailto:Robert.Kiessling@de.easynet.net] Sent: 08 May 2000 17:37 To: Nurani Nimpuno Cc: lir-wg@ripe.net Subject: IP assignment for virtual webhosting Nurani Nimpuno writes:
We would therefore like to request the community to consider making it mandatory for NEW installations to use domain based web-hosting, with the exception of a set of agreed applications needing IP based web-hosting (eg. SSL).
So you would require servers like www.siemens.de to share an IP address with www.my-completely-unimportant-personal-site.de if there is no SSL or similar use? I would suggest to make exceptions for heavily used sites, too. Since the vast mayority of webservers does not fall into this category, this is no waste of address space. Robert

I hate jumping into such a contentious issue, but the very fact that it is contentious, and that it will potentially impact both my employer, Teleglobe, and its customers, I have an obligation to point out several technical issues. I'll start with some recent threads:
But surely www.big-importantco.com would have their own machine and wouldn't share with www.my-little-home-page.org ?
The issue with non-IP based virtuals, is the difficulty and complexity, and more important, time-sensitivity involved, in *relocating* between servers. DNS-based virtuals are impacted by caching resolvers, which are ubiquitous. Lowering timers has risk too, especially if load spikes occur, eg for longer than timer values. If everyone is aware of the "slashdot" effect, then you can appreciate wanting to move such a "slashdotted" site to a separate server (or server farm), in a timeframe less than the DNS normal-TTL-value times. Not doing so would have a serious negative impact on 100 little-domains, who may have SLA's with you. Replace "slashdot" with "IPO" or "new software release", or any of a dozen other usage-spike events; each customer has their own traffic trigger, and the ISP won't necessarily have adequate warning. Three days is way too long; even three hours can result in bad press, angry customers, and cancelled contracts.
Nurani Nimpuno writes:
We would therefore like to request the community to consider making it mandatory for NEW installations to use domain based web-hosting, with the exception of a set of agreed applications needing IP based web-hosting (eg. SSL).
I think there are a number of issues concerning the definition of "NEW". Perhaps the only one to which most will agree is a square-one startup, with no pre-existing hardware, software, or address space. New address space, new servers, or even a new upstream, resulting in a mandatory upgrade places undue burden on any affected company, not the least of which is management systems for a new hosting system. And even there, there is another issue - the digital divide, the technical haves and have-nots. The first and third world. While there may not be as many RIPE members with customers in that category, the fact that *any* do means the policy must, IMHO, be sensitive to such issues. (Any RIPE members with offices in certain countries, eg USA, may be under legal obligation to do so, even if their head office, and/or customer, are not in said country.) There are many parts of the world, which would include parts of Europe which were formerly Iron Curtain countries, where the general expertese, available hardware and software, and language barriers, combined with newly-established free-market economies, put high demand for technology in the hands of the technical newbies, who are soooo far back on the learning curve that there is zero chance of them being proficient enough to deploy and configure DNS-based virtual domains as their first hosting service in a correct, or timely, fashion. I believe, that while it is admirable to encourage, strongly, those who can, to do DNS-based IP, that sufficient arguments in several areas run counter to mandatory policies for this technology. The vast majority of RIPE members are, I believe, commercial entities. Any policy which makes it necessary to turn away customers, would send the wrong message to the market in general. We all benefit from fair and open competition. If we permit "grandfathering" of IP-based virtuals, then to not permit new applicants to do so is ever-so-slightly unfair. ISPs need address space; this is a commercial issue for them. While we may hold ignorance and incompetence in contempt, (and I do, personally), I don't believe it is sufficient justification for the commercial impact of denying IP address space which is otherwise justified (via IP-based virtual hosting.) My two cents worth. -- Brian Dickson, Email: briand@teleglobe.net Director, Backbone Engineering Tel : +1 703 755 2056 Teleglobe Communications Corp., Fax : +1 703 755 2648 Rm 3214, 11480 Commerce Park Drive, Cell : +1 703 851 9053 Reston, Virginia, USA, 20191 http://www.teleglobe.com

Brian Dickson said:
I think there are a number of issues concerning the definition of "NEW".
Perhaps the only one to which most will agree is a square-one startup, with no pre-existing hardware, software, or address space.
Sorry, but I *don't* agree. Put cynically (and I know that the people proposing this aren't being cynical), this says: The people in the business right now are introducing a rule that places new entrants at a disadvantage. This will prevent them from competing on an equal footing. This is called a "cartel" in most places, and is illegal in several countries (including the UK and, I believe, all of the EU) unless it can be specifically justified. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8371 1138 Internet Expert | Home: <clive@davros.org> | Fax: +44 20 8371 1037 Demon Internet | WWW: http://www.davros.org | DFax: +44 20 8371 4037 Thus plc | | Mobile: +44 7973 377646

At 21:29 9-05-00 -0400, Brian Dickson wrote:
The issue with non-IP based virtuals, is the difficulty and complexity, and more important, time-sensitivity involved, in *relocating* between servers. DNS-based virtuals are impacted by caching resolvers, which are ubiquitous. Lowering timers has risk too, especially if load spikes occur, eg for longer than timer values.
If everyone is aware of the "slashdot" effect, then you can appreciate wanting to move such a "slashdotted" site to a separate server (or server farm), in a timeframe less than the DNS normal-TTL-value times. Not doing so would have a serious negative impact on 100 little-domains, who may have SLA's with you.
Replace "slashdot" with "IPO" or "new software release", or any of a dozen other usage-spike events; each customer has their own traffic trigger, and the ISP won't necessarily have adequate warning. Three days is way too long; even three hours can result in bad press, angry customers, and cancelled contracts.
How to move a hostname based virtual webserver: I have to webservers A and B (10.0.0.1) and (10.0.0.2) and want to move site www.cust.com from A to B The config on A is at the moment <VirtualHost 10.0.0.1> ServerName www.cust.com DocumentRoot ... </VirtualHost> Now move the data to B, change the nameserver entry for www.cust.com to point to 10.0.0.2 and create a www2.cust.com also to point to 10.0.0.2. The config file on B becomes <VirtualHost 10.0.0.2> ServerName www.cust.com ServerAlias www2.cust.com DocumentRoot ... </VirtualHost> and the config on A becomes <VirtualHost 10.0.0.1> ServerName www.cust.com Redirect / http://www2.cust.com/ </VirtualHost> So all request still coming in into A are redirected to the new name www2 (no DNS cache) and the DNS servers that are up to date go directly to B. Wait some time and remove the www2 entry from the DNS and clean up the config files. Hope this helps somewhat Regards Niek Rijnbout Knoware.
participants (4)
-
Brian Dickson
-
Clive D.W. Feather
-
Matthew Robinson
-
Niek Rijnbout