[HN Gopher] DNS Key Value Storage
       ___________________________________________________________________
        
       DNS Key Value Storage
        
       Author : Sami_Lehtinen
       Score  : 96 points
       Date   : 2021-01-03 08:12 UTC (1 days ago)
        
 (HTM) web link (dnskv.com)
 (TXT) w3m dump (dnskv.com)
        
       | hzengin wrote:
       | We used (route 53) private DNS records for feature toggles in my
       | previous company; worked better than most of the other solutions
       | tbh.
        
         | brightball wrote:
         | That's a really good use case IMO.
        
       | taylorwc wrote:
       | Corey Quinn from Last Week in AWS jokes about using Route53 as a
       | db often, including this hilarious twitter thread [0].
       | 
       | [0] https://twitter.com/quinnypig/status/1120653859561459712
        
       | ocdnix wrote:
       | With AWS Route 53's 10 000 records/zone, 400 values/record 255
       | chars/TXT and base64's ~35% overhead, you have a bit over 600
       | megabytes of binary value storage.
        
       | michaelmcmillan wrote:
       | DNS is actually pretty nice for ACL [1]. Just make sure you use
       | it with DNSSEC.
       | 
       | Want to check if Tom has access to /web/mike? Just do a lookup on
       | the user in question with the reversed path you want to check.
       | 
       | "Can Tom read /web/mike?" => tom.mike.web.server.net
       | 
       | Advantages:
       | 
       | - Replication to multiple machines is trivial (piggybacking of
       | DNS, after all).
       | 
       | - Lookups are extremely fast. Can also be easily cached.
       | 
       | - All sane programming languages have built-in DNS resolution in
       | their stdlib out-of-the-box.
       | 
       | - Manual override using /etc/hosts for debugging/emergency.
       | 
       | 1. https://itk.samfundet.no/dok/ITKACL2
        
         | axaxs wrote:
         | I love hacks for DNS, but this one feels a little bit of a
         | stretch. The absolute lack of security is probably the biggest
         | one. Now one can troll DNS for a user who has access to a
         | resource.
        
           | tiernano wrote:
           | Doesn't necessarily have to be public dns. Could be internal
           | to just your servers...
        
       | mprovost wrote:
       | The Hesiod system [0] used at MIT in the 80s is based on DNS. It
       | stored things like user (passwd) entries and which is the mail
       | server for an account as DNS TXT records. You could just query
       | the DNS server but there were also dedicated tools. [1]
       | 
       | [0] https://debathena.mit.edu/trac/wiki/Hesiod [1]
       | http://www.mit.edu/afs.new/athena/project/ctraining/presenta...
        
         | m463 wrote:
         | and of course the venerable NIS / yp lived parallel to DNS in
         | most organizations.
        
         | andyjpb wrote:
         | There is still Hesiod support in GlibC / NSS, etc on most
         | modern systems. When put together with Kerberos it's a nice way
         | to provision auth on lots of machines automatically.
         | 
         | It's nice to have a dedicated and restricted resolver config so
         | that the zone visibility can be restricted but that makes
         | deployment a little more complex.
        
         | dublin wrote:
         | +100 for use Hesiod. It solved this problem well and correctly
         | years ago, and just works. (It was also a key part of the
         | support for Carnegie-Mellon's Andrew networked filesystem.)
         | 
         | The seamless integration of all the Project Athena stuff
         | (Hesiod, Kerberos, etc.) with DEC Ultrix is one of many reasons
         | that Ultrix is still, IMO, the greatest Unix/;Unix-like distro
         | in history.
        
       | bluejekyll wrote:
       | I don't understand this:                 A, AAAA, TXT - set
       | record            A, AAAA - check key            TXT - read value
       | 
       | Dynamic DNS supports all of these options directly. Why are
       | additional records used for the key and value? IXFR could instead
       | be used to check if a record is up-to-date rather than
       | overloading A and AAAA in their meaning?
       | 
       | I'm probably missing something about how these records are meant
       | to be used together. Is there a protocol doc available?
        
         | kseistrup wrote:
         | The page says:                   Insert:         * value.key.
         | 
         | So if you                   $ dig txt value.key.dnskv.com
         | 
         | you will receive an "ok" if setting key=value succeeded. Then
         | if you                   $ dig txt key.dnskv.com
         | 
         | you will get the answer "value".
         | 
         | Read more of the page to find out what else you can do.
        
         | andyjpb wrote:
         | I can't find any docs other than what's on the page but my
         | reading suggests that the idea is that you can get/set values
         | "in-band" using a regular lookup query to a resolver rather
         | than the nsupdate style that you'd normally use to remotely
         | configure zones.
        
       | nannal wrote:
       | Cool toy:                   ;; ANSWER SECTION:
       | pressbutton.dnskv.com. 604740 IN TXT "nannal"
       | 
       | I played around with something similar on my domain, using DoH to
       | fetch txt values for page modification .                    dig
       | TXT nannal.com|grep status
       | 
       | Plan was to grab that, pipe it into a JS switch statement and
       | then change some CSS values based on the value.
        
       | frombody wrote:
       | I tend to like Cloudflare's API for key/value storage.
       | 
       | If you don't delete the record, the key will always have the same
       | id-number, so you never need more than a single API call to
       | reference a value or change it.
        
       | ignoramous wrote:
       | You'd think DNS KV Store's a "nice figment of imagination", but
       | one of the teams I worked for did use DNS TXT records genuinely
       | as a (faster) way to reconcile state between the control plane
       | and the data plane.
       | 
       | It sounded ugly on-paper, but the design was approved by everyone
       | in the chain of command for what I presume was for lack of other
       | viable options given the architecture.
       | 
       | And in ironic turn of events, instead of using DNS for service
       | discovery, another set of engineers in the team opted for EC2
       | metadata (for example, security groups) instead.
        
         | OJFord wrote:
         | I did something similar (for personal use) for a sort of 'peer
         | discovery' where load balancing didn't actually matter, I just
         | wanted to pick one of N without knowing where they are ahead of
         | time, using IPVS: https://github.com/OJFord/ipvs-txt-lb
         | 
         | To be honest I'm not sure if it's a total hack or a reasonable
         | use as intended, or somewhere in between. But it got it done,
         | and is at least more elegant than hard coding something
         | arbitrary which may change (just not too frequently), I think.
        
         | strictfp wrote:
         | I've used the AWS metadata trick as well. I kind of liked the
         | solution; better use something that the machine is already
         | relying on than adding something extra.
         | 
         | DNS is also usually a much better option than the framework-
         | specific service discovery mechanism that every framework seems
         | to be destined to reinvent. I think the problem is that most
         | computer scientists aren't very well-versed in networking, and
         | DNS doesn't look like the best match at first glance.
        
           | aECBNhWl4sqXr2 wrote:
           | I've done the same - tag EBS volumes with metadata rather
           | than having to maintain a separate datastore for a tiny
           | amount of information. Worked well.
        
         | alexfrydl wrote:
         | Using TXT records for this kind of thing is not that unusual.
         | For example, Kubernetes's external-dns uses TXT records to
         | track which entries it manages.
        
         | inopinatus wrote:
         | It should not be surprising to anyone that long-established
         | protocol standards are capable and versatile. DNS and LDAP are
         | robust tree-structured replicated attribute stores; mix in
         | Kerberos for a complete foundation of general purpose directory
         | services. NNTP supplies a straightforward Gossip protocol for
         | eventually-consistent distributed pub/sub. MQTT is still good
         | for lightweight telemetry. I have services I authenticate with
         | via Lamport's mostly forgotten scheme (S/KEY). And so on.
         | 
         | There is a current fad of HTTP+JSON as a generic protocol
         | substrate, but it's almost always a mediocre fit for the
         | problem at hand. Go read the RFC archives, there's diamonds to
         | be found.
         | 
         | On the other hand, and perhaps even by the same token: using
         | EC2 metadata isn't a completely terrible idea if it's the
         | infrastructure you already have and the semantics line up with
         | specific needs.
        
       ___________________________________________________________________
       (page generated 2021-01-04 23:01 UTC)