IP assignment for virtual webhosting

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <https://www.ripe.net/ripe/mail/archives/lir-wg/attachments/20000511/68416278/attachment.sig>