mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-21 17:48:07 +00:00
Code Issues Releases Wiki Activity
Page: Config system requirements
Pages
"main" branch partial history rewrite in August 2022 A few thoughts on Rust in BIND BIND 9 Achievements BIND 9 F2F Meeting in Warsaw, October 2019 BIND 9 Memory Explained BIND 9 PKCS11 BIND 9 Packaging BIND 9 Style Guide BIND 9.11 ESV Soft Code Freeze BIND 9.15 Plan BIND 9.17 Plan BIND 9.19 Plan BIND 9.19 Planning: CHANGES BIND 9.19 Planning: Configuration Backend BIND 9.19 Planning: DB notes BIND 9.19 Planning: Discuss new features BIND 9.19 Planning: Incident Manager Rotation BIND 9.19 Planning: Netmgr evaluation BIND 9.19 Planning: Refactor RBTDB BIND 9.19 Planning: Refactoring XFR BIND 9.19 Planning: Refactoring zone.c BIND 9.19 Planning: Refactoring BIND 9.19 Planning: Statistics System Overhaul BIND 9.19 Planning: Testing BIND 9.19 Planning: Things to do before BIND 9.18 cutoff BIND 9.21 Plan BIND Development and Release Process 2019 BIND development workflow CGroups v2 limiting resource consumption for testing CPU profiling using perf Config system requirements DNS Shotgun integration into Gitlab CI DNSSEC Key and Signing Policy (KASP) Data structure survey Debian Packages Escalation Engineer Duties Git Of Theseus Gitlab how to Integration tests wish list Internal objects and their relations Known Issues in BIND 9.18 Known Issues in BIND 9.20 Known Issues in BIND 9.21 LLM based tools thoughts Planning Policy for removing named.conf options Preparing Useful Merge Requests QP‑trie in NSD Requirements and Designs Server side Git hooks Serving stale data Stable Release Update Statistics Requirements SystemTap on 4326 remove locking from copy_namehook_lists SystemTap on main Team Meetings Testing by configuration options Updating resolver algorithm, or "who knows best, the parent or the child?" User space Probing in BIND 9 _sidebar benchmarks best practices caches dashboard home october2018meeting pytest howto stdatomic usage in master
Clone
8
Config system requirements
Vicky Risk edited this page 2025-04-14 20:15:37 +00:00

List of BIND-internal and external use-cases - to be used to validate new designs.

Prior work / further reading:

Stork requirements:

Sizing/environment/performance requirements:

  • 1 M zones
  • 1 M RRs in a zone
  • 10 M QPS
  • 128 CPUs/parallel access
  • config queries and/or changes must not block DNS request processing
  • granular changes are possible via a new config management API

Use-cases:

  • Retrieve default configuration
    • possibly without starting the server itself?
    • Would be great to find out uses cases of this to figure out in which format? Applies for "Retrieve full running configuration" as well
  • Validate configuration - before server (re)start
  • Start a server - should not take ages to parse & use config from disk
  • Retrieve full running configuration
  • Retrieve all values modified in local config (i.e. values which are inherited from default)
    • possibly without starting the server itself?
  • Retrieve a single subtree from config (e.g. config for zone example.com)
    • possibly without starting the server itself?
  • Retrieve a single value from config
    • possibly without starting the server itself?
  • Add or remove a zone, with all its config values
  • Add or remove a zone from a catalog zone
  • Add or remove a forward zone
  • Change a top-level config object shared by many zones - e.g. primaries, key etc.
  • Change a global or view-level value which is inherited by child objects (e.g. max-refresh-time change in a view must propagate to all zones in the view, unless zone overrides this specific config)
  • Change view definition - e.g. match-clients
  • Modify arbitrary config values via API
  • Efficient internal access to values (think of ACL - e.g. allow-query, update-policy) - must take care of inheritance as well
  • Efficient sequential access to repeatable clauses (zones, view, etc.) as this is hugely used this way in server.c initialization code
  • Obviously extremely efficient access in read-only state where the server is using configured values while it is running
  • Transactional API (so this ensures a reader has a consistent view of the configuration)