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
- 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 +shortsets 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
dig delete.pi.k-v.io txt +short.
- The verb
getis the default verb:
dig pi.k-v.io txt +shortis 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.
You don't need to specify our nameservers ("
@ns.sslip.io") in your
if you don't mind dealing with the vagaries of DNS caching and propagation. Here are some of the problems you'll
- 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.
- 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). 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.