Microservices service discovery and configuration with DNS

If you are aiming for a microservice architecture everything is easy as long as the services do not have to communicate with each other. When this is necessary the services have to find each other.

Current solutions for service registration and discovery

This process is called service discovery and there are some newer solutions.

Standards for service discovery

Besides these implementations a lot of standards have own specifications for service discovery like:

Challenges of current solutions

I don’t think that a new solution is needed because solutions like Consul, Eureka and SnoopEE require the following:

  • You have to learn a proprietary API
  • You have to maintain an own service registry and discovery server
  • You have to use solutions that are mainly made for the Java world
  • It is unlikely that your choosen solution will be maintained for a long time
  • The given solutions are using a lot of ressources like main memory

Service discovery with DNS  SRV and TXT records

In this blog post I will emphasize on:

In short DNS SRV records.

I am proposing to use DNS SRV records for service lookups and encrypted TXT records for needed configurations. This is shown in the picture above.. Let me give you an example based on the microservice architecture shown in this blog post.

Example Microservice URLs

Let’s assume we have the following URLs for the services.

Name URL Description
https://production.example.com/ Main URL including Login
timetracking https://production.example.com/timetracking/ Timetracking Microservice
accouting https://production-accouting.example.com/ Accouting Microservice
invoicing https://production.example.com/invoicing/ Invoicing Microservice

SRV records

This would result in the following SRV records on the production.example.com domain:

Service TTL class SRV Priority Weight Port Target
_timetracking._tcp.production.example.com 60 IN SRV 10 100 443 production.example.com
_accouting._tcp.production.example.com 60 IN SRV 10 100 443 production-accouting.example.com
_invoicing._tcp.production.example.com 60 IN SRV 10 100 443 production.example.com


Currently two challenges are visible:

  1. The entry for invoicing and timetracking point to the same server and the url path is not given in the SRV record.
  2. If credentials or other configuration parameters are needed these are not given in the SRV records

Configuration with encrypted TXT records

My proposed solution for saving these information is to encrypt them with the public key of the SSL certificate that is used for production.example.com and then save the base64 encoded string in the TXT record for the given domain.


When encoding this with RSA and openssl ith the following command:
cat _timetracking._tcp.production.example.com.properties | openssl rsautl -encrypt -pubin -inkey public.pem -oaep | openssl base64

The following output will be created:

This will create the following TXT record
_timetracking._tcp.production.example.com. 60 IN TXT "biymNCFyc5kePbBPANirNKJwFWq5QnQKblFZiyCD/glKelnOCxwvLtnBjTPebXNIv/cUjLZUdrEd4lWkOoyPultcMseiIfwP8VAQtNVZnJcWjqiDUxSDCJGLWNzM4n6+rclRRYPyHinw9viga4Rl7jukWWs18bsGVRdk1xvDFVvGuyTn/VpZdWYiyd2pqxhOAtiB/dadQ3W5uCEu5per34vXQzwUJLeMXVAxA+45JqEQnWFrLIrWGA3dN/uHgL81iapmYO7J7rM7HoMHUqRnjkaz7POrJbQBu1XbvyY0odG8jX/pFqRdMvF+FlDTUvLGUatiFNsG/yiB69CpLMv5JA=="

This record can be decrypted to get back the local values.


Combined with the Microprofile Config API this solves the following service registry, discovery and configuration challenges:

  • No new infrastructure needed
  • Build on standards that are unlikely to change
  • Every programminc language has DNS lookup capabilities
  • A JSON Format
  • Tools for maintaining records on multiple providers
  • Dynamic reconfiguration possible when setting a low time-to-live
  • Continuous integration pipelines with build, test and production systems are supported
  • Uses the already available SSL public key infrastructure
  • DNS is proven to be super scalable, reliable and when using DNSSEC secure

Leave a Reply

Your email address will not be published. Required fields are marked *