3 ms·
Author here. Thanks, but I'm using DNS-as-a-database not DNS-as-given-data. Distinguishing feature: The command line example is using a DNS proxy to query a re
by m3047 4y ago
Author here. Thanks, but I'm using DNS-as-a-database not DNS-as-given-data.
Distinguishing feature: The command line example is using a DNS proxy to query a redis database containing netflow information.
It also utilizes DNS to query synthesized PTR records representing DNS-as-given-data (just not the data they want to give you most of the time).
DNS is the database.
- LinuxBender 4y agoAh so more like a Rbldnsd used in the RBL/RSL servers. I've run rbldnsd [1] as both a lookup for spammers/malware and as an authoritative server. Different data format than redis but same idea. [1] - https://github.com/spamhaus/rbldnsd https://github.com/spamhaus/rbldnsd
- m3047 4y agoYes, RBL is an example (I've worked for Vixie FWIW) of DNS-as-a-database. Another notorious example in the Indicator of Compromise sector is EDR (chiefly antivirus) software which uses the DNS to query the provenance of file hashes. The popular take on Redis is that it's good for caching. Well, the DNS is good for caching; Redis is good for a kind of caching that the DNS is not good at: write caching (if there is such a thing). Netflows are a good example: despite whatever measures you take, you're going to be writing the same flow artifact over and over (might as well increment a counter). It may never be queried (read). If it is read, it will probably be read a fair amount in a short period of time. Architecturally, you can have agents updating whatever you want in a Redis database; then when you need it... wherever you need it... you make a DNS query, separating read and write concerns. Put the Redis db close to the event source(s) instead of shipping all of it to a cloud. Agents are already being managed as fleets, so that's just current state of the art.