Re: IP assignment for virtual webhosting
On Mon, 08 May 2000 18:26:19 +0200, Nurani Nimpuno wrote:
We do however wish to raise our concern regarding what we see as an inefficient usage of addresses in our limited address pool. 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).
There is one issue I'd like to bring up that we constantly run into and was never brought up in this debate, which somehow amazes me. Our typical situation is that when a customer orders a domain named web site it comes along with an FTP server and a POP-3 server so they can have their own email addresses. While we could host all customer pages on the same host with the same IP using HTTP 1.1, in order to do the same with the POP servers we need to distinguish the POP server by its single IP address, since there is no HTTP 1.1 equivalent for POP. So we end up with 99% of our domains having a different IP address each, in which case who _cares_ if we also use that IP address for the web server? Are we really wasting IP address space? Hasn't anybody run into this situation? If so, how are you dealing with it? We would ask that, unless a viable solution to this problem is found, name based hosting should be encouraged but not required. BTW we are adopting HTTP 1.1 name based virtual hosts anyway in case the FTP and POP issues could be solved. Regards Javier Llopis BitMailer, S.L. javier@bitmailer.com Juan Bravo 51, Dup. 1-Izq Tel: +34 91 402 1551 28006 Madrid Fax: +34 91 402 4115 SPAIN
On Thu, 11 May 2000, Javier Llopis wrote:
there is no HTTP 1.1 equivalent for POP. So we end up with 99% of our domains having a different IP address each, in which case who _cares_ if we also use that IP address for the web server?
Are we really wasting IP address space?
Hasn't anybody run into this situation? If so, how are you dealing with it?
Use one big POP3 server for all of your customers, and either use "standardized" pop-login names (ie, customercorp01, customercorp02, othercorp 01, othercorp02, etc) and entries in the alias file to point to them. It even makes sense to point mail.customerdomain.com as a cname to your mail.provider.whatever so that if there's a change you don't have to reconfigure all MUA's. As for ftp, it's easily solved by creating different home directories for different logins (don't forget to chroot them). So your customers will not get their own hostname in the login prompt, no big deal.... ;-) Nils - ----------------------------------------------------------------- - n@work Internet Informationssysteme GmbH Tel +49 40 23880900 Spaldingstrasse 160d Fax +49 40 23880929 20097 Hamburg, Germany http://www.work.de/
On Thu, May 11, 2000 at 11:55:25AM +0200, Nils Jeppe wrote:
It even makes sense to point mail.customerdomain.com as a cname to your mail.provider.whatever so that if there's a change you don't have to reconfigure all MUA's.
No. RFC 1912: "Common DNS Operational and Configuration Errors" 2.4 CNAME records [...] Don't use CNAMEs in combination with RRs which point to other names like MX, CNAME, PTR and NS. (PTR is an exception if you want to implement classless in-addr delegation.) For example, this is strongly discouraged: podunk.xx. IN MX mailhost mailhost IN CNAME mary mary IN A 1.2.3.4 [RFC 1034] in section 3.6.2 says this should not be done, and [RFC 974] explicitly states that MX records shall not point to an alias defined by a CNAME. This results in unnecessary indirection in accessing the data, and DNS resolvers and servers need to work more to get the answer. If you really want to do this, you can accomplish the same thing by using a preprocessor such as m4 on your host files.
As for ftp, it's easily solved by creating different home directories for different logins
Not, if you want to give your customers anonymous FTP space. Best regards, Daniel -- Entire Systems Network Operations Center noc@entire-systems.com Entire Systems GmbH - Ferbachstrasse 12 - 56203 Hoehr-Grenzhausen, Germany InterNIC-Handle: ES1238-ORG RIPE-Handle: ESN10-RIPE Tel: +49 2624 9550-55 GnuPG/PGP Key-ID: 0xBF3C40C9 http://www.entire-systems.com/noc/noc-key.asc GnuPG/PGP Fingerprint: 1F3F B675 1A38 D87C EB3C 6090 C6B9 DF48 BF3C 40C9
It even makes sense to point mail.customerdomain.com as a cname to your mail.provider.whatever so that if there's a change you don't have to reconfigure all MUA's.
No.
RFC 1912: "Common DNS Operational and Configuration Errors"
I believe the intention here is that primary MX for the domain is mail.provider.com (A record, easily changed at the DNS), and the SMTP server setting for customers' MUAs is mail.customerdomain.com (valid use of CNAME, easily changed at the DNS instead of manual reconfiguration). Regards, Dave -- dave.wilson@heanet.ie --------------------------------------- +353-1-662-3412 It is one thing to pray; it is another to pray to entities who might not only be listening, but who will search you out on the road and beat you across the head with sticks if you say something that offends them. -- Neil Gaiman ------------------ For crypto key send a blank message to davew+pgp@heanet.ie
On Thu, May 11, 2000 at 11:40:18AM +0100, Dave Wilson wrote:
I believe the intention here is that primary MX for the domain is mail.provider.com (A record, easily changed at the DNS), and the SMTP server setting for customers' MUAs is mail.customerdomain.com
Ah yes. I've overseen "M*U*A". Sure, that's fine. Best regards, Daniel Roesen Entire Systems NOC -- Entire Systems Network Operations Center noc@entire-systems.com Entire Systems GmbH - Ferbachstrasse 12 - 56203 Hoehr-Grenzhausen, Germany InterNIC-Handle: ES1238-ORG RIPE-Handle: ESN10-RIPE Tel: +49 2624 9550-55 GnuPG/PGP Key-ID: 0xBF3C40C9 http://www.entire-systems.com/noc/noc-key.asc GnuPG/PGP Fingerprint: 1F3F B675 1A38 D87C EB3C 6090 C6B9 DF48 BF3C 40C9
RFC 1912: "Common DNS Operational and Configuration Errors"
I believe the intention here is that primary MX for the domain is mail.provider.com (A record, easily changed at the DNS), and the SMTP server setting for customers' MUAs is mail.customerdomain.com (valid use of CNAME, easily changed at the DNS instead of manual reconfiguration).
That's a valid use of CNAME records in conjunction with mail handling, but about the only one. You still shouldn't combine MX and CNAME, which is what RFC1912 talks about in the previously quoted section. However, the text from RFC1912 is still valid (the example lacks the MX priority field, though ;-), but doesn't point out what the reason for the RFC 974 restriction is. So if you'll excuse me for flying off on a DNS tangent... The mail server presents itself with one name in its greeting message. Hopefully this name is a fully qualified domain name (probably mail.provider.com in the above example). This is the name you should be using as the target in an MX record when you want to use the mail service of that host. If you adhere to this rule, your mail server will correctly handle being a "secondary" mail handler for a domain (modulo any configured relaying restrictions), and recognize "itself" in a list of MX targets, and prune off itself and any lower- prioritized entries. If you don't, well..., you're doing something which is similar to walking around pointing a loaded and unsecured gun in the direction of your own foot. - Håvard
On Thu, May 11, 2000 at 11:41:58AM +0000, Javier Llopis wrote:
There is one issue I'd like to bring up that we constantly run into and was never brought up in this debate, which somehow amazes me.
And another one, not raised (enough): Accounting Best regards, Daniel -- Entire Systems Network Operations Center noc@entire-systems.com Entire Systems GmbH - Ferbachstrasse 12 - 56203 Hoehr-Grenzhausen, Germany InterNIC-Handle: ES1238-ORG RIPE-Handle: ESN10-RIPE Tel: +49 2624 9550-55 GnuPG/PGP Key-ID: 0xBF3C40C9 http://www.entire-systems.com/noc/noc-key.asc GnuPG/PGP Fingerprint: 1F3F B675 1A38 D87C EB3C 6090 C6B9 DF48 BF3C 40C9
participants (6)
-
Daniel Roesen -
Dave Wilson -
Entire Systems NOC
-
Havard.Eidnes＠runit.sintef.no -
Javier Llopis -
Nils Jeppe