Get a distributed service configuration database for free
Use DNS as a service configuration database
Although it is not usually considered as such, the Domain Name System (DNS) is one of oldest — and most frequently used — distributed key/value configuration database of the internet.
Most of us associate DNS with domain name resolution, domain registration, and sometimes speculative domain name trading. Actually, one of the primary functions of DNS is to resolve domain names to numerical IP addresses. It is less widely known that in addition to domain name resolution, it can be used to share a variety of information. One of such pieces of information is the so-called TXT resource record, where you can assign any optional text information to a given domain name.
So, the TXT resource record is a key/value entry, which can be used to store configuration properties.
Benefits
Basically, DNS is a distributed system. The data is automatically updated between the name servers that serve the given domain.
If a client initiates the resolution of a domain name, the intermediate name servers automatically cache the response. That is, in addition to the domain’s name servers, several other name servers are involved in caching the information, so that it gets to the client as soon as possible.
DNS is a free key/value database, that is, the providers don’t make extra charge for the data stored therein. There are absolutely free DNS name server services (such as CloudFlare, Hurricane Electric), where you don’t have to pay for the management of your domain either. Additionally, there are some free DNS domain registration services (e.g. Freenom), where you can register a set of domain names within a top-level domain.
Drawbacks
The data stored in the DNS is publicly accessible, that is, you don’t have any control over the users’ access to the data. You may face some problems, though, when you store a configuration in the DNS, as some of the configuration data may be sensible. Therefore, it is advised not to store your sensitive configuration data in the DNS, or you’d better store it in encrypted form.
Owing to the cache function, changes are displayed with some delay. The maximum delay time equals to the so-called time-to-live (ttl) value of the resource record. The minimum recommended value is 5 minutes, but some providers (e.g. CloudFlare) allow shorter delay times (e.g. 2 minutes). Normally, such a delay won’t cause any problem, but instantaneous configuration changes are not advised because of the delay.
As a result of its distributed nature and the cache function, the data stored in the DNS is not always consistent, it is considered as eventually consistent. In the majority of cases, this doesn’t cause a problem, however, owing to this feature, it is unfit for atomic configuration changes.
The size of the value stored in the TXT records is limited, maximum 255 characters long. More precisely, it is a string value, as multiple values can be assigned to the same name. These values, however, are managed and appended by the client. This is not a problem in the majority of the configuration settings.
Implementation
The TXT record associated with a given domain name may contain any string values, and you can store several values to the same domain name. This allows a mapping type, where the configuration properties are the domain names, and the configuration property values are the values included in the TXT record associated with the given name. This type of mapping allows you to easily manage array-type configuration property values as well.
property1 120 IN TXT "value1"
property2 120 IN TXT "value2"
array1 120 IN TXT "item2"
array1 120 IN TXT "item1"An alternative type of mapping is when the domain name only identifies the configuration object, and the configuration properties and their values are included in property=value format in the TXT record associated with the given domain name.
120 IN TXT "property1=value1"
120 IN TXT "property2=value2"
120 IN TXT "array1=item1"
120 IN TXT "array1=item2"The main advantage of this latter solution is that there is an RFC that defines this type of mapping (RFC 1464, RFC 6763) and as a result, it is more widely used and is supported by more opensource tools (e.g. sdget).
When to use
If you wish to separate service provision from configuration management, that is, delegate configuration management tasks, a DNS-based configuration may be very useful.
If there is a service, the provider of which wants the service to be customizable without requiring user registration, or the development of a configuration management interface, or running a separate instance of the service. In such a case, delegating the configuration to the user via DNS TXT records seems an obvious solution. Thus, the service needs one parameter, that is, the domain name, and the configuration is included in the TXT records associated with the given domain name. The DNS can be accessed fast enough, and can be re-accessed faster than any other key/value database, as the DNS data is cached by both the DNS servers and the local DNS resolver of the given running environment. On the other hand, the configuration can be freely customized by the users, under their own domain names.
Examples
There are several URL redirect services. The majority of them have their own admin interface and require user registration. The redirect.name, however, allows URL redirection without user registration, as the configuration of the registration is included in the CNAME and TXT records in the user’s domain.
The Forward Email service allows a custom domain to forward the email messages to an existing email address. The configuration of the forward function is included in the TXT records associated with the given domain, and no user registration is required.
The DNS-based service discovery is a basic or supplementary element of the service discovery in several microservices environments. A good example is SkyDNS or HashiCorp Consul.
The above examples inspired the management of the PhantAuth — random user generator + OpenID connect provider tenant configuration, also based on DNS. To customize the service, you need tenants. A tenant is a DNS name, and the associated TXT records contain the parameters of customization. Thus, the users of the system can change the operation of the service without having to run their own instance of the service. The customization extends to the configuration of third-party plugin-like modules called by PhantAuth via the REST API.
