EveryDNS tells me that pointing a separate domain to domains.wikispot.org using a CNAME record is prohibited by ![[WWW]](../wiki/eggheadbeta/img/sycamore-www.png){kind=small}
RFC 1034, section 3.6.2. Sure enough, the last two paragraphs in that section appear to say just that. (I wasn't sure at first, but the good folks at EveryDNS tend to know what they're talking about.)
Consequently, I've used "A" records to point the following ![[wcwiki]](../wiki/eggheadbeta/img/inter.png){kind=small}
Walnut Creek Wiki hostnames to 209.237.247.200 : walnutcreekwiki.org, wcwiki.org. For both of those, I used CNAME records to point www.[domain].org to [domain].org. I've verified that the changes took effect. —GrahamFreeman
You're misunderstanding. You don't point a domain to a separate domain, but rather you point www — a sub domain — using a CNAME to domains.wikispot.org. The domain itself, in this case wcwiki.org, would then have an A record point someplace that was doing an HTTP forward. Does this make sense? I'm not sure if EveryDNS itself provides such a forwarding service, but DomainDiscover may. It's been my experience that nearly all DNS providers do hosting of HTTP redirects in this way. I figured out how to do this using just everyDNS. I'll update these instructions soon, unless you beat me to it. Update: looks like EveryDNS supports this, but in a hackish way. I've emailed the EveryDNS support address with a request to add a simple feature that should make this possible. If EveryDNS is still in active development I would expect this change to happen on their side fairly soon unless there's something I'm misunderstanding. Until then, we should document the process with other domain providers, instead. —PhilipNeustrom
2007-04-12 19:48:33 I think having a domain point to a third-party HTTP forwarder is a bad idea. It needlessly introduces complexity, reduces security, imposes a performance hit, and is a point of likely failure. —GrahamFreeman
Like I said, EveryDNS provides an HTTP forwarding service but their UI just doesn't let you use it in conjunction with a domain you otherwise modify. Most other domain hosts do provide such a service. I've emailed EveryDNS but I haven't gotten a response from them. I suggest, in the mean time, not using EveryDNS. —PhilipNeustrom
2007-04-12 20:00:10 What I'm saying is that using an HTTP forwarder service is a bad idea. I don't think we should be recommending it - I think we're asking for trouble by doing so. —GrahamFreeman
What do you suggest instead? Do you remember the long email thread we had on the domain name subject (on the wiki spot list) after the EveryDNS outage? A records are a terrible idea for load reasons as well as "we need to change IP" reasons. Telling people to hand over their nameservers is also bad because not everyone wants to do that, and it also doesn't help if we need to quickly change nameservers (the original issue that spawned the discussion). As far as I know, this is the best way to let people use their own domains. It's not perfect, but the other solutions aren't, either. Also, why you think using an HTTP forward is a bad idea? In this case, it's merely forwarding non-www requests to 'www'. Most people will continue to bookmark and use the 'www' version of the page — which means there is no performance hit. As far as security — I don't know what you're referring to. It does introduce complexity into the setup process, but it is not needless. I agree that it sucks it's nasty sometimes, but I honestly can't think of anything that doesn't suck more. —PhilipNeustrom
2007-04-12 20:26:23 Using an HTTP forwarder introduces complexity (agreed), reduces security by allowing the HTTP forwarder service to hijack requests if they themselves are hacked, imposes a performance hit every time any request for [wikiname].org needs to first go to the HTTP forwarder service and then to Wiki Spot, and is a point of likely failure because there's a "middle-man" between the user who's requesting an HTTP-forwarded domain and Wiki Spot.
If the domain name provider gets hacked then they could mess with your domains anyway. There is no performance hit because 99% of people will link to and use the non-HTTP forwarded form of the domain. The non-www form of the domain is there mostly for people who type in the address in their URL bar. All subsequent requests go through the usual domain name without HTTP forwarding. The "middle man" in this case is the person's own domain name provider, so I don't see the "middle man" argument as convincing.
Restating the underlying challenge: DNS records point to IP addresses, and IP addresses sometimes change. Davis Wiki has gone through three IP address changes in the last 12 months or so, due to moving from a crappy shared host in New York to its own server in an excellent yet expensive colo in California, then to a cheaper yet still high-quality colo elsewhere in California, and now to a larger IP address pool (a /24 rather than a /27) due to growth of the cooperative colo that Wiki Spot uses. This is more change than will normally happen, but unless/until Wiki Spot becomes large enough to make use of BGP routing and its own RIR-allocated IP address space, it's entirely plausible that IP address changes will continue to happen. The problem is compounded when dozens or hundreds or thousands of wikis all use Wiki Spot as a hosting provider. Therefore, we (Wiki Spot) should have a plan and methodology that scales.
We do have a plan and methodology that scales, and it's the CNAME+HTTP forward plan we're using!
My suggested solution:
* By default, each Wiki Spot-hosted domain should have it DNS managed by a Wiki Spot team of three or four trusted individuals, each of whom has access to the relevant WHOIS records and DNS zone files. This team should use a publicly-viewable work tracking system to track their work. I'm partial to Request Tracker for the tracking system, but that's not the only good option.
-
I think that asking people to register a domain name and then give it to us introduces levels of complexity into the process that far exceed the complexity of these current instructions. Also, many people would not be comfortable giving their domain name to a third party. This also puts the burden of maintaining the domains on the Wiki Spot administration team.
* For those domains that aren't managed by Wiki Spot, they lose out on the benefits (and risks) of doing so. This means that they won't easily be able to be shifted to another server on a different IP address for performance or vendor change reasons. This should be made clear to the domain owners and wiki stakeholders so that they can make an informed decision.
-
And these remaining individuals must still have our name servers in place for their domain name. This isn't alway ideal for people, either (e.g. if they are doing anything else with their domain).
* Each wiki domain should have multiple authoritative DNS providers. Perhaps EveryDNS and Wiki Spot or Cernio. Having multiple providers allows for continued operations in the face of failure of any one provider.
