# DNSSEC, data verification

Good news! Knot Resolver uses secure configuration by default, and this configuration should not be changed unless absolutely necessary, so feel free to skip over this section.

Warning

Options in this section are intended only for expert users and normally should not be needed.

Since version 4.0, DNSSEC validation is enabled by default. If you really need to turn DNSSEC off and are okay with lowering security of your system by doing so, add the following snippet to your configuration file.

    -- turns off DNSSEC validation
    trust_anchors.remove('.')

The resolver supports DNSSEC including RFC 5011 automated DNSSEC TA updates and RFC 7646 negative trust anchors. Depending on your distribution, DNSSEC trust anchors should be either maintained in accordance with the distro-wide policy, or automatically maintained by the resolver itself.

In practice this means that you can forget about it and your favorite Linux distribution will take care of it for you.

Following functions allow to modify DNSSEC configuration if you really have to:

trust_anchors.add_file(keyfile[, readonly = false])
  Parameters:

    - keyfile (string) – path to the file.

    - readonly – if true, do not attempt to update the file.

  The format is standard zone file, though additional information may be persisted in comments. Either DS or DNSKEY records can be used for TAs. If the file does not exist, bootstrapping of root TA will be attempted. If you want to use bootstrapping, install lua-http library.

  Each file can only contain records for a single domain. The TAs will be updated according to RFC 5011 and persisted in the file (if allowed).

  Example output:

      > trust_anchors.add_file('root.key')
      [ ta ] new state of trust anchors for a domain:
      .                       165488  DS      19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
      nil

      [ ta ] key: 19036 state: Valid

trust_anchors.remove(zonename)

  Remove specified trust anchor from trusted key set. Removing trust anchor for the root zone effectively disables DNSSEC validation (unless you configured another trust anchor).

      > trust_anchors.remove('.')
      true

  If you want to disable DNSSEC validation for a particular domain but keep it enabled for the rest of DNS tree, use `trust_anchors.set_insecure()`.

trust_anchors.hold_down_time = 30 * day
  Return:

    int (default: 30 * day)

  Modify RFC5011 hold-down timer to given value. Intended only for testing purposes. Example: `30 * sec`

trust_anchors.refresh_time = nil
  Return:

    int (default: nil)

  Modify RFC5011 refresh timer to given value (not set by default), this will force trust anchors to be updated every N seconds periodically instead of relying on RFC5011 logic and TTLs. Intended only for testing purposes. Example: `10 * sec`

trust_anchors.keep_removed = 0
  Return:

    int (default: 0)

  How many `Removed` keys should be held in history (and key file) before being purged. Note: all `Removed` keys will be purged from key file after restarting the process.

trust_anchors.set_insecure(nta_set)
  Parameters:

    nta_list (table) – List of domain names (text format) representing NTAs.

  When you use a domain name as an negative trust anchor (NTA), DNSSEC validation will be turned off at/below these names. Each function call replaces the previous NTA set. You can find the current active set in `trust_anchors.insecure` variable. If you want to disable DNSSEC validation completely use `trust_anchors.remove()` function instead.

  Example output:

      > trust_anchors.set_insecure({ 'bad.boy', 'example.com' })
      > trust_anchors.insecure
      [1] => bad.boy
      [2] => example.com

  Warning

  If you set NTA on a name that is not a zone cut, it may not always affect names not separated from the NTA by a zone cut.

trust_anchors.add(rr_string)
  Parameters:

    rr_string (string) – DS/DNSKEY records in presentation format (e.g. `. 3600 IN DS 19036 8 2 49AAC11...`)

  Inserts DS/DNSKEY record(s) into current keyset. These will not be managed or updated, use it only for testing or if you have a specific use case for not using a keyfile.

  Note

  Static keys are very error-prone and should not be used in production. Use `trust_anchors.add_file()` instead.

  Example output:

      > trust_anchors.add('. 3600 IN DS 19036 8 2 49AAC11...')

trust_anchors.summary()

  Return string with summary of configured DNSSEC trust anchors, including negative TAs.

DNSSEC is main technology to protect data, but it is also possible to change how strictly resolver checks data from insecure DNS zones:

mode(['strict' | 'normal' | 'permissive'])
  Param:

    New checking level specified as string (optional).

  Returns:

    Current checking level.

  Get or change resolver strictness checking level.

  By default, resolver runs in normal mode. There are possibly many small adjustments hidden behind the mode settings, but the main idea is that in permissive mode, the resolver tries to resolve a name with as few lookups as possible, while in strict mode it spends much more effort resolving and checking referral path. However, if majority of the traffic is covered by DNSSEC, some of the strict checking actions are counter-productive.

  Glue type | Modes when it is accepted | Example glue [1]
  --- | --- | ---
  mandatory glue | strict, normal, permissive | ns1.example.org
  in-bailiwick glue | normal, permissive | ns1.example2.org
  any glue records | permissive | ns1.example3.net

  [1]

  The examples show glue records acceptable from servers authoritative for org zone when delegating to example.org zone. Unacceptable or missing glue records trigger resolution of names listed in NS records before following respective delegation.