Re: [LONG] subdomains

From: Peter Ajamian (
Date: 12/06/00

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.  * optional entry.  This would allow generic
> >forwarding of all sub-subdomains under the
> >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 file as an example...

Default Server:  localhost


> ls -d
@                       12H IN SOA (
                                        2000120603      ; serial
                                        2H              ; refresh
                                        30M             ; retry
                                        6W              ; expiry
                                        12H )           ; minimum

                        12H IN NS
                        12H IN NS
                        12H IN MX       100
evelation               12H IN CNAME


cog                     12H IN CNAME
exiled                  12H IN CNAME
pathologicus            12H IN CNAME
rhudin                  12H IN A
eternal                 12H IN CNAME
none-5                  12H IN CNAME
nlh                     12H IN CNAME

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
rhudin                  12H IN A
*.rhudin                12H IN A
eternal                 12H IN CNAME

This is a wildcard entry and it should have the effect of returning that
IN A record for every subdomain request to  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

> >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
pathologicus            12H IN MX
rhudin                  12H IN A
eternal                 12H IN CNAME

...but you can do this...

pathologicus            12H IN CNAME
pathologicus            12H IN MX
rhudin                  12H IN A
eternal                 12H IN CNAME

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
pathologicus            12H IN MX
rhudin                  12H IN A
eternal                 12H IN CNAME
eternal                 12H IN MX

> 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
> > 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 and
> >  I have always considered it
> >rather limiting to be restricted to simply
> True, but we're not trying to compete with or  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
rhudin                  12H IN NS       NS1.MYDNSHOST.NET.
rhudin                  12H IN NS       NS2.MYDNSHOST.NET.
eternal                 12H IN CNAME

This would basically tell the client to look at NS1.MYDNSHOST.NET to get
the record for, 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: |
   | Archives: |

This archive was generated by hypermail 2b30 : 04/11/01 PDT