Opened 7 years ago

Closed 6 years ago

#2755 closed enhancement (wontfix)

the use of "list" structures for configuration considered harmful

Reported by: cas Owned by:
Priority: medium Milestone: Remaining BIND10 tickets
Component: configuration Version: bind10-old
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: discuss Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

configuration lists are very hard to deal with in BIND 10.

The index numbers change on additions and deletions, and the index number is not known in the beginning of a configuration session, it must first be looked up, which makes it impossible to change the values by scripting. In a large installation with thousands of zones, mapping zone configurations to index-numbers is very hard and error prone.

using named sets would be simpler to use, it would allow to script configuration changes

examples are
data_sources/classes/CLASS[]
Logging/loggers[]
Auth/datasources[]
Auth/listen_on[]
...

it would be simpler to reference the configuration items as named sets:

data_sources/classes/IN/sqlite3

or

Logging/loggers/boss-log/debuglevel

or

Auth/listen_on/192.0.2.53/port

or

Auth/datasources/memory/zones

List structures work well for configuration items that have no structure themselves (such as a list of IP addresses in an ACL).

Subtickets

Change History (5)

comment:1 follow-up: Changed 7 years ago by vorner

Auth/datasources should be deprecated. There's a need for list in data_sources (the ordering does matter, for performance and for preference if the zone is provided from more places).

The listen_on might need some more thinking how to do it, since you might want to listen on multiple ports on the same address and vice versa.

But I do agree in general.

comment:2 in reply to: ↑ 1 Changed 7 years ago by cas

Replying to vorner:

There's a need for list in data_sources (the ordering does matter, for performance and for preference if the zone is provided from more places).

while a "list" structure does matter for performance, it should only exist in memory in the processes, but not in the configuration files (neither on the server, nor in the API or in the user interfaces).

where ordering does matter, the configuration objects should have a property of "priority/preference" or "weight". DNS, DHCP and Network admins are familiar with that concepts (MX-, SRV-records, DHCP server priority, router priority in OSPF). The order is generated when the configuration is applied based on the relative values.

Using "priority/preference/weight" values, the values can be set without knowing the list index and without overwriting other existing configuration items.

comment:3 Changed 7 years ago by shane

  • Component changed from Unclassified to configuration
  • Milestone New Tasks deleted
  • Type changed from defect to enhancement

Sounds useful.

comment:4 Changed 6 years ago by tomek

  • Milestone set to Remaining BIND10 tickets

comment:5 Changed 6 years ago by tomek

  • Resolution set to wontfix
  • Status changed from new to closed
  • Version set to old-bind10

This issue is related to bind10 code that is no longer part of Kea.

If you are interested in BIND10/Bundy framework or its DNS components,
please check http://bundy-dns.de.

Closing ticket.

Note: See TracTickets for help on using tickets.