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.
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
