DNS Architecture
DNS Allows you to provide a human readable name that maps to an IP address. There are a few tricks and tradeoffs to consider though when organising it
DNS Architecting Best Practices
The following is a handful of do's and do nots when designing your DNS architecture:
Avoid Private IPs In Public DNS: Although helpful, and initially seemingly harmless, this practice exposes your internal network infrastructure setup through your DNS. Malicious actors can enumerate over this information and build a map of your internal networks, providing opportunities to find exploits in your current or future network setup
Fun Fact
As of May 2024 - AWS' EKS service, with private K8s API Endpoint, lists the private IPs on the public DNS endpoints. So even the big guys make these mistakes
Don't Use .local As A TLD For Private DNS: .local is used for multicasting, used commonly by Active Directory or network discovery tools. If you use this, you may potentially trigger a recursive broadcast throughout the network for every DNS lookup request
Use Dots Instead Of Dashes To Separate Domains: Dots (.) are segregation points in DNS. As your DNS setup gets more complicated, dots provide more flexibility points to breakup and organise your DNS records. That said, TLS/SSL wildcards only work for the dot level it is "wild for". abc.website.com is valid for *.website.com TLS/SSL wildcards, but useast1.abc.website.com is not. Using dashes (-) like - useast1-abc.website.com is valid for *.website.com TLS/SSL wildcards. If you are starting out, dashes may be a more affordable option. Just note that this may hinder future management complexity of your domains.
Public And Private IP Resolution
There are two common approaches here:
| Technique | Description | Example |
|---|---|---|
| Split Horizon | Same domains but served in different places. It relies on your private DNS server being faster and closer to your private services then the public DNS server. Thus your private services will receive private IPs and your public services, which can't reach your private DNS, will receive your public IPs |
|
| Seperate Domain | Seperate domains is where you have a different domain for your private traffic then for your public traffic |
|
Common Seperate Domain Patterns
Seperate Domains can mean multiple things. You can have them differential by TLD, be a subdomain of the other, or a completely different domain
Behind A Subdomain: A very common pattern is to put the private domains behind an intra or private subdomain under the root domain. This makes things quite obvious to anyone of what will return a public or private IP. Examples may look like this:
service.website.com- Returns the public IP for the serviceservice.intra.website.com- Returns the private IP for the service
The pattern is that anything behind intra.website.com will be private IPs. This also allows you to maintain whatever your DNS naming conventions you have, just simply slip an intra in between to differentiate public from private.
If your DNS setup is simple, this setup may allow you to use a wildcard TLS/SSL certificate for your private domains. You can create a wildcard *.intra.website.com certificate and serve everything under it.
Note
Wildcard certificates are only valid for the subdomain they "wild" for. If you have more elaborate domains with multiple layers of subdomains, a wildcard certificate will not be sufficient
Ex: abc.intra.website.com would be valid for the *.intra.website.com TLS/SSL certificate, but useast1.abc.intra.website.com is not valid. Many services do not support "double wildcards" or *.*.intra.website.com setups
Different TLDs: This setup has your public and private only differing by the TLD value:
service.website.com- Returns the Public IPservice.website.io- Returns the Private IP
The TLD can be anything, .io , .cloud, .whatever . What you choose though will depend on how you want to configure TLS/SSL with your domain and whether you are okay with the domain being public. If your TLS/SSL is all self-signed and private certificates, then any non-standard TLD can be used. You can use official TLDs, but this could be a source of confusion. More so if you do not own the TLD in your private domains. If you want to use automated TLS/SSL services like LetsEncrypt or ACME, you will need to pick a valid TLD. In this case you will also need to purchase the domain so that HTTP01 or DNS01 validation is able to prove you own the domain
If you are using a reverse proxy, you will also need to configure additional routes to support these new domains
Different Websites: This is the most extreme option, and may be more confusing then it is worth.
service.website.com- Returns Public IPservice.somethingelse.com- Returns Private IP
This setup faces the same issues as having different TLDs, but has an added confusion of a completely separate domain.
Split Horizon vs Seperate Domain Pro/Cons
Split Horizon is more Portable: Applications can try to resolve the same domain and regardless of where it is placed, will find the correct IP relative to where it belongs. IF application A wants to contact application B, and application A is in a private network it can receive application Bs private IP because the private DNS service will return faster. If application A is moved to somewhere outside the private network, it will get application B's public IP and nothing will have to be changed in its configuration to accomodate that.
Split Horizon also makes TLS/SSL certificates simpler as the domain it responds to is always the same. You can keep certificates explicite to the domain or subdomain and have them remain valid wherever the application sits, whether private or public
Services like LetsEncrypt also work better here because it can use DNS01 validation against your public IP but still provide a valid Certificate for your private endpoint
Split Horizon Financially Costs Less: Because of it using the same domain and ability to use the same certificates. Thats less domains to purchase and less certificates to handle or potentially purchase
Seperate Domains Are Easier To Debug: If the domains are the same, it can be harder to tell how your traffic is traversing your network. If the domain resolving your private IPs are different from the public ones, you can gaurantee where your applications will be resolving too
Seperate Private Domains Can Still Use LetsEncrypt With DNS01: You may think your private domain will need custom or manual certificates, but there is a way around this. As long as the private domain is publicly reachable somewhere , DNS01 will still work. You do not need to actually put any A, CNAME, etc records in that public location. DNS01 just needs to be able to add and validate TXT records at that location. This works for the root domain, subdomains and every level below that (sub-subdomains, sub-sub-subdomains, etc)
There are two caveats to this setup though:
- Your private domain does need to be a valid TLD and a domain you have purchased. Public DNS services require domains to be valid in order to host them.
- Having your private domain out in public does add an attack surface that can be enumerated over by malicious actors to deduce your internal infrastructure. It is a small change, assuming you do not store any records within the domain, but a more secure setup would be to not have the private DNS domains reachable at all from the public internet.
Seperate Domains Requires More Routing: With separate domains, your application or reverse proxy in-front of your application, will need to support both domains. This increases operational complexity of the service.