Recommended Knob Settings

[shane-kerr]

We have a list of lots of different settings. We need to add a few words explaining what each does, why an operator would care, and possibly some recommendations on what to set each at.

[moonshiner]

Negative trust anchors and Trust Anchor reporting moved down to end of list

point to discuss how to deal with bad DS failure (Nasa, Slack)

[moonshiner]

Reorder

DNSSEC QNAME

Aggressive NSEC caching - more of auth server thingie?

[moonshiner]

Negative Cache TTL

Max TTL should be an hour (tim)

[moonshiner]

First Level Knobs

note reorder list in terms of priority

DNSSEC validation has support needs

how to test for DNSSEC issues - importance of testing tools DNSviz dig +cd

Protocols

DoH / DoT / DoQ support enabled should be done. support in your s/w or support via network appliance Performance considerations of adding these protocol

Client subnet - performance of enabling

• QNAME minimization

Negative Trust Anchor Reporting - pros and cons of reporting

• DNSSEC validation

  • RFC9364

• QNAME minimization

  • RFC7816

• DoT

  • RFC7858

• DoH

  • RFC8484

• DoQ

  • RFC9250

  Need to add something about Designated Resolvers pros and cons of public resolvers enabling

• EDNS0 sizes to minimize fragmentation, especially for IPv6

  • draft-ietf-dnsop-avoid-fragmentation

• Aggressive NSEC caching

  • RFC8189

• EDNS client subnet

  • RFC7871

• DNS cookies shared secret

  • RFC7873

  • Local root (and maybe local TLD?)

  • RFC8806

• Verify root zone with ZONEMD

  • RFC8976

• TTL limits (max & min)

• TTL record pre-fetch

• DNS error reporting

  • draft-ietf-dnsop-dns-error-reporting

• Extended DNS Errors

  • RFC8914

• Negative trust anchors

  • RFC7646
  • Trust anchor reporting
  • RFC8145

[shane-kerr]

• DNSSEC validation Recommend that DNSSEC validation be enabled.

Negative caching based on NSEC and NSEC3 values can reduce traffic greatly, and is important to protect against random subdomain attacks. This is described in RFC 8198.

The root KSK must be updated when it changes. While RFC 5011 defines an automated way to do this, a resolver operator will probably either manage this trust anchor directly or get it updated via OS updates.

RFC9364 contains a lot of very useful material for DNSSEC operations in general.

• TTL limits (max & min)

Software typically defaults to a maximum stored TTL of 1 or 2 days. This may be lowered to reduce the cache size. A lower TTL will mean removing rarely-used records that have long TTL, and should not have much operational impact from a CPU or network point of view, but may safe memory.

It is possible to set a minimum TTL in many implementations. This is a violation of the DNS protocol, although may be useful to reduce load from records with very low TTL.

Note that software may set different maximum and minimum TTL independent of the results that the resolver returns. That may have a significant impact on queries as well.

• TTL record pre-fetch

Some resolvers have the ability to look up a record before it has expired from cache, in order to refresh the value and extend the TTL. This way there is never a time when the records are missing from the cache. This is not currently standardized, but a form of this was proposed in the IETF as https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-hammer-03. We recommend turning this feature on if available.

• Cache saving

Are there downsides? TODO: ask implementors for advice, DNS OARC list?

• Local root (and maybe local TLD?)
  • RFC8806

Using a local root is good. It is documented in the RFC.

This does not apply for most TLD, which change too frequently.

TODO: @shane-kerr will make a PR based on this comment