It reminded me of this clever hack used to store the source code of DeCSS (CSS descrambler that let you bypass the DVD DRM) in DNS records: http://decss.zoy.org/ (method 9).

"Mark Baker noticed that you could do the request to any nameserver. Which means for instance that the DeCSS source code is available from the DVDCCA's nameservers !"

Classic.

Wish they would open source it. I would have preferred if they would have contributed to PowerDNS instead of reinventing the wheel. Was PowerDNS so awful it required a compete rewrite if so fair enough.

The other day CloudFlare's CEO stated the plan is to open source RRDNS: http://blog.cloudflare.com/cloudflares-new-waf-compiling-to-...

"We're planning on open sourcing RRDNS, the authoritative DNS server we built, when it gets to a state where it could be used by others."

+1 for open sourcing

One of the reasons they originally chose PowerDNS was that "it seamlessly allowed us to add new records without rebooting."

Can someone explain? What DNS server requires a reboot (or even restart) instead of a simple reload?

(I also chose PowerDNS years ago.)

I'm not sure about "rebooting" -- if this was just a language error -- but PowerDNS can run with a MySQL or Postgres backend with instant updates to records. i.e., no reload or other configuration re-read required.

With DB replication up and running, you can get a fairly robust domain name server pool going without the usual headaches associated with copying updates to multiple servers.

CF engineer here. The main pain point of pdns and CloudFlare was all the additional logic needed to support CloudFlare's cdn product. For example, for a given record, should this resolve to the origin server's IP or CloudFlare's edge node? In the case of an edge node, what particular set of CloudFlare's IPs should be returned. These are both user settable options, and need to be propagated to all dns servers in real time. Supporting this meant supporting an increasingly hacked up fork of pdns, with logic scattered though the code base. Eventually it became less work to build rrdns as a clean platform.

In terms of dns updates, see the blog post http://blog.cloudflare.com/kyoto_tycoon_with_postgresql for details on how CF does it now.

I like the way bind updates its child nodes and reloads/adds new records. It allows me to load only what I want, only when I want it done, not immediately. Not to mention the dependency nightmare of requiring a stable SQL backend just to serve virtually-always-static DNS requests...

I'm curious if cloudflare will ever just sell its anycast dns as a service.

Don't really need the other stuff but from what I can see their dns performance is on par with dnsmadeeasy/dyn/ultra

Wouldn't that obviate the need for third party CDN's?

While playing these kinds of games on security sensitive services might not seem like a good idea, it lets someone take ownership of its development, and gain experience with its codebase.

I imagine the switch over to TCP is more because the response is likely to be larger than a UDP packet (which IIRC is why DNS-over-TCP exists) (looks to be the case [1]), as opposed to stopping an amplified reflection attack, but it's a nice side effect.

[1] http://serverfault.com/questions/404840/when-do-dns-queries-...

Nope. Normal DNS behaviour is to send the first few records over UDP and set the response truncated flag, which would still allow amplified reflection. They're intentionally sending no records at all in order to protect against this.

Some name servers include partial rrsets in truncated responses, some decide it's best to omit the entire rrset, some decide it's best to omit that entire section. All of those behaviors are valid (RFC2181 section 9 is about as detailed as it gets). I think there's enough variety that really there's no "normal" for this.

Ah I see, thanks for the clarification.

I remember listening to a podcast where Steve Gibson mentioned that he uses a DNS TXT record to publish the current version of SpinRite. That way the program just does a DNS look-up to see if there is a newer version available.

Thought that was a clever trick. Saves a centralised server getting hit all the time (although you then miss out of usage information I guess.)

"For an even more useless, albeit fun Easter Egg, try querying for the CH record for whois.cloudflare against one of our name servers."

    $ dig ch whois.cloudflare @emma.ns.cloudflare.com
    whois.cloudflare.    86400    CH    TXT    "                                  IIIIIIIIIIIII                              "
    whois.cloudflare.    86400    CH    TXT    "                               IIIII,,,,,,,,,IIIII                           "
    whois.cloudflare.    86400    CH    TXT    "                             III?::::::::::::::::III    I                    "
    whois.cloudflare.    86400    CH    TXT    "                            III:::::::::::::::::::::III I      I             "
    whois.cloudflare.    86400    CH    TXT    "                           III~~~~~~~~~~~~~~~~~~~~~~~III II I I   I          "
    whois.cloudflare.    86400    CH    TXT    "                         II?=======IIIIIIIIIII========III? ???I  I           "
    whois.cloudflare.    86400    CH    TXT    "                 III    III+++++IIIIIIIIIIIIIIIII++++++II????????   I        "
    whois.cloudflare.    86400    CH    TXT    "              IIIIIIIIIIII????IIIIIIIIIIIIIIIIIIIII????III?????? ??I         "
    whois.cloudflare.    86400    CH    TXT    "             III,::~=++IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII???????? ?III     "
    whois.cloudflare.    86400    CH    TXT    "            III:~=+IIIIIIIIIIIIIIIIIIIIIII?IIIIIIIIIIIIIIII??????????        "
    whois.cloudflare.    86400    CH    TXT    "            II==+IIIIIIIIIIIIIIIIIIIIIIIIIIIII???IIIIIIIIII++++????????II    "
    whois.cloudflare.    86400    CH    TXT    "            II??IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII????IIII~:~++????         "
    whois.cloudflare.    86400    CH    TXT    "        IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII+=:,.IIIIIIIII?II        "
    whois.cloudflare.    86400    CH    TXT    "       IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII??++++~~=+I~~::,IIII     "
    whois.cloudflare.    86400    CH    TXT    "     IIII=====++IIIIIIIIIIIIIIIIIIIIIIIIIIIII??????IIIIIIIII???+===~~::III   "
    whois.cloudflare.    86400    CH    TXT    "   III======IIIIIIIIIIIIIIIIIIIIIIIIIII???IIIIIIIIIIIIIIIIIIIII?III++==~III  "
    whois.cloudflare.    86400    CH    TXT    "  III===IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII?IIIII+++III "
    whois.cloudflare.    86400    CH    TXT    "  II==777777777777777777777777777777777777777777777777777777777777I77777??II "
    whois.cloudflare.    86400    CH    TXT    " II=777777777777777777777777777777777777777777777777777777777777777777777III "
    whois.cloudflare.    86400    CH    TXT    " II$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$II "
    whois.cloudflare.    86400    CH    TXT    " IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII "

Easter eggs? In something as crucial as an authoritative DNS server? Is that wise?!?

There are easter eggs in many of the crucial services on the Internet. The HTTP status codes are the first that come to mind.

After all, what's the point of running a massive service if you can't have fun with it?

418 I'm a teapot

Are you implying web browsers[1] are not "crucial"?

1. Browsers were/are a prime location for Easter eggs.

I'm wondering how RRDNS compares to Unbound (unbound.net) ?

You're probably thinking of NSD, not unbound. RRDNS is an authoritative DNS server.

http://www.nlnetlabs.nl/projects/nsd/

We originally considered building of off Unbound. It is great product and plan on switching our internal recursors from PDNS Recursor to Unbound in the future. The decision to build our own was because we are heavy user of Nginx and really like the concept of being able to easily create new modules that can be inserted at different points in DNS response pipeline. We will be blogging a lot more about the technical aspects of RRDNS in the future.