k-v.io

A DNS-based Key-Value Store.

Quick Start

In the following examples, my-key is the key, and my-value is the value.

• To set a key: dig @ns.sslip.io put.my-value.my-key.k-v.io txt +short
• To get a key: dig @ns.sslip.io my-key.k-v.io txt +short
• To delete a key: dig @ns.sslip.io delete.my-key.k-v.io txt +short

Notes:

• Values are stored as TXT records.
• Keys must be valid DNS subdomains, i.e. only alphanumerics and dashes, and cannot exceed 63 characters. "my-key" is valid, but "my#key" is not.
• Values can be one or more subdomains, i.e. alphanumerics, dashes, and dots, and are truncated to 63 characters. For example, dig put.3.14159.pi.k-v.io txt +short sets the the key "pi" to the value "3.14159".
• If you need special characters ("!@#$%^😊"), consider Base32 encoding, but remember that the padding character ("=") is illegal.
• The three verbs are put, get, and delete, e.g. dig delete.pi.k-v.io txt +short.
• The verb get is the default verb: dig pi.k-v.io txt +short is identical to dig get.pi.k-v.io txt +short.
• There's no read security: when you set a key "my-super-secret-password" to the value "dont-tell-anyone", anyone can read it.
• There's no write security: you may set the key "best-rugby-team" to the value "all-blacks", and someone else could change it a minute later to "springboks".
• If you don't want someone to mess with your keys, you should probably use GUIDs or something fairly unique as a key, e.g. dig put.my-value.df616686-26e8-4da8-8104-a24aa0196bc7.k-v.io txt +short
• I have no idea how well this system will scale.
• I'll probably expire keys that haven't been accessed in a month, but I haven't written that code yet.
• This project is very much in beta. Assume you may lose your keys at any time.

DNS Caching/Propagation:

You don't need to specify our nameservers ("@ns.sslip.io") in your dig invocations if you don't mind dealing with the vagaries of DNS caching and propagation. Here are some of the problems you'll face:

• When you change or delete a key, it may take up to 3 minutes for the change to propagate due to DNS caching.
• DNS propagation/caching is particularly troublesome when doing multiple write operations on a key within a 3-minute period. The first one takes effect, the second one doesn't because it's cached at the upstream nameservers & never reaches the k-v.io nameservers.

Technical Notes:

• There are three servers that back this service: two in the USA, one in Singapore, on three different platforms: AWS, Azure, and Google Cloud.
• The underlying key-value store is an etcd cluster. I chose etcd for no particular reason other than it's what Kubernetes uses.
• The k-v.io source code is in Golang, is hosted at GitHub, and is licensed under the Apache 2.0 license.
• Much of the deployment information (terraform files, Kubernetes manifests) is also freely available at a different GitHub repo, and some of the workstation configuration is at a third GitHub repo. Yes, it's an organizational challenge.
• The DNS server code is a mash-up of key-value store and mapping hostnames with embedded IP addresses to those addresses (e.g. 127.0.0.1.sslip.io → 127.0.0.1). In a perfect world, I'd have separated the codebase into two and deployed k-v.io on a second set of three nameservers; however, I had neither the time nor the inclination to manage a 2nd set of DNS servers. So here we are.
• If you have suggestions (or notice that something's broken), please open a GitHub issue.
• I was motivated to create this service because at my job we use S3 as a key-value store, and getting at the keys is a challenge because we need the AWS credentials, and to get at those credentials we need to use CredHub (a Vault-like secrets store). It's a lot of hoops to jump through to find out something as innocuous as the version number of the latest candidate build.
• dnskv.com is a similar service with a rich set of options.