Question regarding web hosting ip addressing

Folks, could use some pointers.

I seem to remember from experience some years ago that if you were
hosting multiple domains for web hosting in a shared environment that
they needed to have individual IP numbers assigned specifically to the
domain, all sharing the interface, so things like AOL browser, etc.
would all work properly.

Am I out of date on this, or is it still common practice to assign a single
ip number to a single web hosted domain i.e.

hme0/1.2.3.1/www.test1.com
hme0/1.2.3.2/www.test2.com

...and so on and so forth?

Specifics would be helpful i.e. certain browsers, applications, etc.

Thanks.

Regards,

Folks, could use some pointers.

I seem to remember from experience some years ago that if you were
hosting multiple domains for web hosting in a shared environment that
they needed to have individual IP numbers assigned specifically to the
domain, all sharing the interface, so things like AOL browser, etc.
would all work properly.

I haven't heard of any problems with virtual hosting and client-side
browsers. The only caveat I'm aware of is that SSL-enabled virtual hosts
(i.e. https://foo.bar.bz) must have a unique IP per host, due to the nature
of SSL and certificates.

Am I out of date on this, or is it still common practice to assign a single
ip number to a single web hosted domain i.e.

hme0/1.2.3.1/www.test1.com
hme0/1.2.3.2/www.test2.com

...and so on and so forth?

Only for SSL vhosts. Otherwise, there are no problems (well, very few anyway)
that I am aware of in using a single IP to host as many vhosts as physical
resources will allow.

I'm quite certain somebody will correct me if I've missed something. :slight_smile:

http://httpd.apache.org/docs-2.0/vhosts/name-based.html

Summary: Name based if you can to save on addressing and if you don't need
SSL. IP Based for SSL and if customer insists for some strange reason. It
got really popular when ARIN said no more IP's for web addressing, then
they backed off of that idea.

I've set it up on IIS and Apache before. Pretty simple on both.

Gerald

hme0/1.2.3.1/www.test1.com
hme0/1.2.3.2/www.test2.com

It is probably better to attach the IP addresses to the loopback
interface rather than the ethernet interface.

-mark

Odd. I've run multiple "https:" sites on one IP. The browser
will complain about the certificate but you can always have

And therein lies the problem. :slight_smile: The last web host work I did had a few
bottom-lines rules, and one of them was do not confuse the end-users, because
that tends to either create support calls (whee) or send them to competitors.

a different certificate for each site while using one IP address.
(Correct me if I'm wrong!)

According to http://httpd.apache.org/docs/vhosts/name-based.html (thanks
Gerald), name-based hosting cannot be used with SSL due to the nature of the
SSL protocol.

correct. there's a specific technical problem due to the way that the https
protocol is designed; it's a chicken-and-egg problem.

specifically, name based identification of sites is based on the HTTP host
request-header field. in https, the certificates are processed before the
Host request-header is transmitted; Host is supposed to be inside the
encrypted tunnel.

a different design might have permitted named based https identification of
virtual web site, but they did what they did.

richard

> Odd. I've run multiple "https:" sites on one IP. The browser
> will complain about the certificate but you can always have
> a different certificate for each site while using one IP address.
> (Correct me if I'm wrong!)

You're wrong. :slight_smile: The SSL exchange happens before the HTTP protocol over
SSL can begin, and so the server has no idea which cert to send; or more
practically, just has one cert configured per (host,port).

There is a defined mechanism to do HTTPS over port 80 using a mechanism
called Upgrade and inband TLS. This will make it possible to do name
based vhosts and encryption, because you provide a Host: header along
with the Upgrade: TLS/1.0 header.

According to http://httpd.apache.org/docs/vhosts/name-based.html (thanks
Gerald), name-based hosting cannot be used with SSL due to the nature of the
SSL protocol.

Yep.

This thread lasted much longer than I think necessary for a simple
question, but I had to comment/correct one thing:

> > Odd. I've run multiple "https:" sites on one IP. The browser
> > will complain about the certificate but you can always have
> > a different certificate for each site while using one IP address.
> > (Correct me if I'm wrong!)

You're wrong. :slight_smile: The SSL exchange happens before the HTTP protocol over
SSL can begin, and so the server has no idea which cert to send; or more
practically, just has one cert configured per (host,port).

Careful. You could come accross harsh. The internet doesn't route
sarcasm well. What they are talking about is sorta possible.

You can setup Name-based virtual hosting and have 1 and only 1 SSL site on
that IP address. Any other sites on that IP that you setup with SSL get
the usual SSL complaint that the cert does not match the site name. This
is not acceptable for business class customers and as said before will
generate complaints.

SSL has to be tied to one IP, nothing says you can't virtual host the rest
of the http(without SSL) sites on that same IP (Even though that gets
messy pretty quick I think).

In practice/pricing it's easiest to just include the cost of one
additional IP on the machine for each SSL site and then name-based on
the server's primary IP won't cause you any problems.

## Examples...

This is the clean way to set it up:
# All name based hosts on the server would point to 10.4.10.1 in DNS.
10.4.10.1 # primary machine's IP setup for name based virtual hosting
10.4.10.2 # SSL site1 and alias1 IP on the network interface
10.4.10.2 # nonssl version of the same site1 on alias1 IP
10.4.10.3 # SSL site2 and alias2 IP on the network interface...etc
10.4.10.3 # nonssl version of site2 on alias2 IP (sometimes people don't
want or need the nonssl versions...but it works just the same.)

But this sorta works even if it is a bit unclean in my opinion:
10.4.10.1 # SSL site ssl.domain.com
10.4.10.1 # nonssl.domain.com
10.4.10.1 # nonssl2.domain.com
10.4.10.2 # SSL site 2 and alias1 on the network interface
10.4.10.2 # nonssl3.domain.com

We've strayed far from network operation discussion, and moved to web
server setup. I hope this will complete this thread. There is also
much of this similar discussion available on google since like I said
before it was a hot topic when ARIN temporarily changed their policy on
web server addressing.

If anyone wants more granular detail and this still doesn't make sense:
  - after reading the documentation from your web server
  - AND checking google groups for this discussion
  - e-mail me off list, but I can't promise to be as cordial there.
    ;-)

This is a stretch for a nanog discussion. (...though not the first)

Gerald

P.S. I'm a sysadmin not an English teacher. Grammar/Spelling problems
happen.