The test stage was failing because molecule couldn't find the podman
driver. The issue was that 'molecule[podman]' extra doesn't exist in
molecule 25.12.0. Install 'molecule-podman' package instead which
provides the required podman driver for molecule.
- Add dnsutils and bind9-doc installation in prepare.yml
Ensures dig command and documentation are available for testing
- Enhance verify.yml with improved validation:
- Add named-checkconf syntax validation
- Improve error detection logic in BIND logs
- Add explicit error check assertions
- Increase log tail output from 20 to 30 lines for better diagnostics
These fixes address PR #14 review issues #3, #4, and #5:
- Issue #3: Molecule converge.yml configuration (valid, no changes needed)
- Issue #4: prepare.yml now installs required testing tools
- Issue #5: verify.yml now includes better validation and error checking
Related to: PR #14
- Added molecule/bind9-20 scenario for testing BIND9 9.20+ compatibility
- molecule.yml: Ubuntu 24.04 platform configuration
- converge.yml: Complete 9.20 configuration with TLS, DNSTAP, and modern features
- verify.yml: Comprehensive test cases for 9.20 features
- collections.yml: Required Ansible collections
- prepare.yml: Pre-test environment setup
- README.md: Scenario documentation with breaking changes reference
- Added docs/BIND9_9.20_SUPPORT.md implementation guide
- Architecture overview for multi-version support
- Runtime version detection strategy
- Configuration changes and examples
- Migration path for upgrading users
- Feature highlights for BIND9 9.20
- Updated meta/argument_specs.yml
- Added multi-version support documentation
- Documented bind9_version variable (read-only, auto-detected)
- Clarified supported BIND9 versions (9.18.x LTS and 9.20+)
These changes establish the feature/bind9-20-support branch as the development
path for BIND9 9.20+ support, separate from the main branch's 9.18.x focus.
Closes#9: Create feature/bind9-20-support branch with 9.20 templates
- Create step-by-step migration guide with pre-planning checklist
- Document all 44 breaking changes with explanations
- Provide before/after configuration examples
- Include Ansible role-specific changes and branch selection
- Add DNSSEC policy migration guidance
- Include testing recommendations and validation checklist
- Provide rollback procedures for safe migration
- Link to technical version differences documentation
Closes#6
- Generate BIND_VERSION_DIFFERENCES.md with detailed grammar comparison
- Document 44 breaking changes between BIND9 9.18.44 and 9.20.18
- Document 35 new options and 22 modified options in BIND9 9.20
- Document 3 newly deprecated options
- Add version compatibility section to CONFIGURATION_GRAMMAR.md
- Update CHANGELOG.md with version differences details
- Include migration guide for upgrading from 9.18 to 9.20
Closes#11
- Identify 9.18 branch as BIND9 9.18.x LTS support line
- Document supported platforms and backporting policies
- Link to version support policy and documentation
- Add version support table to README
- Link to VERSION_SUPPORT.md for detailed policies
- Add minimum requirements documentation
- Update license to GPL-3.0-or-later
- Add links to key documentation and contributing info
- Establish formal version maintenance strategy
- Define BIND9 9.18 (LTS) and 9.20+ support tiers
- Document branching strategy (main for 9.18, 9.20 for next major)
- Define backporting policies for security, bugs, features
- Create release management and CI/CD framework
- Add OS platform compatibility matrix
- Add version support table to README
- Link to VERSION_SUPPORT.md for detailed policies
- Add minimum requirements documentation
- Update license to GPL-3.0-or-later
- Add links to key documentation and contributing info
- Establish formal version maintenance strategy
- Define BIND9 9.18 (LTS) and 9.20+ support tiers
- Document branching strategy (main for 9.18, 9.20 for next major)
- Define backporting policies for security, bugs, features
- Create release management and CI/CD framework
- Add OS platform compatibility matrix
- Created primary.zoneopt.json to define grammar for primary zones with various options including allow-query, allow-transfer, and DNSSEC settings.
- Added redirect.zoneopt.json for redirect zones, specifying options like allow-query and primaries.
- Introduced secondary.zoneopt.json for secondary zones, detailing options such as allow-notify, forwarders, and notify configurations.
- Implemented static-stub.zoneopt.json for static stub zones, including server-addresses and server-names options.
- Added stub.zoneopt.json for stub zones, defining options like check-names and forwarders.
- Created zoneopt.json as a general template for zone options, incorporating common fields across different zone types.
- Quote octal file mode values (0640, 0750 -> '0640', '0750')
- Add 'Prepare' name to prepare.yml play
- Fix truthy value in .gitea/workflows/test.yaml (on -> 'on')
- Use role name 'bind9' instead of path in converge.yml
- Move tags to top-level for Deploy and Validate Configuration block
- Remove unnecessary comments to clean up code
- Ensure all YAML and Ansible files pass ansible-lint production profile
- Fix line length in meta/argument_specs.yml (wrap long description)
- Remove extra blank lines in molecule/default/collections.yml
- Fix line lengths in tasks/main.yml (wrap long messages)
- Remove trailing spaces from tasks/main.yml
- Ensure all YAML files pass yamllint with relaxed profile
- Add yamllint for YAML style validation (relaxed profile)
- Add ansible-lint for Ansible best practices (production profile)
- Add Molecule test job that runs only on pull requests
- Lint job runs on all push events to main and feature branches
- Test job depends on lint job passing
- Clean, maintainable pipeline configuration
- Create converge.yml with forwarding DNS configuration
- Configure global forwarders with Google and Cloudflare DNS
- Configure forward-only zone for internal.example with TLS
- Create verify.yml with comprehensive test validation
- Test BIND9 installation, service status, and configuration files
- Verify forwarders and forward zones are properly configured
- Test actual DNS resolution via forwarders
- Add clarification on different parameter combinations (port/dscp vs port/tls)
- Replace generic 'IP_PORT_DSCP_OPTION' with 'ADDRESS_PORT_TLS_OPTION' example
- Update all configuration examples to show port/tls parameters
- Document usage of forwarders with TLS support
- Improve documentation of flexible configuration formats
- Add tls parameter to forwarders grammar in options section
- Add tls parameter to forwarders grammar in zone section
- Update options and zone examples to demonstrate tls usage
- Rename 'Address with Port/DSCP' section to 'Address with Port/TLS'
- Update all data type examples to show port/tls patterns instead of port/dscp
- Document global and per-address port/tls configuration options
- Update named.conf.options.j2 to use parent_address_port_tls for forwarders
- Update named.conf.zone.j2 to use parent_address_port_tls for forwarders
- Enables support for per-address and global port/tls parameters
- Add list_address_port_tls macro for rendering address lists with port and tls parameters
- Add parent_address_port_tls macro for parent statements with global port/tls
- Follow existing naming pattern with separate list_ and parent_ macros
- Supports forwarders, primaries, and similar blocks with port/tls grammar