This is the multi-page printable view of this section. Click here to print.
Specifications
- 1: Infra mikrotik
- 2: Owned dns
1 - Infra mikrotik
1.1 - Infrastructure MikroTik
Purpose
Describe the checked-in RouterOS export snapshots and site DNS declarations for the dc1 routers. This package is a documentation and record-input owner: its BUILD file declares no router deployment executable. Export contents are historical source evidence, not a verification of current device configuration.
Baseline source revision: 550d7e79b1f5fdbc2b6017b75178471d6914082f.
Observation date: 2026-09-08. Sources are linked in full; no excerpts are used.
Sources: export workflow, package targets, router1 snapshot, router2 snapshot, and DNS declarations.
Requirements
Requirement: Preserve export snapshots as the package’s documented interface
The package SHALL retain the router export files as documentation inputs and
describe the RouterOS /export collection workflow. Documentation SHALL
distinguish these snapshots from automatically applied desired state. The
Terraform root SHALL manage DNS records only and SHALL NOT apply router exports.
Scenario: Inspect the router package
- WHEN a reader opens the component documentation
- THEN the reader can inspect both router export snapshots
- AND the Terraform package exposes owner-local DNS management while the snapshots remain documentary inputs
Requirement: Describe the two routers according to their recorded topology
The baseline description SHALL identify router1’s separate wired and wireless bridges with their own DHCP networks, and router2’s single bridge containing its eight Ethernet interfaces with a DHCP client. It SHALL NOT infer additional live devices or enabled topology from comments elsewhere in the repository.
Scenario: Compare the recorded network roles
- WHEN the two checked-in exports are compared
- THEN router1 records
bridge1for wired ports andbridge2for Wi-Fi ports - AND router2 records
bridge01and an IP DHCP client on that bridge
Requirement: Retain the recorded router1 traffic-policy structure
The router1 snapshot SHALL describe named interface lists for input and forwarding permissions, explicit terminal IPv4 input and forwarding drops, and source NAT masquerading for WAN egress. This contract describes the export and SHALL NOT be represented as a live firewall audit.
Scenario: Review router1’s recorded IPv4 policy
- WHEN a reader follows the IPv4 firewall section of the snapshot
- THEN the listed service permissions precede terminal input and forwarding drop rules
- AND the NAT section declares masquerading for traffic leaving the WAN list
Requirement: Supply site-local DNS records to the DNS owner
The package SHALL expose its dnsconfig.json as a Bazel filegroup. Its router,
switch, and bare-metal records SHALL be assigned to the dc1 destination view.
Scenario: Assemble the dc1 DNS configuration
- WHEN the DNS owner consumes
//infra/mikrotik:dnsconfig - THEN router1 IPv4 and IPv6 records and the declared switch and bare-metal IPv4 records are available for the dc1 view
2 - Owned dns
2.1 - owned-dns Specification
Purpose
Define MikroTik router DNS management through the owner’s tf root,
including canonical declarations, scoped credentials, and offline source checks
before adopting live records.
Requirements
Requirement: Owner-local DNS configuration
The tf root SHALL consume this owner’s canonical dnsconfig.json through
the shared DNS Terraform module, preserving declared record identities and views.
DNS resources SHALL default to disabled until the authorized adoption revision
and SHALL retain enabled ownership after existing records are imported into the
owner’s state. Reconciliation against unchanged declarations and adopted state
SHALL propose no record additions, changes, replacements, or deletions.
Scenario: Inspect the preparatory configuration
- WHEN the checked-in root is evaluated with default inputs before its authorized adoption revision
- THEN it reads this owner’s declaration and disables managed DNS records
- AND the package contains the module and declaration inputs
Scenario: Adopt existing DNS records
- WHEN the authorized adoption audits competing writers within its documented coverage, keeps identified competing writers stopped, and enables the owner’s record management
- THEN the owning root imports existing records by exact provider ID into its state while preserving their declared identities and views
Scenario: Inspect adopted source defaults
- WHEN the adopted root uses its checked-in source defaults
- THEN DNS ownership remains enabled and the package retains the module and canonical declaration inputs
Scenario: Reconcile existing DNS records
- WHEN the owning root plans against its adopted state and unchanged declarations
- THEN it proposes no record additions, changes, replacements, or deletions
Requirement: Scoped DNS execution and offline checks
The DNS wrapper SHALL select src_infra_mikrotik through the repository AL flow and keep
secret values in injected variables. DNS injection SHALL select the root’s existing
Terraform stage label. Real DNS credentials and Vault policy grants SHALL be
prerequisites for operational Terraform calls. RouterOS DNS credentials SHALL be isolated
from unrelated RouterOS resources. The package SHALL expose a format test that
does not authenticate to Vault or contact DNS providers.
Scenario: Validate the Terraform source
- WHEN the package format test executes
- THEN it checks the packaged Terraform configuration without live credentials
- AND existing non-DNS authentication and backend paths remain unchanged
Scenario: Prepare an operational Terraform invocation
- WHEN the wrapper selects its Terraform stage labels
- THEN it selects DNS credential injection through the owner AppRole
- AND disabled DNS resources do not imply offline provider configuration