AND

AND.

AND, and previously, R-Squared were vapourware DNS servers, but please, read on.

Rationale

There are two use cases:

1. A massive, globally coherent, caching DNS.
2. A seriously large, authoritative DNS server.

Who would benefit from such things? Obviously ISPs would, but a community run version of either could mean we are no longer reliant on the big companies (e.g. Google & OpenDNS for caching, and AWS & Google Cloud for authoritative servers). In a world where free speech is being threatened so a big company could remove your authoritative name server, and where people are worried about their DNS requests being monitored, a community alternative could be a good idea (even if the design is totally different to mine).

Design

Perhaps the simplest designs are the best, which is why this is so short.

1. Store all the data in a sharded, key-value store, which natively supports TTLs.
2. Have multiple front-ends: all of which are equal: no masters and no secondaries.

And that's it. Redis is the original choice for storing the data. For the "front end", since envisioning the idea, CoreDNS has come on the scene and:

1. It's already a DNS server: no TCP/UDP server or custom DNS daemon code to write
2. Has an awesome middleware layer, which means we can just implement this as a plugin

So we should stand on the shoulders of giants, not reimplement the wheel and do a CoreDNS Middleware + Redis-based proof-of-concept, just to see if this: works at all; is a usable design; performs and scales.

Early optimisation is always a bad thing, so this may not be necessary. I've written it here, because it's a common design pattern for large-scale systems (because it's a common problem for them): put a(nother) (set of) DNS caches in front.

• For a caching-only name server, any caching-only name server will do and this could help with (locally?) hot zone records
• However, authoratitive name servers would need the caches to act like slaves and needs more thought.

And I repeat: this may not be necessary.

Sample prototype

A very small Perl prototype of how simple it is to store data appears in its own repo: andns-prototype.

A Favo(u)r

Can I first ask you a favour? If you read this (brief) design and choose to implement it, please credit me. I've failed to write this name server for many years, so I want the design out there in the open. It's more important that someone writes it than I sit here with it in my head, jealously keeping it secret, then releasing it to the world, fully complete. Watch this video to see why that's innefective, stupid, and egotistic. (Although I am still violating one of the ideas in this video: announcing too early, with no real code).

I am an unnecessary component of any implementation: go ahead and do it without me. Just please mention me somewhere.

(Although since first coming up with this, I realised that AWS Route 53 and others may well already be designed in the same way, so it may not be original. Alternatively, it could suck, and now I look like an arrogant <swear-word>.)

History

My first attempt R-Squared was an attempt/PoC using Ruby and Redis (hence R²). Then I was going to write AND (Another Name Daemon) in C for no better reason than it would be fun and more hardcore.

1. 2013 R Squared's empty repo.
2. 2013 R Squared Message: RFC 1035 messages in ruby (unfinished)
3. 2014 AND(NS): Aborted C implementation
4. 2014 Prototype: Perl demo of storing data in Redis
5. 2017 Design released: let's build this for the community and for the world