k-v.io
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
, anddelete
, 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 todig 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.