I just realised I probably need to correct an error:

> PowerDNS Recursor is the recursive-server matching element to PowerDNS
> Authoritative Server from the same folks. Both are back-ended into SQL

                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> databases (default MySQL). Consequently, it's also a bit heavy-weight,
^^^^^^^^^^^^^^^^^^^^^^^^^
> so I'd rule it out on those grounds.

My fading recollection (it's been a while since I worked with PowerDNS)
was playing tricks on me, I am pretty sure: The _authoritative_ package
back-ends into a SQL database[1], but on reflection I'm reasonably certain
that the recursive nameserver package doesn't, and instead just keeps a
cache in RAM just like Unbound, Deadwood, and BIND9.

So, sorry about that gaffe. I _still_ would not strongly recommend
PowerDNS Recursor with Unbound and Deadwood available as better
alternatives, because PowerDNS is just that little bit more slow, heavy,
large, etc.

I cannot recall whether djbdns's dnscache stores its cache in RAM or on
disk. I remember that something or somethings in the djbdns's toolkit
stores its records in Bernsein's cdb database, but that's probably the
tinydns authoritative-only nameserver.


[1] There are interesting consequences of this. Making a change to any
RR is an atomic operation: This change propagates to the other PowerDNS
Authoritative Server nodes via MySQL replication. Consequently, the S/N
subfield in the SOA record gets utterly ignored and its value in a zone
hosted on PowerDNS is devoid of meaning. There is no IXFR/AXFR zone
transfer functionality among the nodes, so no need to rely on S/N.