aardvark-dns

Overview

aardvark-dns is an authoritative DNS server for container A and AAAA records. In practice, it helps container runtimes answer name lookups for containers on a network, while forwarding other queries to the configured resolver. Upstream notes that it is intended to work with Netavark, which can launch it automatically when both components are installed. (github.com)

For NiceOS, this package is part of the container networking stack rather than a standalone user-facing service. It is typically useful when container name resolution is expected to work through Podman and Netavark-based networking. Podman documentation refers to netavark/aardvark-dns in the context of network name resolution and aliases. (github.com)

Purpose and typical use cases

Typical use cases include:

• resolving container names on container networks managed by Netavark;
• supporting network-scoped aliases for containers and pods;
• providing DNS answers for container-to-container communication in test, staging, and local development environments;
• serving as the DNS component expected by Podman when Netavark-based networking is used. (github.com)

Typical users include:

• container platform maintainers and system administrators;
• developers running local container stacks;
• CI/CD maintainers that exercise container networking in automated jobs;
• anyone packaging or debugging Podman/Netavark networking on Linux. (github.com)

Upstream project

Upstream project: containers/aardvark-dns

The upstream repository describes aardvark-dns as a Rust-based authoritative DNS server for container records. NiceOS maintainers should treat the upstream README and release notes as the primary reference when checking behavior changes, configuration changes, or build expectations. (github.com)

Dist-git repository contents

This dist-git repository is organized in the usual RPM packaging layout:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source manifests and related integrity metadata;
• METADATA/ — package metadata used by the dist-git workflow;
• SBOM/ — software bill of materials data when present.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source storage metadata and integrity manifests in SOURCES/. That keeps the git history small and makes it easier to review packaging changes without carrying large binary blobs.

Source storage and integrity policy

The source policy for this package is to track source integrity through manifest files in SOURCES/, not by committing the full upstream source archive into git. NiceOS maintainers should verify that the manifest still matches the upstream source that the spec file expects before accepting an update.

Before relying on an update, check at least the following:

• the upstream source location still matches the packaging intent;
• the source manifest in SOURCES/ is refreshed correctly if the upstream archive changed;
• any spec file references to patches, licenses, or build helpers still apply;
• no new generated files were accidentally introduced into the repository;
• the package still builds cleanly with the target Rust toolchain and RPM macros used in NiceOS.

If the upstream project changes its build system, file layout, or release process, NiceOS maintainers should verify whether any packaging metadata needs to be regenerated.

NiceOS maintenance notes

Before updating this package, check the following:

• whether the upstream project changed its purpose, build instructions, or Netavark integration details;
• whether any patches in SPECS/ still apply cleanly;
• whether the spec file needs updates for changed build requirements, install paths, or binaries;
• whether SOURCES/ needs a regenerated manifest after refreshing the source input;
• whether SBOM/ or other generated metadata needs to be refreshed if NiceOS tracks it for this package;
• whether the update introduces behavior changes that affect container DNS resolution or the expectations of Podman/Netavark users.

Risks to consider:

• changes in upstream DNS behavior may affect container name resolution in existing environments;
• configuration or file layout changes may require spec updates;
• packaging changes in Rust projects can surface toolchain or dependency issues;
• integration assumptions with Netavark or Podman should be confirmed against current upstream documentation rather than assumed.

Build and verification checklist

A practical maintainer checklist:

• review the upstream release notes or changelog for behavior changes;
• confirm the spec file still matches current upstream build requirements;
• refresh source manifests in SOURCES/ if the upstream source input changed;
• rebuild the RPM in the NiceOS build environment;
• run package-specific tests if available upstream;
• verify that the installed files land in the expected paths;
• verify that the binary starts and prints help/version information correctly;
• if the package is expected to integrate with Netavark or Podman, perform a basic container DNS resolution check in a controlled test environment;
• inspect the resulting RPM for unexpected file additions, missing licenses, or missing documentation;
• confirm that SBOM or metadata files remain consistent if NiceOS policy requires them.

References

• Upstream repository: containers/aardvark-dns
• Podman documentation: network aliases and netavark/aardvark-dns
• Podman documentation: network create options
• Netavark upstream repository

Russian documentation

See README_RU.md for the Russian version of this document.

Dist-git repository notes

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