github.com/philhug/dnscontrol@v0.2.4-0.20180625181521-921fa9849001/docs/opinions.md (about) 1 --- 2 layout: default 3 title: An Opinionated System 4 --- 5 6 # DNSControl is an opinionated system 7 8 DNSControl is an opinionated system. That means that we have certain 9 opinions about how things should work. 10 11 This page documents those opinions. 12 13 14 # Opinion #1: DNS should be treated like code. 15 16 Code is written in a high-level language, version controlled, 17 commented, tested, and reviewed by a third party... and all of that 18 happens before it goes into production. 19 20 DNS information should be stored in a version control system, like 21 Git or Mercurial, and receive all the benefits of using VCS. Changes 22 should be in the form of PRs that are approved by someone-other-than-you. 23 24 DNS information should be tested for syntax, pass unit tests and 25 policy tests, all in an automated CI system that assures all changes 26 are made the same way. (We don't provide a CI system, but DNSControl 27 makes it easy to use one; and not use one when an emergency update 28 is needed.) 29 30 Pushing the changes into production should be effortless, not 31 requiring people to know which domains are on which providers, or 32 that certain providers do things differently that others. The 33 credentials for updates should be controlled such that anyone can 34 write a PR, but not everyone has access to the credentials. 35 36 37 # Opinion #2: Non-experts should be able to safely make DNS changes. 38 39 The goal of DNSControl is to create a system that is set up by DNS 40 experts like you, but updates and changes can be made by your 41 coworkers who aren't DNS experts. 42 43 Things your coworkers should not have to know: 44 45 Your coworkers should not have to know obscure DNS technical 46 knowledge. That's your job. 47 48 Your coworkers should not have to know what happens in ambiguous 49 situations. That's your job. 50 51 Your coworkers should be able to submit PRs to dnsconfig.js for you 52 to approve; preferably via a CI system that does rudimentary checks 53 before you even have to see the PR. 54 55 Your coworkers should be able to figure out the language without 56 much training. The system should block them from doing dangerous 57 things (even if they are technically legal). 58 59 60 # Opinion #3: dnsconfig.js are not zonefiles. 61 62 A zonefile can list any kind of DNS record. It has no judgement and 63 no morals. It will let you do bad practices as long as the bits are 64 RFC-compliant. 65 66 dnsconfig.js is a high-level description of your DNS zone data. 67 Being high-level permits the code to understand intent, and stop 68 bad behavior. 69 70 TODO: List an example. 71 72 73 # Opinion #4: All DNS is lowercase for languages that have such a concept. 74 75 DNSControl downcases all DNS names (domains, labels, and targets). #sorrynotsorry 76 77 When the system reads dnsconfig.js or receives data from DNS providers, 78 the DNS names are downcased. 79 80 This reduces code complexity, reduces the number of edge-cases that must 81 be tested, and makes the system safer to operate. 82 83 Yes, we know that DNS is case insensitive. See Opinion #3. 84 85 86 # Opinion #5: Users should state what they want, and DNSControl should do the rest. 87 88 When possible, dnsconfig.js lists a high-level description of what 89 is desired and the compiler does the hard work for you. 90 91 Some examples: 92 93 * Macros and iterators permit you to state something once, correctly, and repeat it many places. 94 * TXT strings are expressed as JavaScript strings, with no weird DNS-required special escape charactors. DNSControl does the escaping for you. 95 * Domain names with Unicode are listed as real Unicode. Punycode translation is done for you. 96 * IP addresses are expressed as IP addresses; and reversing them to in-addr.arpa addresses is done for you. 97 * SPF records are stated in the most verbose way; DNSControl optimizes it for you in a safe, opt-in way. 98 99 100 # Opinion #6 If it is ambiguous in DNS, it is forbidden in DNSControl. 101 102 When there is ambiguity an expert knows what the system will do. 103 Your coworkers should not be expected to be experts. (See Opinion #2). 104 105 We would rather DNSControl error out than require users to be DNS experts. 106 107 For example: 108 109 We know that "bar.com." is a FQDN because it ends with a dot. 110 111 Is "bar.com" a FQDN? Well, obviously it is, because it already ends 112 with ".com" and we all know that "bar.com.bar.com" is probably not 113 what the user intended. 114 115 We know that "bar" is *not* an FQDN because it doesn't contain any dots. 116 117 Is "meta.xyz" a FQDN? 118 119 That's ambiguous. If the user knows that "xyz" is a top level domain (TLD) 120 then it is obvious that it is a FQDN. However, can anyone really memorize 121 all the TLDSs? There used to be just gov/edu/com/mil/org/net and everyone 122 could memorize them easily. As of 2000, there are many, many, more. 123 You can't memorize them all. In fact, even before 2000 you couldn't 124 memorize them all. (In fact, you didn't even realize that we left out "int"!) 125 126 "xyz" became a TLD in June 2014. Thus, after 2014 a system like DNSControl 127 would have to act differently. We don't want to be surprised by changes 128 like that. 129 130 Therefore, we require all CNAME, MX, and NS targets to be FQDNs (they must 131 end with a "."), or to be a shortname (no dots at all). Everything 132 else is ambiguous and therefore an error.