Managing unbound.conf for additional performance and security

[feld]

Currently we do not manage any unbound configuration but we can gain some performance and security benefits by doing so. I suggest we create a config such as /etc/unbound/unbound.conf.d/unbound.conf with the following contents:

server:
  hide-version: yes
  hide-identity: yes
  use-caps-for-id: yes
  prefetch: yes
  prefetch-key: yes
  harden-dnssec-stripped: no
  aggressive-nsec: yes
  serve-expired: yes
  serve-expired-reply-ttl: 30
  serve-expired-ttl: 86400
  serve-expired-ttl-reset: yes
  serve-expired-client-timeout: 1800
  qname-minimisation-strict: no
  extended-statistics: no
  log-queries: no
  log-replies: no
  log-tag-queryreply: no
  log-servfail: no
  log-local-actions: no
  verbosity: 1
  msg-cache-size: 50m
  rrset-cache-size: 100m
  outgoing-num-tcp: 10
  incoming-num-tcp: 10
  num-queries-per-thread: 4096
  outgoing-range: 8192
  jostle-timeout: 200
  infra-host-ttl: 120
  infra-keep-probing: yes
  infra-cache-numhosts: 10000
  val-log-level: 0

• hide-version, hide-identity, and use-caps-for-id provide some anonymity benefits

• harden-dnssec-stripped attempts to detect if DNSSEC was stripped from a response if the domain was listed in the trust anchors but a plain respose was returned. I have not enabled this, but it's worth considering.

• aggressive-nsec is both a DNSSEC performance and security improvement 1

• prefetch and prefetch-key will keep the the cache warm by automatically fetching DNS records for expiring entires in the cache. This could speed up deliveries by tens to hundreds of milliseconds to servers that have not been communicated with recently (e.g., if their TTL is 3600 / 1 hour and it has been longer than that since the last time you send a message.)

• serve-expired and friends is useful for NS outages and if there is censorship of a domain. Values could be tweaked to be more aggressive.

• infra-keep-probing and infra-host-ttl is very useful when there are DNS propagation issues or a misconfiguration. If someone launches a new server and DNS didn't propagate yet but you try to send them a message you'll probably get a negative cache entry and have to wait the default 15 minutes (900) before the record can be resolved. The infra-host-ttl will drop the waiting period to that value. The infra-host cache holds the lameness, EDNS, and roundtrip latency information.

Some of the other values like the cache sizes could probably be adjusted down as mine are rather large.