I've been doing a little bit with .dk lately, and I kind of like their model: DK Hostmaster handles almost everything. Due to lobbying from various hosting companies, there is an arbitrary restriction that you can't register a domain initially with them, but instead have to go through a registrar (same as in .com). I think this is mostly because it gives various hosting companies a chance to upsell you on email/Wordpress/whatever, since you have to go through one of them to get the domain. But then once you have the domain, you never have to deal with them again, because you subsequently do your yearly renewal directly through DK Hostmaster. You just log in, pay your $8.50 fee, and that's that. And unlike GoDaddy et al, they aren't trying to sell you a dozen services every time you try to renew.

>You just log in, pay your $8.50 fee, and that's that. And unlike GoDaddy et al, they aren't trying to sell you a dozen services every time you try to renew.

The registrars are pretty efficient, if you ask me. I think that part of the system isn't broken. Yeah, if you want to save every penny, godaddy does that, at the cost of the shitty service and upsells.

If you are willing to pay just a few bucks more, there are a lot of good registrars who don't up-sell you. Joker.com is my favorite. I think it comes to another four dollars a year; less than half a dollar a month.

$8.50 still seems quite high given you're paying them to let you use their interface to increment the expiry date on the domain. With the volume they have and once the system is set-up there's got to be almost no action to take beyond the maintenance of a few servers?

A registry is not just a MySQL database with some random domain names in it.

Have you considered what kind of resources and expertise that are required to handle issues such as domain name disputes? For example, suppose Alice and Bob run an informal business together, they have a clash and both of them make claims of the business' domain name. Or if Mallory registers someone elses company name and use it for nefarious purposes? [+]

[+] See http://swartz.typepad.com/texplorer/2006/04/wellknown_rock_.... for a particularly domain name anecdote involving Metallica and a Swedish VC firm.

Yeah, I'm not too sure what the expenses and finances are like. They mention that they manage ~1m domains, so that's ~$8-9m/yr revenue. Maybe a bit less if a substantial percentage of domains are doing 3-year or 5-year renewals (which are discounted 10-20%). Not a trivial amount, but it's not hard to spend a few million $ on salaries, office space, a server room, etc. It's possible the service is also sending a surplus to its owner, the nonprofit Danish Internet Forum, but I'm not sure if that's the case.

It hadn't even occurred to me that someone might have considerable control/ownership over large tracts of DNS servers. (Of course they do, I'd just never thought about it!). So anyway, I'd just like to say thanks, this is a really great explanation.

I worked for a registry a few years ago and the uptime the ICANN mandate are very very tough full redundancy on 4 separate continents.

Amazon, Google, Dnsmadeeasy, UltraDNS, Cloudflare all do it. I wouldn't say its that tough.

Disclaimer: Infrastructure engineer

Well maybe tough isn't the right word certainly expensive and unless your ex Telco and used to that level of redundancy a bit of a shock.

And Amazon AWS remind me how many major down time incidents have they had ;-)

> And Amazon AWS remind me how many major down time incidents have they had ;-)

Not sure if you were joking or not; I've managed thousands of instances in AWS across the world, and while us-east-1 continues to have issues occasionally, their DNS has been rock solid. Netflix uses them (with some UltraDNS for geolocation-based redirection, which Route53 doesn't support). That's good enough for me.

It's way easier to build a reliable DNS cluster than it is to build a reliable UNIX box.

Anycast works way better for UDP/dns than it does for TCP/http.

The idea behind Anycast is that you announce the address block your DNS cluster is on out many different locations around the world. At each location you have (usually a redundant cluster of) dns servers.

The router ahead of the IP of the person looking up an address on your nameserver will check it's bgp table, and then choose whichever location of yours is the fewest hops away. From that router's point of view, this is no different from you having one location with many different service providers.

If one of your locations goes away, it stops announcing the block, and all clients that would have gone to it instead use the next closest (hop-wise) location.

(this is actually one of the hard parts; if you have a setup where the dns server stops responding correctly but it's still announcing via bgp, you are broken.)

You generally don't use this for HTTP and other connection-based stuff, because a route flap is going to move your connection endpoint to an entirely new server. This causes a bunch of problems with your connection oriented stuff. (yes, you can sync connection state across servers... but the latency in that is going to kill you.)

I've built global anycast DNS clusters before :) Thanks for sharing the info though!

Protip: Perform service checks, and immediately withdraw your BGP route if a failure is detected.

Also, props for explaining why HTTP anycast is a pain in the casee. Even stateless it doesn't work well, which is why its usually done with DNS vs BGP/anycast.

>I've built global anycast DNS clusters before :)

Hah. I've only talked about it. It's one of those things I want to do before it's an obsolete skill, but it isn't at the top of my priority list.

You're not missing anything, trust me.

In terms of costs, keeping a few kb for the domain and associated contacts is almost nothing. Providing an API for resellers that is up 24h/24 is a bit more expensive but still doesn't justify the 8$/m. What's probably the biggest costs is the DNS servers. Verisign does have to have to maintain beefy DNS servers to reply to all .com subdomains queries.