Github's senior infrastructure engineer Joe Williams blogged about the version-control repository's move to a new architecture that includes increases support working at Github scale, from the regular simple DNS structure which has served them well to date.
![""]("__GHOST_URL__/content/images/2017/06/2017-05-09-at-12.14-PM.png")
According to Williams, Github was led to this sudden change of model as a result of many of the hosted applications being sensitive to DNS resolution performance availability which could result in customers experiencing degraded performance, and/or outages. With the previous infrastructure, these concerns were only partially problematic when conducting configurations or code changes; Least of which was the difficulty in identifying root causes of any malfunctions. The only tool engineers could use was tcpdump. Additional benefits include:
- Improve reliability by reducing any external dependencies.
- Improve role isolation between caches and authorities.
- Support API and deploy based workflows for automated changes.
- Creating invisible internal zones to add flexibility to the way internal and external zones were served, unless otherwise configured, while also guaranteeing external zones visible from the inside whilst on the internal network.
From these requirements, Github has managed to build an architecture that included three kinds of nodes:
Create, modify or delete records via the HTTP API. Authorities, which serve as DNS masters and manage zone transfers from edge nodes.
Regional level authorities called Edges, which handle the requests from the caches thereby acting as a gateway for the data centre and are in charge of performing a zone transfer.
The caches in data centres are responsible for the providing live data to applications without requiring them to cross data centre constraints.
Github engineers have also sought to benefit logging by choosing to use PowerDNS for authorities, Unbound for caches and NSD for edge hosts.
Should you require to access the external zones from github.com, you may do so from the internal zones using their github.net domain, without ever communicating with the external DNS providers thanks ti
As mentioned, external zones, using the github.com domain, can be accessed from internal zones, using the github.net domain, without ever communicating with the external DNS providers. This is made possible by Unbound, which additionally supports the option to access the external network should the internal DNS ever fail.
Williams gives a detailed approach to the changes implemented in his blog post.
Thanks for visiting Base64, please share any thoughts in the comments section below.