input/dsablog/2014/The_Debian_DNS_universe.mdwn

   1 [[!meta author="Peter Palfrader"]]
   2
   3 # Abstract
   4
   5 I recently moved our primary nameserver from `orff.debian.org`, which is
   6 an aging blade in Greece, to a VM on one of our ganeti clusters.  In the
   7 process, I rediscovered a lot about our DNS infrastructure.  In this post,
   8 I will describe the many sources of information and how they all come
   9 together.
  10
  11 # Introduction
  12
  13 The [Domain Name System][DNS] is the hierarchical database and query
  14 protocol that is in use on the Internet today to map hostnames to IP
  15 addresses, to map the reverse thereof, to lookup relevant servers for
  16 certain services such as mail, and a gazillion other things.  Management
  17 and authority in the DNS is split into different zones, subtrees of the
  18 global tree of domain names.
  19
  20 Debian currently has a bit over a score of zones.  The two most
  21 prominents clearly are `debian.org` and
  22 `debian.net`.  The rest is made up of `debian`
  23 domains in various other top level domains and reverse zones, which
  24 are utilized in IP address to hostname mappings.
  25
  26 # Types and sources of information
  27
  28 The data we put into DNS comes from a wide range of different systems:
  29
  30  * [Classical zonefiles maintained in git][domains].  This represents
  31    the core of our domain data.  It maps services like
  32    `blends.debian.org` to `static.debian.org` or
  33    specifies the servers responsible for accepting mail to
  34    `@debian.org` addresses.  It also is where all the
  35    `ftp.CC.debian.org` entries are kept and maintained together with the
  36    mirror team.
  37  * Information about `debian.org` hosts, such as `master`, is maintained
  38    in Debian's [userdir LDAP][db], queryable using
  39    LDAP<sup>[^ldap]</sup>.
  40   * This includes first and foremost the host's IP addresses (v4 and v6).
  41   * Additionally, we store the server responsible for receiving a host's
  42     mail in LDAP (`mXRecord` LDAP attribute, DNS `MX` record type).
  43   * LDAP also has some specs on computers, which we put into each host's
  44     `HINFO` record, mainly because we can and we are old-school.
  45   * Last but not least, LDAP also has each host's public ssh key, which we
  46     extract into [SSHFP][rfc4255] records for DNS.
  47  * LDAP also has per-user information.  Users of debian infrastructure
  48    can attach limited DNS elements as `dnsZoneEntry` attributes to their
  49    user<sup>[^ldap2]</sup>.
  50  * The auto-dns system (more on that below).
  51  * Our [puppet] also is a source of DNS information.  Currently it
  52    generates only the [`TLSA`][rfc6698] records that enable clients to
  53    securely authenticate certificates used for mail and HTTPS, similar
  54    to how `SSHFP` works for authenticating ssh host keys.
  55
  56 # Debian's auto-dns and geo setup
  57
  58 We try to provide the best service we can.  As such, our goal is that,
  59 for instance, user access to [`www`][www] or [`bugs`][bugs] should always
  60 work.  These services are, thus, provided by more than one machine on
  61 the Internet.
  62
  63 However, HTTP did not specify a requirement for clients to re-try a
  64 different server if one of those in a set is unavailable.  This means
  65 for us that when a host goes down, it needs to be removed from the
  66 corresponding DNS entry.
  67 Ideally, the world wouldn't have to wait for one of us to notice and
  68 react before they can have their service in a working manner.
  69
  70 Our solution for this is our auto-dns setup.  We [maintain a
  71 list][auto-dns] of hosts that are providing a service.  We [monitor them
  72 closely][mini-nag].  Whenever a server goes away or comes back we
  73 automatically rebuild the zone that contains the element.
  74
  75 This setup also lets us reboot servers cleanly &mdash; since one of the
  76 things we monitor is "is there a shutdown running", we can, simply by
  77 issuing a `shutdown -r 30 kernel-update`, de-rotate the machine in
  78 question from DNS.  Once the host is back it'll automatically get
  79 re-added to the round-robin zone entry.
  80
  81 The auto-dns system produces two kinds of output:
  82
  83 * In *service*-mode it generates a file with just the address records
  84   for a specific service.  This snippet is then included in its zone
  85   using a standard bind `$INCLUDE` directive.  Services that work like
  86   this include [`bugs`][bugs] and `static` ([service definition for
  87   static][static]).
  88 * In *zone*-mode, auto-dns produces zonefiles.  For each service it
  89   produces a set of zonefiles, one for each out of a set of different
  90   geographic regions.  These individual zonefiles are then transferred
  91   using `rsync` to our [GEO-IP enabled][geoip] nameservers.  This
  92   enables us to give users a list of `security` mirrors closer to them
  93   and thus hopefully faster for them.
  94
  95 # Tying it all together
  96
  97 ![The Debian DNS Rube Goldberg Machine.](/dsablog/2014/debian-dns.png)
  98
  99 Figure 1: The Debian DNS Rube Goldberg Machine.
 100
 101 Once all the individual pieces of source information have been
 102 collected, the `dns-update` and `write_zonefile` scripts from our
 103 [dns-helpers] repository take over the job of building complete
 104 zonefiles and a bind configuration snippet.  Bind then loads the zones
 105 and notifies its secondaries.
 106
 107 For geozones, the zonefiles are already produced by auto-dns'
 108 `build-zones` and those are pulled from the geo nameservers via rsync
 109 over ssh, after an ssh trigger.
 110
 111 # and also DNSSEC
 112
 113 All of our zones are signed using DNSSEC.  We have a script in
 114 [dns-helpers] that produces, for all zones, a set of rolling signing
 115 keys.  For the normal zones, bind 9.9 takes care of signing them
 116 in-process before serving the zones to its secondaries.  For our
 117 geo-zones we sign them in the classical `dnssec-signzone` way before
 118 shipping them.
 119
 120 The secure delegation status (DS set in parent matches DNSKEY in child)
 121 is monitored by a set of nagios tests, from both [dsa-nagios] and
 122 [dns-helpers].  Of these, `manage-dnssec-keys` has a dual job: not
 123 only will it warn us if an expiring key is still in the DSset, it can
 124 also prevent it from getting expired by issuing timly updates of the
 125 keys metadata.
 126
 127 # Relevant Git repositories:
 128
 129 * [domains]
 130 * [auto-dns]
 131 * [mini-nag]
 132 * [dns-helpers]
 133 * [puppet]
 134
 135 [^ldap]: `ldapsearch -h db.debian.org -x -ZZ -b dc=debian,dc=org -LLL 'host=master'`
 136
 137 [^ldap2]: `ldapsearch -h db.debian.org -x -ZZ -b dc=debian,dc=org -LLL 'dnsZoneEntry=*' dnsZoneEntry`
 138
 139
 140 [DNS]: https://en.wikipedia.org/wiki/Domain_Name_System
 141 [db]: https://db.debian.org/
 142 [rfc4255]: https://tools.ietf.org/html/rfc4255
 143 [rfc6698]: https://tools.ietf.org/html/rfc6698
 144 [www]: https://www.debian.org/
 145 [security]: http://security.debian.org/
 146 [bugs]: http://bugs.debian.org/
 147 [geoip]: https://en.wikipedia.org/wiki/Geolocation_software
 148
 149 [puppet]: http://anonscm.debian.org/gitweb/?p=mirror/dsa-puppet.git;a=tree
 150 [domains]: http://anonscm.debian.org/gitweb/?p=mirror/domains.git;a=tree
 151 [auto-dns]: http://anonscm.debian.org/gitweb/?p=mirror/dsa-auto-dns.git;a=tree
 152 [mini-nag]: http://anonscm.debian.org/gitweb/?p=mirror/dsa-mini-nag.git;a=tree
 153 [dns-helpers]: http://anonscm.debian.org/gitweb/?p=mirror/dns-helpers.git;a=tree
 154 [static]: http://anonscm.debian.org/gitweb/?p=mirror/dsa-auto-dns.git;a=blob;f=services/static.debian.org.service;hb=HEAD
 155
 156 -- Peter Palfrader