DNSControl is an opinionated system. That means that we have certain opinions about how things should work.
This page documents those opinions.
Code is written in a high-level language, version controlled, commented, tested, and reviewed by a third party… and all of that happens before it goes into production.
DNS information should be stored in a version control system, like Git or Mercurial, and receive all the benefits of using VCS. Changes should be in the form of PRs that are approved by someone-other-than-you.
DNS information should be tested for syntax, pass unit tests and policy tests, all in an automated CI system that assures all changes are made the same way. (We don’t provide a CI system, but DNSControl makes it easy to use one; and not use one when an emergency update is needed.)
Pushing the changes into production should be effortless, not requiring people to know which domains are on which providers, or that certain providers do things differently that others. The credentials for updates should be controlled such that anyone can write a PR, but not everyone has access to the credentials.
The goal of DNSControl is to create a system that is set up by DNS experts like you, but updates and changes can be made by your coworkers who aren’t DNS experts.
Things your coworkers should not have to know:
Your coworkers should not have to know obscure DNS technical knowledge. That’s your job.
Your coworkers should not have to know what happens in ambiguous situations. That’s your job.
Your coworkers should be able to submit PRs to dnsconfig.js for you to approve; preferably via a CI system that does rudimentary checks before you even have to see the PR.
Your coworkers should be able to figure out the language without much training. The system should block them from doing dangerous things (even if they are technically legal).
A zonefile can list any kind of DNS record. It has no judgement and no morals. It will let you do bad practices as long as the bits are RFC-compliant.
dnsconfig.js is a high-level description of your DNS zone data. Being high-level permits the code to understand intent, and stop bad behavior.
TODO: List an example.
DNSControl downcases all DNS names (domains, labels, and targets). #sorrynotsorry
When the system reads dnsconfig.js or receives data from DNS providers, the DNS names are downcased.
This reduces code complexity, reduces the number of edge-cases that must be tested, and makes the system safer to operate.
Yes, we know that DNS is case insensitive. See Opinion #3.
When possible, dnsconfig.js lists a high-level description of what is desired and the compiler does the hard work for you.
When there is ambiguity an expert knows what the system will do. Your coworkers should not be expected to be experts. (See Opinion #2).
We would rather DNSControl error out than require users to be DNS experts.
We know that “bar.com.” is a FQDN because it ends with a dot.
Is “bar.com” a FQDN? Well, obviously it is, because it already ends with “.com” and we all know that “bar.com.bar.com” is probably not what the user intended.
We know that “bar” is not an FQDN because it doesn’t contain any dots.
Is “meta.xyz” a FQDN?
That’s ambiguous. If the user knows that “xyz” is a top level domain (TLD) then it is obvious that it is a FQDN. However, can anyone really memorize all the TLDSs? There used to be just gov/edu/com/mil/org/net and everyone could memorize them easily. As of 2000, there are many, many, more. You can’t memorize them all. In fact, even before 2000 you couldn’t memorize them all. (In fact, you didn’t even realize that we left out “int”!)
“xyz” became a TLD in June 2014. Thus, after 2014 a system like DNSControl would have to act differently. We don’t want to be surprised by changes like that.
Therefore, we require all CNAME, MX, and NS targets to be FQDNs (they must end with a “.”), or to be a shortname (no dots at all). Everything else is ambiguous and therefore an error.