This is a long post because I want people on the list to see what has
led up to this point so I am quoting liberally.
George Greer wrote:
>
> On Sun, 3 Dec 2000, Peter Ajamian wrote:
>
> >I'm really not sure who to address this to, so I hope that you would
> >forward it to the appropriate party for me.
>
> It's me. I wrote mudreg.cgi although the idea was originally Jeremy's. I
> just integrated it with making a new sites.shtml for the web site.
>
> >1. *.yourdomain.circlemud.net optional entry. This would allow generic
> >forwarding of all sub-subdomains under the yourdomain.circlemud.net
> >subdomain to a particular server
>
> I'm not sure how we'd do this. I don't know of a way currently to make
> BIND return the same IP address for any random string in a subdomain. I've
> known of places that have done it, so it's probably possible somehow.
>
I'll give a chunk of the circlemud.net file as an example...
#nslookup
Default Server: localhost
Address: 127.0.0.1
> server CAMBOT.CIRCLEMUD.ORG.
Default Server: CAMBOT.CIRCLEMUD.ORG
Address: 128.9.160.111
> ls -d circlemud.net
[CAMBOT.CIRCLEMUD.ORG]
$ORIGIN circlemud.net.
@ 12H IN SOA cambot.circlemud.org.
jelson.circlemud.org. (
2000120603 ; serial
2H ; refresh
30M ; retry
6W ; expiry
12H ) ; minimum
12H IN NS cambot.circlemud.org.
12H IN NS dns.m-l.org.
12H IN MX 100 cambot.circlemud.org.
evelation 12H IN CNAME alpha.thewolvesden.net.
...
cog 12H IN CNAME bucket.ualr.edu.
exiled 12H IN CNAME exiledmud.org.
pathologicus 12H IN CNAME pl.inetsolve.com.
rhudin 12H IN A 64.32.50.81
eternal 12H IN CNAME eternal.outeractive.com.
none-5 12H IN CNAME monkey.csa.net.
nlh 12H IN CNAME nlh.mudservices.com.
Okay, I'll use my own subdomain (rhudin) as an example...
You could add an extra line after the rhudin entry like this...
pathologicus 12H IN CNAME pl.inetsolve.com.
rhudin 12H IN A 64.32.50.81
*.rhudin 12H IN A 64.32.50.81
eternal 12H IN CNAME eternal.outeractive.com.
This is a wildcard entry and it should have the effect of returning that
IN A record for every subdomain request to rhudin.circlemud.net. You
should also be able to do the same thing for a CNAME record, and I think
it will even work for NS and MX records, not sure though. Of course,
the resulting server would then be responsible for sorting out which
subdomain is being asked for (easily done with domain aliasing
techniques).
> >2. CNAME and MX entries for the subdomain. This would allow expanded
> >possibilites in terms of name aliasing and email forwarding.
>
> 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...
pathologicus 12H IN CNAME pl.inetsolve.com.
pathologicus 12H IN MX eternal.circlemud.net.
rhudin 12H IN A 64.32.50.81
eternal 12H IN CNAME eternal.outeractive.com.
...but you can do this...
pathologicus 12H IN CNAME pl.inetsolve.com.
pathologicus 12H IN MX rhudin.circlemud.net.
rhudin 12H IN A 64.32.50.81
eternal 12H IN CNAME eternal.outeractive.com.
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...
pathologicus 12H IN CNAME pl.inetsolve.com.
pathologicus 12H IN MX pl.inetsolve.com.
rhudin 12H IN A 64.32.50.81
eternal 12H IN CNAME eternal.outeractive.com.
eternal 12H IN MX eternal.outeractive.com.
> If we did subdomains, we wouldn't need to set that up ourselves anyway.
> The host server would in that case.
>
> >3. NS only entries. This would allow the name-holder to set up his own
> >DNS record on his own server(s), or use a 3rd-party DNS hosting service
> >so that he can have virtually unlimited flexibility with his
> >circlemud.net subdomain.
>
> I'm not sure how flexible we want to be. After all, we want the sites to
> be CircleMUD-related and allowing subdomains makes it harder on us to
> verify it's being used for such activity. (Not that it particularly matters
> to the computer, but as a matter of principle to us it does.)
>
> >This is just in consideration that it would ceartainly be nice to be
> >able to manage your own subdomains and have the option of making better
> >use of it with names such as www.yoursubdomain.circlemud.net and
> >majordomo.yoursubdomain.circlemud.net. I have always considered it
> >rather limiting to be restricted to simply yoursubdomain.circlemud.net.
>
> True, but we're not trying to compete with dhs.org or yi.org. Also, my
> understanding of BIND operation means we'd have to add a subdomain entry
> into /etc/named.conf (the server configuration file) every time we change
> it. Firstly, I don't have permission to edit that, nor would I want to.
> Secondly, messing that file up could take down every domain hosted on the
> machine. The current system just changes the zone loaded by BIND every
> night.
>
You don't need to mess with /etc/named.conf, you can do it like this...
pathologicus 12H IN CNAME pl.inetsolve.com.
rhudin 12H IN NS NS1.MYDNSHOST.NET.
rhudin 12H IN NS NS2.MYDNSHOST.NET.
eternal 12H IN CNAME eternal.outeractive.com.
This would basically tell the client to look at NS1.MYDNSHOST.NET to get
the record for rhudin.circlemud.net, I, in turn, would contract with the
"MYDNSHOST" company to provide me with DNS hosting service (or I might
use one or more of my own servers, or use a free service such as
centralinfo). Note that there are two DNS servers listed, this is
recommended for redundancy. You can also list three or more servers for
added redundancy.
> I can bring it up on the developer's list if you want, or you can mail the
> CircleMUD mailing list,
Alrighty. ;)
> but I don't expect it to be feasible. I'm not
> saying it won't be done. We'd debate it given favorable circumstances
> without implementation limitations. With what I have mentioned above, I
> don't think the risks would be worth it. Feel free to prove me wrong on
> the /etc/named.conf configuration issues though, that's the major sticking
> point.
--
+---------------------------------------------------------------+
| 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