Andrew Latham

A recurring issue in most computer system infrastructure is the System of Record (SOR)[1] which is a source of truth about the desired state or the current state of systems and networks. Many outsiders or senior management are left to believe that the planned state and the current state are the same but that rarely happens. I have written a few SORs and enabled others to be more accurate. Much of the work on modern container image manifests [2] has made great advancements to a more complete language to communicate the details of an endpoint. An issue I would love to resolve is the assumption that a single application is the SOR. The reality is that a data service is the ultimately the SOR and many things might read from or write to it. Today if I was asked to write another SOR I would setup RethinkDB [3] and establish a table named 'help' that pointed to a table named 'standards' and thus became self documenting system.

SORs should also be free to access offline in emergencies and distributed systems like RethinkDB and even Git are perfect for this type of setup. A support person or team can maintain a local copy of the SOR with little to no overhead. Even tools like MediaWiki[4] are great as they can be duplicated or distributed as a side effect of their design. For discovery there are established tools like DNS SRV [5] that are often overlooked. A popular solution for datacentres is NetBox [6] which is a fine step forward from RackTables [7] which served many for years and is still not a horrible solution. In my spare time I hope to integrate a DCIM [8] solution into Odoo [9] to connect the various organizational groups together.

  1. https://en.wikipedia.org/wiki/System_of_record
  2. https://github.com/opencontainers/image-spec/blob/master/manifest.md
  3. https://www.rethinkdb.com/
  4. https://www.mediawiki.org/wiki/MediaWiki
  5. https://en.wikipedia.org/wiki/SRV_record
  6. https://netbox.readthedocs.io/en/latest/
  7. https://www.racktables.org/
  8. https://en.wikipedia.org/wiki/Data_center_infrastructure_management
  9. https://www.odoo.com/
Andrew Latham

A very evil example of showing it can be done...

So you have a domain like example.com that you want to alias to anotherexample.com. What is happening is at the root of the example.com is an @ or base or apex record that per the RFCs must be an IP address.

Example

$ORIGIN com.
com.                  IN  SOA ns.example.com. domain.example.com. (1 3H 15 1w 3h)
example.com   IN CNAME anotherexample.com.

$ORIGIN example.com.
example.com.  IN  SOA ns.example.com. domain.example.com. (1 3H 15 1w 3h)
       IN  NS     ns.example.com.
       IN  NS     ns.anotherexample.com.
ns         IN  A      127.0.0.1
www    IN  CNAME anotherexample.com.

What we are doing

The goal here is to server example.com and CNAME it to anotherexample.com which is not supposed to work. What I am actually doing is creating a zone for .com and then answering with a CNAME for example.com then reseting the $ORIGIN quickly so the zone now becomes the zone for example.com. I also show the www.example.com CNAME as an example of how it is normally done and the base driver for this issue. In the browser address bar the user does not understand the difference between the two and this hack is a dangerous and silly hack to make the user happy.

Don't do this....

Only do this in a Lab or test setup to prove things out. People will not like you for doing this in the real world.

I glossed over a ton of details to keep this readable.

Please use with extreme caution and configure and secure your DNS infrastructure properly.

Andrew Latham
  1. Name servers have glue records[a] setup via the registrar
  2. Base (apex) domain (@) and www point to the same IP(s)
  3. mail.example.com, nameservers.example.com return all the mail and name servers respectively
  4. SOA[b] email address works and is read by a human daily
  5. Name servers are on more than one subnet
  6. SOA serial is not date based
  7. Wildcard and or Generated answers for undefined PTR[c] records
  8. Registrar offers API to update glue records for mitigating DDOS[d]
  9. Documentation is easy to find
  10. Disaster recovery is tested on a schedule
a. https://en.wikipedia.org/wiki/Domain_Name_System#Circular_dependencies_and_glue_records
b. Start of Authority
c. https://en.wikipedia.org/wiki/Reverse_DNS_lookup
d. distributed denial-of-service attack