Check out RFC #1033 it appears to delve quite exstensively into this topic. George Greer wrote: > On Wed, 6 Dec 2000, Peter Ajamian wrote: > I was thinking of externally-hosted subdomains loaded locally, which is > what the /etc/named.conf editing could entail. > You mean secondaries? That would fall more under the category of DNS hosting than of providing a domain name. I wouldn't even bother trying to do that anyone who wants it can get DNS hosting from several other services, and with the NS method listed below can link up their myname.circlemud.net domain to work with it. > >> If you give us a hostname, we do a CNAME. If you give us an IP, we do an A > >> (authoritative) record. CNAME's aren't allowed to have MX records (or any > >> other information), IIRC. > >> > >Okay, I'm not positive about this, but I believe that a record CAN share > >CNAME and MX entries. What you cannot do is point an MX record to a > >CNAME record, the hostname that you specify on the RIGHT side of an MX > >record must have an A entry and will not work with a CNAME, you can do > >whatever you want for the hostname on the LEFT side, though. For > >example you couldn't do this... > > I seem to remember BIND griping, so I looked up the error: > > "%s has CNAME and other data (invalid)" > Yep, I was mistaken about that, apparently if you use a CNAME you can't have any other type of RR for that hostname. My suggestion would be to either allow a CNAME, two or more NS entries, or one or more an A entries and/or MX entries for a given hostname. Of course MX is pretty much optional, of you leave it out the mail server will follow the A entry (well, technically no MX entry is actually an implicit MX entry pointing to itself, RFC #974). > It'll also gripe about: > > "NS points to CNAME" > Yep, it is definately in error to point an NS entry (or any other type of record for that matter) to a CNAME. You can do one of two things, reply with an error if the user does this (this requires some amount of testing for the target name) or simply use the entry regardless and let the user be responsible for an invalid entry (worst case scenario is that that entry simply won't work, best case scenario is that it will work despite being in error). > Because it's hard to get the IP of the nameserver when you have to do a > lookup within that domain to get the nameserver for the domain. > In that scenario you're supposed to put in one or more A RRs for the nameserver(s). > >In fact, for those records that have a CNAME entry, I would highly > >recommend accompanying the entry with a corresponding MX entry as well, > >the reason is simple, mail servers will follow the MX entry, but they > >won't follow the CNAME... > > The MX record of the A record looked up by the CNAME is used. > Right, I got mixed up on the CNAME issue a bit, anyways, you can allow MX RRs and NS RRs as long as you don't allow them in conjunction with CNAME RRs, let the user be responsible as to weather or not a CNAME, MX or NS RR points to a CNAME. I've seen it work for a CNAME pointing to a CNAME but there's a danger of looping (not a good idea), not sure about MX and I know it won't work for NS. Regards, Peter -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/11/01 PDT