1. 05 Aug, 2020 1 commit
  2. 14 Jul, 2020 1 commit
    • Tony Finch's avatar
      Fix re-signing when `sig-validity-interval` has two arguments · 31005d61
      Tony Finch authored
      Since October 2019 I have had complaints from `dnssec-cds` reporting
      that the signatures on some of my test zones had expired. These were
      zones signed by BIND 9.15 or 9.17, with a DNSKEY TTL of 24h and
      `sig-validity-interval 10 8`.
      This is the same setup we have used for our production zones since
      2015, which is intended to re-sign the zones every 2 days, keeping
      at least 8 days signature validity. The SOA expire interval is 7
      days, so even in the presence of zone transfer problems, no-one
      should ever see expired signatures. (These timers are a bit too
      tight to be completely correct, because I should have increased
      the expiry timers when I increased the DNSKEY TTLs from 1h to 24h.
      But that should only matter when zone transfers are broken, which
      was not the case for the error reports that led to this patch.)
      For example, this morning my test zone contained:
              dev.dns.cam.ac.uk. 86400 IN RRSIG DNSKEY 13 5 86400 (
                                      20200701221418 20200621213022 ...)
      But one of my resolvers had cached:
              dev.dns.cam.ac.uk. 21424 IN RRSIG DNSKEY 13 5 86400 (
                                      20200622063022 20200612061136 ...)
      This TTL was captured at 20200622105807 so the resolver cached the
      RRset 64976 seconds previously (18h02m56s), at 20200621165511
      only about 12h before expiry.
      The other symptom of this error was incorrect `resign` times in
      the output from `rndc zonestatus`.
      For example, I have configured a test zone
              zone fast.dotat.at {
                      file "../u/z/fast.dotat.at";
                      type primary;
                      auto-dnssec maintain;
                      sig-validity-interval 500 499;
      The zone is reset to a minimal zone containing only SOA and NS
      records, and when `named` starts it loads and signs the zone. After
      that, `rndc zonestatus` reports:
              next resign node: fast.dotat.at/NS
              next resign time: Fri, 28 May 2021 12:48:47 GMT
      The resign time should be within the next 24h, but instead it is
      near the signature expiry time, which the RRSIG(NS) says is
      20210618074847. (Note 499 hours is a bit more than 20 days.)
      May/June 2021 is less than 500 days from now because expiry time
      jitter is applied to the NS records.
      Using this test I bisected this bug to 09990672 which contained a
      mistake leading to the resigning interval always being calculated in
      hours, when days are expected.
      This bug only occurs for configurations that use the two-argument form
      of `sig-validity-interval`.
      (cherry picked from commit 030674b2)
  3. 22 Jun, 2020 1 commit
  4. 25 May, 2020 1 commit
  5. 03 Apr, 2020 1 commit
    • Matthijs Mekking's avatar
      Redesign dnssec sign statistics · f59f4461
      Matthijs Mekking authored
      The first attempt to add DNSSEC sign statistics was naive: for each
      zone we allocated 64K counters, twice.  In reality each zone has at
      most four keys, so the new approach only has room for four keys per
      zone. If after a rollover more keys have signed the zone, existing
      keys are rotated out.
      The DNSSEC sign statistics has three counters per key, so twelve
      counters per zone. First counter is actually a key id, so it is
      clear what key contributed to the metrics.  The second counter
      tracks the number of generated signatures, and the third tracks
      how many of those are refreshes.
      This means that in the zone structure we no longer need two separate
      references to DNSSEC sign metrics: both the resign and refresh stats
      are kept in a single dns_stats structure.
      Incrementing dnssecsignstats:
      Whenever a dnssecsignstat is incremented, we look up the key id
      to see if we already are counting metrics for this key.  If so,
      we update the corresponding operation counter (resign or
      If the key is new, store the value in a new counter and increment
      corresponding counter.
      If all slots are full, we rotate the keys and overwrite the last
      slot with the new key.
      Dumping dnssecsignstats:
      Dumping dnssecsignstats is no longer a simple wrapper around
      isc_stats_dump, but uses the same principle.  The difference is that
      rather than dumping the index (key tag) and counter, we have to look
      up the corresponding counter.
      (cherry picked from commit 705810d5)
  6. 17 Mar, 2020 1 commit
  7. 14 Feb, 2020 1 commit
  8. 13 Feb, 2020 1 commit
  9. 12 Feb, 2020 1 commit
  10. 06 Nov, 2019 4 commits
    • Matthijs Mekking's avatar
      dnssec-policy inheritance from options/view · 5f464d15
      Matthijs Mekking authored
      'dnssec-policy' can now also be set on the options and view level and
      a zone that does not set 'dnssec-policy' explicitly will inherit it
      from the view or options level.
      This requires a new keyword to be introduced: 'none'.  If set to
      'none' the zone will not be DNSSEC maintained, in other words it will
      stay unsigned.  You can use this to break the inheritance.  Of course
      you can also break the inheritance by referring to a different
      The keywords 'default' and 'none' are not allowed when configuring
      your own dnssec-policy statement.
      Add appropriate tests for checking the configuration (checkconf)
      and add tests to the kasp system test to verify the inheritance
      Edit the kasp system test such that it can deal with unsigned zones
      and views (so setting a TSIG on the query).
    • Matthijs Mekking's avatar
      Update zoneconf to use kasp config · 09990672
      Matthijs Mekking authored
      If a zone has a dnssec-policy set, use signature validity,
      dnskey signature validity, and signature refresh from
      Zones configured with 'dnssec-policy' will allow 'named' to create
      DNSSEC keys (similar to dnssec-keymgr) if not available.
    • Matthijs Mekking's avatar
      Parse dnssec-policy config into kasp · 2924b19a
      Matthijs Mekking authored
      Add code that actually stores the configuration into the kasp
      structure and attach it to the appropriate zone.
    • Matthijs Mekking's avatar
      Extend ttlval to accept ISO 8601 durations · b7c5bfb2
      Matthijs Mekking authored
      The ttlval configuration types are replaced by duration configuration
      types. The duration is an ISO 8601 duration that is going to be used
      for DNSSEC key timings such as key lifetimes, signature resign
      intervals and refresh periods, etc. But it is also still allowed to
      use the BIND ttlval ways of configuring intervals (number plus
      optional unit).
      A duration is stored as an array of 7 different time parts.
      A duration can either be expressed in weeks, or in a combination of
      the other datetime indicators.
      Add several unit tests to ensure the correct value is parsed given
      different string values.
  11. 03 Oct, 2019 1 commit
  12. 01 Oct, 2019 2 commits
  13. 24 Sep, 2019 1 commit
  14. 23 Jul, 2019 3 commits
  15. 25 Jun, 2019 2 commits
    • Matthijs Mekking's avatar
      Also collect DNSSEC refresh signature statistics · 6f67546c
      Matthijs Mekking authored
      In addition to gather how many times signatures are created per
      key in a zone, also count how many of those signature creations are
      because of DNSSEC maintenance.  These maintenance counters are
      incremented if a signature is refreshed (but the RRset did not
      changed), when the DNSKEY RRset is changed, and when that leads
      to additional RRset / RRSIG updates (for example SOA, NSEC).
    • Matthijs Mekking's avatar
      Add DNSSEC sign operations statistics channel · d8cf7aed
      Matthijs Mekking authored
      Add a new statistics structure to record how many sign operations
      a key has made within a zone.
  16. 08 Mar, 2019 1 commit
  17. 08 Nov, 2018 2 commits
  18. 24 Oct, 2018 4 commits
    • Michał Kępień's avatar
      Define a default master server list for the root zone · 2c69734b
      Michał Kępień authored
      To minimize the effort required to set up IANA root zone mirroring,
      define a default master server list for the root zone and use it when
      that zone is to be mirrored and no master server list was explicitly
      specified.  Contents of that list are taken from RFC 7706 and are
      subject to change in future releases.
      Since the static get_masters_def() function in bin/named/config.c does
      exactly what named_zone_configure() in bin/named/zoneconf.c needs to do,
      make the former non-static and use it in the latter to prevent code
    • Michał Kępień's avatar
      Clean up handling of NOTIFY settings for mirror zones · 1d49b01c
      Michał Kępień authored
      Previous way of handling NOTIFY settings for mirror zones was a bit
      tricky: any value of the "notify" option was accepted, but it was
      subsequently overridden with dns_notifytype_explicit.  Given the way
      zone configuration is performed, this resulted in the following
        - if "notify yes;" was set explicitly at any configuration level or
          inherited from default configuration, it was silently changed and so
          only hosts specified in "also-notify", if any, were notified,
        - if "notify no;" was set at any configuration level, it was
          effectively honored since even though zone->notifytype was silently
          set to dns_notifytype_explicit, the "also-notify" option was never
          processed due to "notify no;" being set.
      Effectively, this only allowed the hosts specified in "also-notify" to
      be notified, when either "notify yes;" or "notify explicit;" was
      explicitly set or inherited from default configuration.
      Clean up handling of NOTIFY settings for mirror zones by:
        - reporting a configuration error when anything else than "notify no;"
          or "notify explicit;" is set for a mirror zone at the zone level,
        - overriding inherited "notify yes;" setting with "notify explicit;"
          for mirror zones,
        - informing the user when the "notify" setting is overridden, unless
          the setting in question was inherited from default configuration.
    • Michał Kępień's avatar
      Replace the "mirror" zone option with "type mirror;" · 2cb9e8a0
      Michał Kępień authored
      Use a zone's 'type' field instead of the value of its DNS_ZONEOPT_MIRROR
      option for checking whether it is a mirror zone.  This makes said zone
      option and its associated helper function, dns_zone_mirror(), redundant,
      so remove them.  Remove a check specific to mirror zones from
      named_zone_reusable() since another check in that function ensures that
      changing a zone's type prevents it from being reused during
    • Michał Kępień's avatar
      Define a separate dns_zonetype_t for mirror zones · e1bb8de6
      Michał Kępień authored
      Rather than overloading dns_zone_slave and discerning between a slave
      zone and a mirror zone using a zone option, define a separate enum
      value, dns_zone_mirror, to be used exclusively by mirror zones.  Update
      code handling slave zones to ensure it also handles mirror zones where
  19. 20 Sep, 2018 1 commit
  20. 08 Aug, 2018 3 commits
  21. 02 Aug, 2018 1 commit
  22. 11 Jul, 2018 1 commit
    • Michał Kępień's avatar
      Do not reuse zones whose "mirror" setting was changed · dbfd19c6
      Michał Kępień authored
      Update named_zone_reusable() so that it does not consider a zone to be
      eligible for reuse if its old value of the "mirror" option differs from
      the new one.  This causes "rndc reconfig" to create a new zone structure
      whenever the value of the "mirror" option is changed, which ensures that
      the previous zone database is not reused and that flags are properly set
      in responses sourced from zones whose "mirror" setting was changed at
  23. 28 Jun, 2018 3 commits
    • Michał Kępień's avatar
      Disable notifies for mirror zones unless also-notify is used · dd30f53e
      Michał Kępień authored
      Since the mirror zone feature is expected to mostly be used for the root
      zone, prevent slaves from sending NOTIFY messages for mirror zones by
      default.  Retain the possibility to use "also-notify" as it might be
      useful in certain cases.
    • Michał Kępień's avatar
      Disable outgoing mirror zone transfers by default · 3af412c0
      Michał Kępień authored
      As mirror zone data should be treated the way validated, cached DNS
      responses are, outgoing mirror zone transfers should be disabled unless
      they are explicitly enabled by zone configuration.
    • Michał Kępień's avatar
      Add new "mirror" slave zone option · 49201f10
      Michał Kępień authored
      Add a new slave-only boolean configuration option, "mirror", along with
      its corresponding dns_zoneopt_t enum and a helper function for checking
      whether that option was set for a given zone.  This commit does not
      introduce any behavior changes yet.
  24. 06 Jun, 2018 1 commit
  25. 25 May, 2018 1 commit
    • Evan Hunt's avatar
      remove the experimental authoritative ECS support from named · e3244493
      Evan Hunt authored
      - mark the 'geoip-use-ecs' option obsolete; warn when it is used
        in named.conf
      - prohibit 'ecs' ACL tags in named.conf; note that this is a fatal error
        since simply ignoring the tags could make ACLs behave unpredictably
      - re-simplify the radix and iptable code
      - clean up dns_acl_match(), dns_aclelement_match(), dns_acl_allowed()
        and dns_geoip_match() so they no longer take ecs options
      - remove the ECS-specific unit and system test cases
      - remove references to ECS from the ARM