bind

Overview

BIND is the ISC DNS software package used for name service on Unix-like systems. Upstream describes it as open source DNS software that includes an authoritative server, a recursive resolver, and related utilities. In a Linux distribution, the package typically provides the DNS server software, client-side tools, and libraries needed to run or manage DNS services. (bind.isc.org)

For NiceOS maintainers, this repository exists to package BIND in a form that fits the distribution build process and update workflow. It is not a mirror of the full upstream source tree. Instead, it contains the packaging metadata, build instructions, and integrity manifests needed to rebuild the package from upstream sources. (bind.isc.org)

Purpose and typical use cases

Typical use cases for BIND include:

• running an authoritative DNS server for internal or external zones;
• running a recursive resolver for client networks;
• using BIND command-line tools for DNS administration and diagnostics;
• building DNS-related services that depend on BIND libraries or helper tools.

Typical users include:

• system and network administrators operating DNS infrastructure;
• developers who need DNS libraries, utilities, or test environments;
• security engineers reviewing DNS behavior, validation, or zone-signing workflows;
• CI/CD maintainers building and testing packages or appliances that depend on BIND;
• desktop or workstation users who only need the command-line tools, if the package set includes them in the distribution build.

The practical value of the package is that it provides a standard DNS implementation that can be managed, upgraded, and verified through the distribution packaging system rather than by manual upstream installation. (bind.isc.org)

Upstream project

Upstream BIND is maintained by ISC. ISC’s public project pages and documentation describe BIND as a DNS system for authoritative service, recursive resolution, and related administration tasks. The official project pages and documentation are the preferred references when checking intended behavior or packaging changes. (isc.org)

If a packaging change depends on a feature, a build option, or a behavior that is not obvious from the current spec file, NiceOS maintainers should verify it against upstream documentation before relying on it. (isc-projects.gitlab-pages.isc.org)

Dist-git repository contents

This dist-git repository normally contains the following top-level areas:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source manifest files and any small tracked metadata needed to describe the upstream inputs;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials data, when maintained for this package.

The repository is intended to hold packaging metadata, not the full upstream payload. Large upstream source archives are intentionally not stored in Git. Instead, the repository tracks the source inputs through manifest files in SOURCES/. That lets the package be rebuilt without carrying large binary-like archives in the repository history. (bind.isc.org)

Source storage and integrity policy

NiceOS uses manifests in SOURCES/ to record which upstream source inputs belong to this package. Those manifests are the place to check when validating whether the repository still points at the expected upstream material.

Before updating the package, verify that:

• the spec file still references the correct upstream source set;
• the SOURCES/ manifest entries match the intended upstream release materials;
• any regenerated packaging metadata was updated consistently;
• the repository does not accidentally include large upstream archives or unrelated build artifacts;
• the source set still matches the license and redistribution expectations for the package.

Do not treat the repository as the canonical storage for upstream sources. It is a packaging repository, and the integrity trail should remain in the source manifests rather than in checked-in archive blobs. (bind.isc.org)

NiceOS maintenance notes

Before updating BIND in NiceOS, check at least the following:

• read the upstream release notes and documentation for changed behavior, deprecated options, or build-system changes;
• confirm whether the spec file needs rebuilds of generated files, patches, or macro adjustments;
• review any changes to the SOURCES/ manifests and confirm the expected upstream input set;
• inspect SBOM/ if NiceOS maintains one for this package, and regenerate it if required by the update workflow;
• review whether packaging changes affect service files, configuration defaults, or subpackage split decisions;
• test the package on the target branch before pushing the update.

Risks to consider include:

• DNS software is operationally sensitive, so regressions can affect name resolution quickly;
• upstream build or feature changes may require spec adjustments;
• bundled patches may become stale and need revalidation;
• packaging changes may alter generated files or installed paths.

If a detail is not clearly confirmed by the spec, upstream docs, or repo contents, NiceOS maintainers should verify it explicitly before depending on it. (isc-projects.gitlab-pages.isc.org)

Build and verification checklist

For RPM maintenance work, a practical checklist is:

1. Review the spec file diff and the source manifest changes.
2. Confirm that the upstream source reference set still matches the intended release inputs.
3. Rebuild the SRPM and binary RPMs in a clean environment.
4. Run the package test suite or smoke tests that are available for the build.
5. Verify the installed files, subpackages, and scriptlets against expectations.
6. Check that service and configuration packaging still behaves correctly.
7. Confirm that any generated packaging artifacts were refreshed consistently.
8. Review build logs for new warnings, missing files, or unexpected feature toggles.
9. Validate that the resulting package still fits the branch policy for NiceOS.

If the package ships libraries or helpers used by other components, rebuild reverse dependencies or run the relevant integration checks before publishing the update.

References

• ISC BIND project page
• BIND project information
• BIND 9 documentation

Russian documentation

See README_RU.md.

Dist-git repository notes

• Package repository: rpms/bind
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.