Wait, so you've been turning DNS into a remote debugging and netflow/log analysis protocol?
I tried to understand the code and how it's used among the nodes. The thoughts in my head right now are similar to "wow this is so cool but I have no idea what it does".
I've been experimenting with DNS a lot lately, and e.g. used DNS exfil techniques to build a mesh router (mostly for privacy related reasons). [1]
But this kind of protocol layer inside PTR/TXT/URI(?) records could be really useful, as it could bypass firewalls which is super important while remote debugging a potentially compromised node. With DNSSEC or OPT record support, you could probably also reflect an authentication workflow, so that the following sessions could be handled in an encrypted-per-session manner.
Yeah, something like that I guess. "Debugging" implies for me a traffic volume which I don't intend to support. My thinking is based on properly segmented (DNS and DHCP properly implemented at the segment edge, not forwarded) networks, recognizing that diagnostics and evaluatives are distinct, doing the work to make evaluatives widely available in a controlled fashion, and remembering that diagnostic investigation will take place on the segment where complete logging is available. That sentence is way too long!
It's probably simpler than you think it is. ;-)
1: there's something producing diagnostic information which needs to be monitored
2: identify and construct evaluatives
3: put evaluatives in redis (e.g. rkvdns_examples/totalizers, but you can also write directly, see shodohflo/pcap_agent)
4: put RKVDNS in front of that (this is where the control plane ends)
5: put e.g. BIND in front of RKVDNS (BIND sits at the segment edge)
6: lie to the world that the BIND instance is authoritative (optionally hack BIND to always return AA, but never mind, nothing cares)
7: use the full set of features provided by BIND for access control, integrity, privacy
DNS as exfil / C&C can either bypass DNS infrastructure or embrace it; different mitigations / detection techniques accrue. (You just gave me an inspiration for an observable I should add to Rear View RPZ!) I'm not tunnelling protocols inside of DNS; our objectives are probably diametrically opposed, but ok! RKVDNS is meant to be a "data diode": you can get selected, curated data out but you can't put any data in.
DNSSEC is problematic for something like RKVDNS (as are zone transfers), doing negative proofs in particular. DNSSEC does not provide encryption; it provides proof of authenticity, and nonrepudiation / integrity. DNS can be used to publish public keys (DANE), and DNSSEC provides proof that the key belongs to someone / something.
I need to say an important thing here: DNS is a wire format, an algorithm, and an application layer protocol. That last one in particular seems to be something people want to wish away. Every (recursing) DNS server is like an HTTP proxy: what happens to proxy headers when you chain HTTP proxies?
Encryption is per-hop, each DNS server has access to the entire DNS question, and assembles its own response. DNSSEC provides identity across the entirety of the DNS; there is no encryption / privacy across the entirety of the DNS.
On a per-hop basis, encryption is provided by DoH and DoT. DoT is as simple as putting nginx in front of the nameserver (config templates used to be included with the BIND distro, I think Ondrej was responsible for that). You're more likely to have success implementing (key based) access management with DoT; if you don't need encryption, you can get access management and non-repudiation with TSIG (from BIND, RKVDNS doesn't support TSIG), on a per-hop basis.
The most common santa claus and easter bunny question I get is "why didn't my super special EDNS data make it to my authoritative server?": people truly wanna believe. That's because EDNS is per-hop; I don't care what Cisco or Microsoft say, ain't gonna happen. (That's another reason why you need true DNS at the segment edge, not forwarding.)
("My favorite programming language is the one with the least maintenance burden. If you find it, please let me know.": In my somewhat grizzled experience lack of dependency management is the biggest burden. I try to minimize dependencies and live off the land as much as possible.)
I'd love to see a demo. We should demo for each other. I will stalk you and attempt to send you an email. (Oh I see. I'll open an issue on GitHub then.)
On second thought, no I won't open an issue. I provide contact information here and on GitHub. Get in touch if you feel like it, you make it too hard to contact you.
I tried to understand the code and how it's used among the nodes. The thoughts in my head right now are similar to "wow this is so cool but I have no idea what it does".
I've been experimenting with DNS a lot lately, and e.g. used DNS exfil techniques to build a mesh router (mostly for privacy related reasons). [1]
But this kind of protocol layer inside PTR/TXT/URI(?) records could be really useful, as it could bypass firewalls which is super important while remote debugging a potentially compromised node. With DNSSEC or OPT record support, you could probably also reflect an authentication workflow, so that the following sessions could be handled in an encrypted-per-session manner.
[1] https://github.com/tholian-network/warps