mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 11:15:54 +03:00
[GH-ISSUE #1803] Storage backend: Key-Value landscape #775
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#775
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @darnuria on GitHub (Oct 16, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1803
(to maintainers feel free to edit! it's a draft for now; Will try to edit with pro/cons later)
Right now Trust-Dns purpose only the following backends:
It might be pertinent to have a Key-Value based store, or even multiple.
In this ticket I share some of the research I already did personally.
From my experience, DNS involves a majority of read, and need to support quite nicely writes without locking all the reads, edge case like big zone edition are already showcased by CloudFlare but it might be covered into an other issue. Aka transactional read/write, thread aware is also a need.
It's important to note that Auth have to handle fastly and with a cache request because some domains has.... hundreds of RR.
A struct like Btree is handy for DNS search based on Name (sorted and iterable)
Related issues
Pertinent reads:
https://mozilla.github.io/firefox-browser-architecture/text/0017-lmdb-vs-leveldb.html
Sled
https://github.com/spacejam/sled
RKV
https://github.com/mozilla/rkv
Has a LMDB backend might need some commit in this backend to be fully prod ready, the Safe is prod ready.
LMDB
See also RKV
crate.iosearch: https://crates.io/keywords/lmdbAlready used by powerdns: https://github.com/PowerDNS/pdns/tree/master/modules/lmdbbackend
LevelDB
crate.iosearch: https://crates.io/search?q=leveldbRockDB
-https://github.com/rust-rocksdb/rust-rocksdb
Berkeley database 5.3
No really good binding, it's old, easy to shot your feet but do the job.
Agathe DB
https://github.com/tikv/agatedb
Still early.
SkyDB (AGPLV3) (not embeded)
https://github.com/skytable/skytable
Berkeley database from 6.x (AGPLV3)
No Rust binding, also worth noting that's AGPLv3 software from 6.x version.
@djc commented on GitHub (Oct 17, 2022):
I basically think we shouldn't take on more implementations like this in the server crate. As I see it, the server crate is already pretty undermaintained, and in my experience there are common use cases where the
Authoritytrait isn't even that helpful. It's also pretty easy to write your own backend, in my experience (I maintain aRequestHandlerthat's backed byRedis).@bluejekyll commented on GitHub (Nov 7, 2022):
Yeah, maybe we should look into supporting some dylib option for implementing custom backends and loading at runtime?
@darnuria commented on GitHub (Nov 17, 2022):
It's a dual edged sword. Have some experience with this part with PowerDns wouldn't say it's perfect it need a really good management of crash and signals to avoid leaving databases in bad state if they are in process space.
If a C-ABI is exposed it an other kind of beast and error (it need an interface for logging, managing failure and cleaning etc.)
Don't want to say it's "impossible" but would prefers having a solid mature Backend API before exposing a public external dynlib one.
It's only my humble opinion.
A "Thin" protocol remote API for external process backend is indeed interesting, would suggest avoiding JSON, XML or anything needing big parsing it kills a lot performance (already hit by process context change).