input/dsablog/2010/02/Securing_the_Debian_zones.mdwn

   1 [[!meta author="Peter Palfrader"]]
   2
   3 We are in the process of deploying
   4 [DNSSEC](http://www.dnssec.net/),
   5 the DNS Security Extensions, on the Debian zones.  This means properly
   6 configured resolvers will be able to verify the authenticity of information
   7 they receive from the domain name system.
   8
   9 The plan is to introduce DNSSEC in several steps so that we can react
  10 to issues that arise without breaking everything at once.
  11
  12 We will start with serving signed <code>debian.net</code> and
  13 <code>debian.com</code> zones.  Assuming nobody complains loudly enough
  14 the various reverse zones and finally the <code>debian.org</code> zone will
  15 follow.  Once all our zones are signed we will publish our trust anchors
  16 in [ISC's DLV Registry](https://www.isc.org/solutions/dlv), again in
  17 stages.
  18
  19 The various child zones that are handled differently from our normal
  20 DNS infrastructure
  21 (<code>mirror.debian.net</code>,
  22 <code>alioth</code>,
  23 <code>bugs</code>,
  24 <code>ftp</code>,
  25 <code>packages</code>,
  26 <code>security</code>,
  27 <code>volatile</code>,
  28 <code>www</code>)
  29 will follow at a later date.
  30
  31 We are using bind 9.6 for [NSEC3](http://tools.ietf.org/html/rfc5155) support and
  32 [our](http://git.debian.org/?p=mirror/Net-DNS-SEC-Maint-Key.git)
  33 [fork](http://git.debian.org/?p=mirror/Net-DNS-SEC-Maint-Zone.git)
  34 of RIPE's
  35 [DNSSEC Key Management Tools](http://www.ripe.net/disi/dnssec_maint_tool/)
  36 for managing our keys because we believe that it integrates nicely
  37 with our
  38 [existing DNS helper scripts](http://git.debian.org/?p=mirror/dns-helpers.git),
  39 at least until something better becomes available.
  40
  41 We will use NSEC3RSASHA1 with key sizes of 1536 bits for the KSK and
  42 1152 bits for the ZSK.  Signature validity period will most likely be
  43 four weeks, with a one week signature publication period
  44 (cf. [RFC4641: DNSSEC Operational
  45 Practices](http://tools.ietf.org/html/rfc4641)).
  46
  47 Zone keys rollovers will happen regularly and will not be announced in
  48 any specific way.  Key signing key rollovers will probably be announced
  49 on the
  50 [debian-infrastructure-announce](http://lists.debian.org/debian-infrastructure-announce/)
  51 list until such time that our zones are reachable from a
  52 [signed root](http://www.root-dnssec.org/).  KSK rollovers for our own
  53 child zones (www.d.o et al.), once signed, will not be announced because
  54 we can just put proper
  55 [DS records](http://en.wikipedia.org/wiki/List_of_DNS_record_types#DS)
  56 in the respective parent zone.
  57
  58 Until we announce the first set of trust anchors on the mailinglist the
  59 keysets present in DNS should be considered experimental.  They can
  60 be changed at any time, without observing standard rollover practices.
  61
  62 Please direct questions or comments to either the debian-admin or, if
  63 you want a more public forum, the debian-project list at
  64 lists.debian.org.
  65
  66 See also:
  67
  68 * [DNSSEC wikipedia page](http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions),
  69 * [DNSSEC HOWTO, a tutorial in disguise (Olaf Kolkman, nlnetlabs)](http://www.nlnetlabs.nl/publications/dnssec_howto/index.html).