7 Authority: answering from owned facts

7.1 Finding the closest relevant authority

For a question (name, type), an authoritative server determines:

whether the name lies in a served zone;
whether a delegation cut is closer than that zone’s apex;
whether the exact name exists;
whether the requested RRset exists;
whether a CNAME or wildcard changes the answer;
which SOA proves a negative result.

A query beneath a delegated child should produce a referral, not an authoritative negative answer from the parent. A query outside all configured zones should normally be refused. These boundary checks matter more than a simple map lookup.

rgbdns’s Zone stores records in a BTreeMap<Name, Vec<Record>>, authoritative apices and delegation owners in ordered sets, and separate metadata for location and activation. Lookup walks name ancestry, recognizes cuts, filters visible records, applies exact-name and wildcard rules, and returns the typed Lookup outcome.

The response builder then:

copies the query ID and relevant RD bit;
marks authoritative answers with AA;
expands CNAME chains with a 16-hop limit and visited-name set;
adds address records for NS, MX, and SRV targets;
clears AA on referrals;
adds the SOA to negative answers;
maps malformed, unsupported, and policy cases to protocol response codes.

The finite CNAME bound and visited set are deliberate denial-of-service and correctness controls. A cyclic zone must not turn one datagram into unbounded work.

7.2 tinydns data as a source language

djbdns uses a compact line-oriented zone source called data. The first character selects a record form. Common forms include:

Prefix	Meaning
`.`	zone authority plus NS and address data
`&`	delegation NS and optional glue
`Z`	explicit SOA
`=`	A plus matching reverse PTR
`+`	A only
`6`	AAAA plus reverse PTR forms
`3`	AAAA only
`@`	MX and optional exchanger address
`C`	CNAME
`^`	PTR
`'`	TXT
`S`	SRV
`:`	generic record
`%`	client-location mapping

Fields are colon-separated with octal escapes for bytes that would otherwise be ambiguous. Optional fields carry TTL, timestamp, and location information. The format is terse because it was designed for mechanical generation as well as hand editing.

Zone::parse reads this language line by line. It ignores blank, comment, and disabled lines; reports the failing line number; expands convenience forms into ordinary typed records; validates IPv4, flat 32-digit IPv6, names, numeric ranges, and escaped bytes; and records authoritative and delegation structure. When an SOA serial is omitted, file loading derives a nonzero default from the source modification time.

Timestamp fields use TAI64-style cutoffs. Depending on the marker, a record can be visible before or after a specified instant. Location codes select records using configured client IPv4 prefixes. rgbdns carries that metadata beside the record and evaluates it at lookup time.

7.3 CDB: compile once, read predictably

The traditional tinydns-data compiles text into a constant database, CDB. The serving process reads the compiled file instead of reparsing editable text for every startup or query. Compilation also enables atomic replacement: write and validate a new file, then rename it into place.

rgbdns’s src/cdb.rs preserves the djbdns key/value layout. compile serializes typed records and metadata; load reads entries and reconstructs a Zone. The loader does not trust the database merely because it is local. It bounds file and entry sizes, validates keys, checks record layouts, decodes names and RDATA through explicit lengths, and rejects malformed data.

This is an important general rule: compiled configuration is still input. It may be truncated by a failed copy, generated by an older tool, or replaced by an attacker with filesystem access. Memory safety should not depend on the provenance story being perfect.