Let's Talk Basic DNS

[Originally written on LinkedIn]

Let’s talk basic DNS.

Deep black magic, a slowly dying art in infrastructure teams. But, more importantly, let’s discuss the largest challenge in technology from engineering to infrastructure: naming things.

Fundamentally, there are two ways DNS is leveraged: external, what others need to see; and internal, information which is specifically for visibility to the infrastructure and development teams.

External, or public, DNS, provides an interface to the outside world. Things like api[.]example[.]com. This name also serves multiple functions, but key is abstraction. Abstractions are easier for humans to interact with, remember, or write. After all, what’s easier to remember, api[.]example[.]com, or abc123xyz[.]execute-api[.]us-east-1[.]amazonaws[.]com? Abstractions also make some things easier to manage or change pieces out from underneath, which allows for things like distributing traffic, geographic specific answers, and so on. Abstraction also allows you to effectively rename a resource to be not just human friendly, but resilient to outages, or other issues that would affect availability, or to point resources to a new record; although DNS clients may not always obey caching TTLs, or may choose to not repeat lookups to refresh CNAME members (looking at you, Varnish Cache…).

Internal DNS, or infrastructure DNS, should convey information about the infrastructure it represents. This means the name should tell you some detail, for example: is this instance production workloads? What application is it serving, or what service does it provide? What cluster member is it part of? Example layout can be fairly simple, it could be foo1-bar2[.]dc3[.example[.]com to something complex, like int-e4-sw1-c4[.]lon11[.]uk[.]e3-100[.]net. The goal here is minimizing contextual changes to enable infrastructure teams to quickly assess what’s affected, and where that system or device is, without having to resort to additional lookup tables or documentation.

There are additional DNS records that come in useful, for example text and service records (TXT and SRV, respectively), to help flesh out the infrastructure, or provide additional detail to the name. The goal here is to help ease access to information, and leverage known and familiar tools to help reference infrastructure. Or to provide automation tooling with additional information about the infrastructure.

After all, it’s almost always DNS.

And a special thanks to LinkedIn for forcing a defang of every hostname in this post by replacing them with URLs (hostnames are not URLs, but URLs can be hostnames…) and their link shortener.