People do the funniest things with DNS. It's a pretty good key-value
store, especially for read-heavy workloads.
Maybe you update counters for "what clients in this OT environment are
posting telemetry to this web server"? DNS wouldn't be a good choice for
that, but Redis is. But maybe you want to query for the info with the DNS;
as a bonus, DNS can offload / cache reads.
On Sat, 15 Oct 2022, Grant Taylor via bind-users wrote:
[...]
How does hosting the zone on an internal server provide any additional
security? Or are you simply relying on other security mechanisms to prevent
non-secure clients -- as Bob described them -- from accessing the server ~>
zone?
I feel like, by default -- as Bob described, any hosted zone is going to be
accessible by any client that can query the server.
DNS is federated, meaning that a server can be both a service and a
client, which means in the use case given above that the Redis instances
can be distributed close to where the counters are updated; the DNS will
go out and collect those counters when you query them, no need to send a
constant stream of telemetry to a central location.
You probably don't want those counters accessible to every dog on the
internet. Some thought is necessary in deploying DNS servers so that
intended clients get access. (We don't usually expect DNS clients to issue
hundreds of requests per second either, but it works; you just need to
give it some thought.)
I assume that people have been doing variations on this sort of thing
since PDPs were as common as LSD in Berkely.
The usual suspects arrive: TSIG, allowed addresses, firewall rules;
site-to-site VPNs; that sort of thing. Turns out RPZ is useful as a WAF
equivalent, limiting the Redis keys which can be queried as well as the
types of allowed queries.
Here is my contribution to ensuring employment for DNS subject matter
experts:
* https://github.com/m3047/rkvdns -- DNS proxy for Redis
* https://github.com/m3047/rkvdns_examples -- examples
--
Fred Morris, internet plumber
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
