Infrastructure · Split-horizon · Private records · Federated-by-default
The problem
A large enterprise has a DNS name (bigcorp.com, chase.com,
kp.org, <university>.edu). They want:
Cryptographic proof that they control that name,
referenceable by partners, regulators, customers, and
other Quidnug-native services.
Authoritative resolution for their own records. Not
“my DNS resolves to an IP address from a cache somewhere.”
Rather: “queries for records on my domain are served by
nodes I control, and I decide what’s publicly queryable
versus restricted versus private.”
Split-horizon visibility. Some records should be
public globally (the main website IP, the MX record).
Some should be visible only to trusted partners (partner
API endpoints, B2B integration URLs). Some should be
private and cryptographically unreadable to anyone outside
the organization (employee directory, internal service
discovery, board-level communications).
Auditable change trail. Every record modification is
signed, stamped, attributable. No more “we don’t know who
updated that DNS record last Tuesday.”
Legacy compatibility. Existing DNS stays intact. Nobody
has to change their resolver. The Quidnug layer is additive.
Current state of the art: traditional DNS + Active Directory
DNS + corporate DNS vendors + internal secret-sharing tools +
VPN-gated service discovery. Six to eight separate systems
per enterprise, all with different ownership, different
access rules, different audit capabilities, different failure
modes.
Why Quidnug fits
All the pieces exist in the protocol now (post-QDP-0023 +
QDP-0024) to collapse these six-to-eight systems into one:
The enterprise pays the one-time attestation fee (typically
$5-25 depending on TLD), delegates resolution back to their
own consortium (already operational per their Quidnug
deployment), and gets the whole stack for free.
This use case documents how to do it end-to-end.
The reference scenario
Throughout this folder we use BigCorp as a running
example:
BigCorp owns bigcorp.com (registered with standard
registrar, 20 years old).
BigCorp operates ~3,000 employees across 12 offices
globally.
BigCorp has ~150 partner organizations integrating with its
APIs.
BigCorp has an existing Quidnug consortium running the
interbank-wire-authorization use case (three validators, 8
cache replicas, ~50k wires/day). They want to extend that
consortium to serve as their DNS authority rather than
standing up a separate one.
Public tier: A / MX / bare TXT records. Served from
any cache replica globally. Same UX as today’s DNS.
Trust-gated tier: Partner APIs, B2B URLs. Served to
clients whose trust graph reaches bigcorp.com.partners
above threshold. Non-qualifying clients get NXDOMAIN.
Private tier: Employee directory, internal service
discovery, board comms. Encrypted via QDP-0024 group keys.
Only members of bigcorp.com.employees (or sub-groups)
can decrypt.
Concrete ergonomics
Public record (website IP)
Terminal window
quidnug-clirecordspublish\
--domainbigcorp.com\
--record-typeA\
--name"@"\
--value203.0.113.42\
--ttl300\
--visibilitypublic\
--sign-with<bigcorp-owner-key>
Any resolver globally can query this. Cache replicas
everywhere serve it. Cryptographically verifiable.
Trust-gated record (partner API)
Terminal window
quidnug-clirecordspublish\
--domainbigcorp.com\
--record-type"TXT/API"\
--name"_api.partners"\
--value"https://api.bigcorp.com/v2/"\
--ttl3600\
--visibility"trust-gated:bigcorp.com.partners"\
--min-trust0.5\
--sign-with<bigcorp-owner-key>
To query successfully, client must have a trust edge chain
reaching bigcorp.com.partners with weight ≥ 0.5. Every
approved partner organization has this edge (established at
partnership-agreement signing). Non-partners get NXDOMAIN
indistinguishable from a non-existent record.
Private record (employee directory)
Terminal window
quidnug-clirecordspublish\
--domainbigcorp.com\
--record-type"TXT/EMP"\
--name"_directory.employees"\
--value-filedirectory.json\
--ttl1800\
--visibility"private:bigcorp.com.employees"\
--sign-with<bigcorp-owner-key>
Payload is encrypted with the current epoch key of the
bigcorp.com.employees group (QDP-0024). Cache replicas
store ciphertext; only employees with their group leaf key
can decrypt. When an employee leaves, group rotates epoch
and the departing employee loses future access (past
records they saw remain readable, by design).
The value proposition
Capability
Traditional stack
Quidnug
Public DNS
BIND / Cloud DNS
Quidnug public records
Split-horizon internal DNS
BIND views / AD DNS
Quidnug trust-gated
Private service discovery
Consul / etcd / internal VPN
Quidnug private + QDP-0024
Secret management
Vault / K8s secrets / 1Password Teams
Quidnug encrypted events
Change audit
Cloud provider audit logs + SIEM
Quidnug signed events (always-on)
Key rotation
Manual per-system
QDP-0002 guardian recovery
Key recovery
Varies per system
QDP-0002 guardian recovery
Employee offboarding
Touch ~8 systems
Remove from group; epoch rotates
Partner onboarding
Touch ~5 systems
Grant trust edge to partners domain
Multi-region availability
Per-system setup
Inherent (QDP-0014 cache tier)
TLS cert continuity tracking
Manual / CT-log monitoring
Attestation carries fingerprint
Compliance / audit export
Custom per-system
Single chain query
Single system to operate. Single audit trail. Single key
management surface. Compliance teams get a single query
target. Ops teams get one on-call rotation rather than six.
split_horizon.py, pure decision logic for the three
visibility tiers (public / trust-gated / private).
split_horizon_test.py, 13 pytest cases.
demo.py, five-step end-to-end flow: register BigCorp
actors, publish records in all three tiers, build trust +
membership graphs, and demonstrate that outsider / partner /
employee each see a different subset of the zone.
Banks already running Quidnug for interbank wires
(per the existing use case). DNS authority is a natural
extension with very high value (compliance + partner
auth + internal service discovery all collapse).
Universities with .edu (free attestation tier).
Transcripts + credentials + research-computing service
discovery all fit the same model.
Healthcare systems with .org and HIPAA
requirements. Private tier is the critical feature,
PHI-bearing directory services encrypted at rest.
Large SaaS companies running multi-region
infrastructure + partner ecosystems. Split-horizon DNS +
partner API discovery in one system.
Government agencies with .gov (free tier). Public
records + private internal coordination + inter-agency
trust edges.
Status
Design. Builds on QDP-0023 + QDP-0024 (both Draft). Reference
implementation scheduled for 2026-Q3 alongside the QDPs.
Architecture
Data model, components, sequence diagrams.
Enterprise domain authority architecture
Detailed data model, AUTHORITY_DELEGATE payload structure,
and group-key management for enterprise split-horizon
domains. Companion to README.md.
1. Data model overview
Every enterprise domain after attestation + delegation has
five moving parts:
Root DNS attestation (per QDP-0023), the signed
binding from DNS name to quid. Lives on the federated
attestation root’s ledger.
Authority delegation (per QDP-0023 AUTHORITY_DELEGATE)
the signed “who serves records” pointer. Lives on the
owner’s control domain.
Record events (per standard Quidnug event schema),
the actual record data. Lives on the delegated domain’s
event stream.
Trust-gate edges (per standard TRUST transactions),
what controls access to trust-gated:* records. Lives on
the access-control domains (<domain>.partners, etc.).
Group state (per QDP-0024), the TreeKEM groups that
back private:* records. Lives on per-group governance
domains.
Most of this tree is already present if BigCorp is running
any prior Quidnug use case (interbank wires, reviews, agent
authorization). Adding DNS authority adds mostly just the
.public, .partners, .employees, .board subdomains
plus the AUTHORITY_DELEGATE event.
3. The AUTHORITY_DELEGATE event (canonical form)
Generic form defined in QDP-0023 §3.3. Full enterprise
example:
delegate_nodes: the three validator quids that serve
records authoritatively. Clients prefer these for fresh
reads. Cache replicas everywhere store ciphertext/trust-
gated data and serve per policy.
delegate_domain: all record events for bigcorp.com
flow through this Quidnug domain. BigCorp’s existing
consortium (from the wire-authorization deployment) hosts
the domain.
visibility.record_types: per-record-type policy.
Granular down to “record type + subtype pattern.” Wildcard
matches apply.
default: fallback when a record’s type doesn’t match
any explicit rule. Safe default (trust-gated) prevents
accidental public leakage of new record types.
fallback_public: false: if delegate_nodes are
unreachable, don’t fall back to serving public records
from cache tier. Stricter availability but prevents stale-
cache leakage during delegation issues.
4. Record event schema
Standard Quidnug EVENT transaction with a record-specific
payload. Example public record:
{
"type": "EVENT",
"trustDomain": "bigcorp.com",
"timestamp": 1729468800000000000,
"subjectId": "bigcorp.com",
"subjectType": "DOMAIN",
"sequence": 42,
"eventType": "DNS_RECORD",
"payload": {
"recordType": "A",
"name": "@",
"value": "203.0.113.42",
"ttl": 300,
"visibility_class": "public"
}
}
Trust-gated record:
{
"type": "EVENT",
"trustDomain": "bigcorp.com",
"sequence": 43,
"eventType": "DNS_RECORD",
"payload": {
"recordType": "API/v2",
"name": "_api.partners",
"value": "https://api.bigcorp.com/v2/",
"ttl": 3600,
"visibility_class": "trust-gated",
"gate_domain": "bigcorp.com.partners",
"min_trust": 0.5
}
}
Private record (encrypted payload):
{
"type": "EVENT",
"trustDomain": "bigcorp.com",
"sequence": 44,
"eventType": "ENCRYPTED_RECORD",
"payload": {
"groupId": "bigcorp.com.employees",
"epoch": 7,
"contentType": "dns-record",
"nonce": "a1b2c3d4e5f6...",
"ciphertext": "...",
"aad": ""
}
}
The ENCRYPTED_RECORD wraps the inner DNS-record payload.
Plaintext (after decryption):
3. Cache replica sees visibility_class=private, group_id=
"bigcorp.com.employees".
4. Cache replica doesn't need to verify membership, ciphertext
is returned regardless, but only group members can decrypt.
5. Client checks: am I a member of bigcorp.com.employees at
epoch 7? (Consults group state events.)
6. If yes: derive K_epoch_7 via TreeKEM tree walk, decrypt the
record, return plaintext.
7. If no: decryption fails. Client treats as NXDOMAIN.
Cache serves encrypted data freely (no crypto on the hot
path). Decryption happens client-side. Membership checks are
also client-side (TreeKEM state is stored per member).
6. Group management for private records
6.1 Groups backing DNS visibility
Typical BigCorp groups:
Group ID
Type
Members
Records encrypted
bigcorp.com.employees
dynamic
All quids with trust edge into bigcorp.com.employees ≥ 0.3
See operations.md §3 for the full runbook.
Short version:
New employee generates a quid (via corporate onboarding
portal or directly on their device).
Employee publishes their MEMBER_KEY_PACKAGE event
(QDP-0024 §6.3).
HR governance signs a TRUST edge from bigcorp.com.employees
to the new employee at level 1.0.
Since the bigcorp.com.employees group is dynamic with
threshold 0.3, the employee is auto-added on next epoch.
A group member (typically IT ops) signs the
EPOCH_ADVANCE event adding the new employee to the tree.
New employee receives welcome package; decrypts to derive
current epoch key.
Employee can now decrypt all records published from this
epoch forward.
Optional: group members choose to re-wrap historical epoch
keys for the new employee so they can read past records
(useful for role-based onboarding that needs history
access).
6.3 Offboarding an employee
HR governance signs TRUST edge revocation (or lets the
edge expire via QDP-0022 ValidUntil).
Next EPOCH_ADVANCE blanks the departing employee’s
leaf; path updates.
Departing employee cannot derive new epoch keys.
Past-epoch keys they hold remain valid for reading
records written while they were a member (by design).
Optional (compromise response): force immediate epoch
advance if the employee is suspected of exfiltration.
Offboarding takes < 1 block interval to take effect on new
records. No coordination with 6 separate systems.
6.4 Partner onboarding
Partners don’t join groups; they receive a TRUST edge:
Partner registers their org quid (via their own Quidnug
deployment or as a sub-identity under a partnership
registration).
BigCorp governance quorum signs a TRUST edge from
bigcorp.com.partners to the partner at a negotiated
level (e.g., 0.8 for deeply-integrated partners, 0.5 for
standard integration).
Partner can now query trust-gated records with their
quid.
Partnership agreements carry a validUntil per QDP-0022,
so the trust edge auto-expires at contract end.
7. Multi-region considerations
Large enterprises have multi-region deployments. QDP-0014
sharding handles this naturally:
7.1 Cache tier spread
Caches replicas in each region (US-East, US-West, Europe,
Asia-Pac). Public records served from nearest cache.
Trust-gated records require trust-graph walk; caches can
short-circuit via local graph state or defer to validators.
Private records served from any cache (ciphertext; client-
side decrypt).
7.2 Validator placement
BigCorp’s 3 validators (from the wire-authorization
deployment) might be in US-East / US-West / Europe.
Authoritative writes happen at validators; gossip replicates
to cache tier within a block interval.
7.3 Regional policy variance
Some records may have region-specific visibility (e.g., EU
employees can read EU-only records but not US HR records).
Implemented via sub-groups:
bigcorp.com.employees.eu (EU staff only)
bigcorp.com.employees.us (US staff only)
bigcorp.com.employees (all staff; superset group)
Records encrypted with the appropriate subgroup’s key.
8. Interaction with TLS / certificate infrastructure
BigCorp’s TLS certs are issued by standard CAs. The DNS
attestation captures the TLS fingerprint at verification
time (QDP-0023 §4.3). On cert rotation:
BigCorp gets new cert (normal CA flow).
On next DNS attestation renewal, new TLS fingerprint is
captured.
The renewal event’s fingerprintRotationProof field
includes the CT-log entry chain connecting old to new
cert (proves legitimate rotation vs. adversary swap).
Attestation renews successfully.
For TLSA (DANE-style) records, BigCorp can also publish
their TLS public-key hash as a TXT/TLSA public record.
Relying parties that support DANE validate the TLS cert
against this published key, bypassing the CA entirely.
9. Interaction with identity management
Enterprise identity lives in HR systems + IAM (Okta,
AzureAD, etc.). Integration pattern:
IAM remains source of truth for “who works here.”
HR onboarding provisions a Quidnug quid for each new
hire + publishes trust edge in bigcorp.com.employees.
IAM offboarding revokes the trust edge.
Quidnug group membership derives automatically from the
trust edges (dynamic groups).
For smaller orgs without IAM integration, everything can be
manual (CLI-based).
10. Observability + audit
Every operation on the enterprise domain is a signed event.
BigCorp can run standard Quidnug observability (QDP-0018):
Per-operator hash-chained audit log.
Periodic on-chain anchoring.
Five verification endpoints.
Standardized metric label set.
Compliance officers get a single query target for “who
accessed what when.” Regulatory queries resolve in seconds
rather than weeks.
Motivated by: disruption; sybil attacks on the trust
ecosystem.
Capability: issue counterfeit attestations.
2. Attack vectors + defenses
2.1 Attestation-layer attacks
V1. Fake attestation via rogue root.
Attack: A11 stands up a root, attests bigcorp.com to an
attacker-controlled quid.
Defense: trust weighting. Rogue root has near-zero trust
weight; its attestation loses in weighted comparison to
BigCorp’s legitimate multi-root attestations.
Residual: clients that manually trust the rogue root get
the rogue attestation. Client default-list curation keeps
rogues out of the reference SDK defaults.
V2. Attestation takeover via DNS/registrar compromise.
Attack: A2/A3 compromises BigCorp’s registrar, changes
nameservers, publishes their own _quidnug-attest.* TXT,
claims a new attestation.
Defense:
Multi-resolver TXT consistency check (A3 must coordinate
globally simultaneously).
TLS fingerprint continuity: new attestation’s TLS
fingerprint differs from BigCorp’s known rotation chain
→ rejection.
Multiple roots: attacker must compromise each root’s
verification path.
Revocation: legitimate BigCorp retains root quorum
signatures to revoke the fraudulent attestation.
Residual: A3-level attacker with CA cooperation + global
resolver manipulation is a real risk. Mitigation: RLA-style
continuous monitoring for attestation changes.
V3. TLS cert rotation as cover for takeover.
Attack: attacker coordinates fresh TLS cert issuance via
CA compromise and uses it for the well-known endpoint
during fake attestation.
Defense: CT-log verification. All legitimate TLS certs
must appear in CT logs; attestation renewal proof must
include the CT-log chain. A fresh cert without
plausible-continuity CT-log entries is rejected.
Residual: CT-log compromise is a separate but high-bar
attack.
2.2 Delegation-layer attacks
V4. Delegation authority hijack.
Attack: attacker publishes a fraudulent
AUTHORITY_DELEGATE event claiming to be BigCorp.
Defense: event signature validation. AUTHORITY_DELEGATE
must be signed by the quid named in the attestation’s
owner_quid field. Attacker doesn’t have the owner-quid’s
private key.
Residual: if A8/A10 compromises the owner-quid key
directly, they can redirect delegation. Mitigation:
guardian quorum can sign revocation + new delegation.
V5. Malicious delegate node.
Attack: BigCorp delegates to node X; node X’s operator
serves malicious or altered records.
Defense: every record event is signed by the authorized
publisher (BigCorp’s record-ops quid). Delegate cannot
forge records; can only serve or refuse to serve.
Consortium membership is visible; BigCorp sees which node
is misbehaving.
Residual: delegate can delay or censor (temporary denial).
Mitigation: multiple delegate nodes (quorum); clients
prefer fresh data from validators over cache.
2.3 Trust-gated record attacks
V6. Unauthorized access to trust-gated records.
Attack: A1 tries to query trust-gated partner API records
without a trust edge.
Defense: cache replica checks GetTrustLevel(client_quid, gate_domain, min_trust). No edge → NXDOMAIN (not “access
denied”; indistinguishable from nonexistent record).
Residual: A1 can still probe for existence via indirect
means (timing attacks, error-message differentiation);
mitigation is constant-time responses + no error-message
differentiation on query-time.
V7. Partner collusion.
Attack: A4 partner shares their trust edge / quid with a
third party.
Defense: not defended. Trust edges are transferable key
material; if partner misbehaves, their trust edge is
revoked + partnership agreement invoked.
Detection: monitoring for unusual query patterns from
a partner quid.
V8. Expired-edge exploitation.
Attack: A5 ex-partner continues querying records using
an expired trust edge; cache tier fails to enforce TTL.
Defense: QDP-0022 ValidUntil enforcement. Cache replicas
check ValidUntil against local clock; expired edges are
skipped.
Residual: brief window of cache staleness (< TTL). Mitigation:
short TTL on sensitive trust edges.
2.4 Private record attacks
V9. Group membership analysis.
Attack: A1 observes which quids are in which groups by
analyzing epoch-advance events + member-key-package
publications.
Defense: partial. Group membership is public metadata by
design; encrypted-record content is private.
Residual: org-chart inference is possible. Mitigation:
opaque group naming (group-a3f2b9), periodic reshuffling,
or off-chain communication for truly sensitive structure.
V10. Post-membership access retention.
Attack: A7 departing employee retains past-epoch keys;
reads records from epochs they were a member of.
Defense: by design, past access is preserved. Mitigation
for sensitive data: rotate groups per-sensitivity-level,
shorter history retention per-group policy, cryptographic
shredding (destroy past-epoch keys when retention expires).
V11. Compromised employee key.
Attack: A8 adversary has employee’s X25519 private key;
decrypts ongoing encrypted records.
Defense: compromise-response epoch rotation. Once detected,
the compromised key’s future access is revoked within
one epoch advance.
Residual: records published between compromise and detection
are exposed. Mitigation: scheduled epoch rotation (default
90d); short rotation interval for high-sensitivity groups.
V12. Forward-compromise attack.
Attack: A2 captures current epoch key; reads future
records until they’re detected.
Defense: compromise-response rotation; post-compromise
security ensures future keys are not derivable.
Residual: same window issue as V11.
2.5 Governance attacks
V13. Rogue group admin.
Attack: A6 employee with group-admin privileges forcibly
advances epochs or excludes legitimate members.
Defense: every EPOCH_ADVANCE is audited; affected
members detect exclusion quickly.
Mitigation: governance quorum required for certain
sensitive actions (remove member from board group, etc.).
Residual: temporary disruption possible; full recovery
within hours.
V14. Governance quorum compromise.
Attack: A10 takes over a majority of governors.
Defense: no defense against majority compromise by
design. Mitigation: guardian quorum on each governor
key (QDP-0002) means majority-compromise requires
compromising majority of (governor AND their guardians).
Residual: catastrophic-compromise scenario; full system
re-initialization required.
2.6 Cache + consortium attacks
V15. Cache-stored ciphertext harvest.
Attack: A1 cache-replica operator (or their compromised
counterpart) harvests all encrypted records + attempts
offline decryption.
Defense: AES-GCM-256 is computationally infeasible to
break offline without the group key.
Residual: “harvest now, decrypt later” remains a concern
if quantum computers break X25519 key agreement
retrospectively. Mitigation: QDP-0024 roadmap includes
post-quantum migration.
V16. Validator censorship.
Attack: A9 compromised validator refuses to include
BigCorp’s record-update transactions.
Defense: consortium quorum (2-of-3) means one bad
validator cannot fully censor; transactions go via the
remaining validators.
Residual: brief latency increase during censorship.
3. Comparison with legacy split-horizon approaches
Property
BIND + views
AD DNS + VPN
Consul + Vault
Quidnug
Public record integrity
Unsigned; DNSSEC optional + rare
Unsigned
Internal to org
Signed by construction
Access-control granularity
Source IP / ACL
AD group
Service-mesh policy
Trust-graph edge
Audit trail
System logs (fragile)
AD event logs + SIEM
Consul audit + Vault audit + SIEM
Signed events (tamper-evident)
Key rotation
Manual per key
Manual
Manual
Guardian recovery primitive
Compromise response
Manual
Manual
Manual
Epoch rotation automated
Employee offboarding
~8 systems touched
~8 systems
~6 systems
1 trust revocation + 1 epoch advance
Partner revocation
Manual per system
Manual
Manual
1 trust revocation
Private record encryption
External tool required
External tool
External tool
Native QDP-0024
Multi-region
Per-system config
Per-system config
Per-system config
Native QDP-0014
Cryptographic DNS ownership proof
None
None
None
QDP-0023 attestation
Key recovery on loss
Varies; often catastrophic
Domain admin reset
Vault recovery keys
Guardian quorum
Cost
Low ops, high integration
High
High
Medium (one system)
4. What this design deliberately does NOT defend against
Full compromise of the owner quid. If A2 obtains the
BigCorp owner-quid’s private key + all its guardians,
they own the domain. Mitigation relies on key-custody
discipline (HSMs, dual control, 5-of-7 guardian quorums).
Nation-state infrastructure control. Simultaneous
compromise of DNS, CT logs, multiple attestation roots,
and BigCorp’s governance is not defended. Design assumption:
such actor has achieved catastrophic capability and
cryptographic measures alone cannot help.
Traffic analysis / metadata observation. Observers
can see that encrypted records exist, their sizes, timing,
and which group they belong to. Applications needing
metadata privacy layer additional primitives (cover
traffic, rate padding, off-chain channels) on top.
Physical access to employee devices. If an attacker
has physical access to an employee’s device + extracts
their X25519 key, they have the employee’s access. Use
device-level keystore (Secure Enclave / TPM / YubiKey)
to raise the bar.
Coercion. An employee compelled to share group keys
cannot be defended against by cryptography. Operational
discipline (group admin reviews access patterns) and
legal process apply.
Supply-chain compromise. If the Quidnug node binary
is backdoored upstream, the threat model breaks down.
Reproducible builds + audit discipline help; doesn’t
eliminate.
Long-term cryptographic advances. X25519 is not
post-quantum. Future migration required. QDP-0024 §16
flags this as open work.
5. Risk prioritization
For a typical enterprise deployment, risk likelihood + impact:
Risk
Likelihood
Impact
Priority
V11 compromised employee key
Medium
Medium
High
V2 registrar/DNS compromise
Low
High
High
V9 group membership analysis
High
Low
Medium
V16 validator censorship
Low
Medium
Medium
V14 governance compromise
Very Low
Catastrophic
High
V1 rogue root
Medium
Low (low weight)
Low
V10 post-membership retention
Low (by design)
Low
Low
V5 malicious delegate
Low
Medium
Medium
6. Recommended security discipline
Enterprise deployment should implement all of:
HSM-backed owner + governor keys. Non-negotiable.
5-of-7 guardian quorums on governance keys.
Multi-root attestation (≥2 independent roots).
Automated CT-log monitoring for TLS cert changes.
Scheduled epoch rotation on all private groups (90d
default, 30d for high-sensitivity).
Compromise-response runbook rehearsed quarterly.
Independent penetration testing annually.
Key-ceremony room for key generation (air-gapped +
paper backup).
Dual-control on sensitive operations (group admin +
governor required for board-group changes).
Third-party audit of operational discipline annually.
How this use case layers onto existing Quidnug
deployments: what to reuse, what to add fresh, how to
bootstrap from nothing. Companion to
README.md + architecture.md.
1. Three deployment starting points
1.1 Starting from an existing Quidnug consortium
If BigCorp already runs Quidnug for another use case (e.g.,
interbank-wire-authorization), they extend the existing
consortium:
Add: DNS attestation claim (pay + verify at a
federated root), AUTHORITY_DELEGATE event, record
publishing flow, employee + board + partner groups.
Implementation effort: ~1 person-week. Most infrastructure
is already in place.
1.2 Starting greenfield
If BigCorp has no existing Quidnug deployment, they bootstrap
minimal infrastructure first:
Deploy ≥2 Quidnug validator nodes (preferably 3+ for
resilience).
Configure governor quorum.
Stand up consortium per the standard deployment (see
deploy/public-network/ + helm/).
Then claim the DNS attestation + delegate authority.
Implementation effort: ~3 person-weeks including
infrastructure.
1.3 Starting as a consumer (no own consortium)
Smaller orgs can skip running their own nodes and delegate
authority to a provider’s consortium (a “managed Quidnug
DNS” service run by a trusted third party):
Add: only the DNS attestation claim + an
AUTHORITY_DELEGATE pointing to the provider’s nodes.
Owner still holds their own signing key for publishing
records; provider just serves them.
Implementation effort: ~1 day. Trade-off: trust in the
provider’s operational integrity (they can’t forge records
because those are signed by owner’s key, but they can refuse
to serve them or slow down publication).
2. Integration with QDP-0023 attestation
2.1 Claim flow
1. BigCorp generates (or reuses) a Quidnug quid:
$ quidnug-cli identity create \
--name "bigcorp-owner" \
--save-to ~/.quidnug/bigcorp-owner.key
2. BigCorp initiates the claim at a federated root:
$ quidnug-cli dns claim \
--domain bigcorp.com \
--root quidnug.com \
--owner-key ~/.quidnug/bigcorp-owner.key \
--payment-method stripe \
--requested-valid-until 2027-04-20T00:00:00Z
3. CLI returns the TXT record + well-known file content.
BigCorp publishes both:
DNS TXT at _quidnug-attest.bigcorp.com
File at https://bigcorp.com/.well-known/quidnug-domain-attestation.txt
4. BigCorp pays the $5 standard-tier fee via Stripe link.
5. Root's verifier runs the full verification pass
(multi-resolver DNS + TLS fingerprint + WHOIS + blocklist).
6. Root publishes DNS_ATTESTATION event.
7. Attestation now visible across federation.
Time from step 1 to step 7: typically 10-30 minutes. Most of
it is Stripe + DNS propagation.
2.2 Multi-root stacking
For high-stakes domains (bank, government), BigCorp pays
multiple independent roots:
$ quidnug-cli dns claim --domain bigcorp.com --root quidnug.com
$ quidnug-cli dns claim --domain bigcorp.com --root eff.quidnug
$ quidnug-cli dns claim --domain bigcorp.com --root cloudflare.quidnug
Three independent attestations; combined trust weight near
saturation. Phishing operators can’t get all three.
2.3 Renewal automation
Attestations expire (typically 1 year). Automate renewal in
CI/CD:
.github/workflows/quidnug-renew.yml
name: Renew Quidnug DNS attestation
on:
schedule:
- cron: '0 0 1 * *'# monthly check
jobs:
renew:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check attestation status
run: |
quidnug-cli dns status --domain bigcorp.com \
--exit-zero-if-valid-for "90d"
- name: Renew if needed
if: steps.status.outcome == 'failure'
run: |
quidnug-cli dns renew --domain bigcorp.com \
--owner-key-secret ${{ secrets.QUIDNUG_KEY }}
Automatic renewal 30+ days before expiry. No manual
coordination needed.
3. Integration with QDP-0024 groups
3.1 Group creation
$ quidnug-cli groups create \
--group-id bigcorp.com.employees \
--type dynamic \
--dynamic-trust-domain bigcorp.com.employees \
--dynamic-min-trust 0.3 \
--policy-rotation-interval 90d \
--policy-max-members 10000 \
--governor-key ~/.quidnug/hr-governor.key
Creates GROUP_CREATE event + initial epoch key. Members
are everyone with trust edge into bigcorp.com.employees
at level ≥ 0.3 (dynamic).
3.2 Adding members
In the dynamic case, adding a member = granting the trust
edge:
$ quidnug-cli trust grant \
--truster bigcorp.com.employees \
--trustee <new-employee-quid> \
--level 1.0 \
--valid-until 2027-04-20T00:00:00Z \
--sign-with ~/.quidnug/hr-governor.key
$ quidnug-cli groups advance-epoch \
--group-id bigcorp.com.employees \
--reason member-added \
--added <new-employee-quid> \
--sign-with ~/.quidnug/group-admin.key
The advance-epoch command publishes EPOCH_ADVANCE with
path update + welcome package for the new member.
3.3 Removing members
$ quidnug-cli trust revoke \
--truster bigcorp.com.employees \
--trustee <departing-employee-quid> \
--sign-with ~/.quidnug/hr-governor.key
$ quidnug-cli groups advance-epoch \
--group-id bigcorp.com.employees \
--reason member-removed \
--removed <departing-employee-quid> \
--sign-with ~/.quidnug/group-admin.key
Trust edge revocation + epoch advance. Member loses future
access within 1 block.
3.4 Integration with existing IAM
Most enterprises have IAM providers (Okta, AzureAD, Google
Workspace). Pattern:
IAM stays source of truth.
IAM hooks trigger Quidnug sync:
Onboarding hook → generate quid + grant trust edge +
advance epoch
Reference integration in
integrations/iam-sync/README.md (to be built; current
scope).
4. Integration with existing DNS
BigCorp keeps their existing DNS provider (Cloudflare DNS,
AWS Route 53, internal BIND). Quidnug layers on top:
4.1 Public records: DNS + Quidnug in parallel
Public records can be served from both systems:
Traditional DNS (Cloudflare etc.) serves the record the
way it does today.
Quidnug serves the same record via cryptographic
attestation.
Clients that support Quidnug resolver get the cryptographic
version; clients that don’t fall back to traditional DNS. No
migration needed.
4.2 Trust-gated records: Quidnug-exclusive
Partner APIs + employee directories etc. cannot be
represented in traditional DNS (DNS has no access-control
mechanism). These records are Quidnug-exclusive. Clients
must use a Quidnug-aware resolver (SDK or CLI) to query
them.
For partner integrations: BigCorp provides client libraries
to each partner. Partner integrates via library; library
does Quidnug resolution under the hood.
4.3 Private records: Quidnug-exclusive, encrypted
Same as trust-gated but with encryption. Employees use
internal tooling that decrypts transparently.
5. Gateway pattern (optional)
For clients without native Quidnug support, BigCorp can run
a Quidnug-to-DNS gateway:
External clients (legacy DNS resolvers)
│
▼
┌──────────────────────────────────┐
│ Quidnug-to-DNS Gateway Service │
│ (runs in BigCorp's infrastructure) │
└────────────┬─────────────────────┘
│
│ Quidnug queries
▼
┌──────────────────────────────────┐
│ BigCorp's Quidnug validators │
└──────────────────────────────────┘
Gateway:
Accepts legacy DNS queries (UDP/TCP port 53).
For each query, does a Quidnug resolution with
client_quid=<gateway-quid>.
Returns whatever records the gateway’s trust level grants
it (typically only public tier for external resolvers;
trust-gated if configured with appropriate trust edges).
Gateway is convenience; not required for mainstream adoption.
6. Integration with interbank-wire-authorization
BigCorp (hypothetically a bank) is already running the
interbank-wire consortium. Adding DNS authority:
Same validators serve wire authorization + DNS.
Same governance quorum adopts both.
Same guardian quorums protect keys.
Same monitoring + alerting covers both.
Specifically:
bigcorp.com (new: attested by root)
├── wires.outbound (existing: wire authorization)
├── wires.inbound (existing)
├── signatories (existing)
├── audit (existing)
├── peering.counterparty-banks (existing)
├── public (new: public DNS records)
├── partners (new: trust-gated records)
├── employees (new: private group)
└── board (new: private group)
The tree grows; everything else stays.
7. Integration with content authenticity
If BigCorp publishes media (press releases, product
announcements), they can use C2PA + Quidnug:
BigCorp’s quid (DNS-attested) signs a C2PA manifest.
Manifest published via integrations/c2pa/.
Consumer verifies: C2PA signature resolves to a quid
attested to bigcorp.com. Signal authentic.
This is subtle but powerful: phishing press releases can’t
fake the C2PA chain back to the attested domain.
RBAC on authoritative access moves to Quidnug trust edges.
Split-horizon policy migrates to AUTHORITY_DELEGATE
visibility rules.
Scripts replaced by signed events.
9.3 From Consul / etcd / service mesh
Service discovery moves to trust-gated records.
Service secrets move to private encrypted records.
mTLS cert distribution moves to signed TLSA records
(DANE-style).
10. Testing + validation
10.1 Staging environment
Mirror production with a staging network:
$ quidnug-cli domain register \
--name bigcorp-staging.test \
--validators <staging-validators> \
--governors <staging-governors>
Point a staging DNS name (staging.bigcorp.com or a
dedicated staging TLD) at the staging Quidnug network.
Exercise all visibility classes, group rotations, partner
onboarding flows.
10.2 Smoke tests
Automated daily:
#!/bin/bash
# Daily smoke test
set -e
# Public record exists + resolvable
quidnug-cli dns resolve bigcorp.com A --expect 203.0.113.42
# Trust-gated record exists for partner
quidnug-cli dns resolve bigcorp.com API/v2 \
--client-quid <test-partner-quid> \
--expect-non-null
# Private record decryptable by employee
quidnug-cli dns resolve bigcorp.com DIRECTORY/employees \
--client-quid <test-employee-quid> \
--expect-non-null
# Non-member gets NXDOMAIN for private record
quidnug-cli dns resolve bigcorp.com DIRECTORY/employees \
--client-quid <random-quid> \
--expect NXDOMAIN
10.3 Penetration testing
Annual penetration test covering:
Can an attacker read trust-gated records without the edge?
Can a departing employee read records from the new epoch?
Deployment topology, daily operations, runbooks for
employee + partner + record-change flows, incident
response. Written for a national-bank-scale enterprise
running ~3,000 employees + 150 partners + split-horizon
DNS under one AUTHORITY_DELEGATE.
1. Deployment scale
Scale
Example
Employees
Partners
Records
Nodes
Monthly cost
SMB
Regional law firm
50-200
10-30
~500
2 validators + 1 cache
$300-800
Mid-market
Regional bank, mid-sized healthcare
500-2000
30-100
~5,000
3 validators + 3 cache
$2,000-5,000
Enterprise
National bank, global SaaS
2000-10000
100-500
~50,000
5 validators + 10 cache
$10,000-30,000
Global
Fortune 100
10000+
500+
~500,000
10+ validators + 40+ cache
$50,000-200,000
Scale drivers: employee count (group-key rotation frequency),
partner count (trust-gated record query volume), record count
(storage + query volume).
Cache nodes can be spot instances; they’re stateless
(replicate from validators).
3. Runbooks
3.1 Employee onboarding
Trigger: HR adds employee to IAM system.
Time to complete: ~5 minutes automated; ~30 minutes manual.
Steps:
IAM webhook fires to onboarding-sync service.
Sync service:
a. Generates a new Quidnug quid for the employee (or
uses their existing personal quid if they have one +
policy allows).
b. Publishes IDENTITY transaction registering the quid
under bigcorp.com.employees with HR governor as
creator.
c. Publishes MEMBER_KEY_PACKAGE event with the
employee’s X25519 public key (from their device
keyring).
d. Publishes TRUST edge from bigcorp.com.employees to
the new quid at level 1.0, validUntil =
(employment end date if fixed-term).
Group admin service (can be automated):
a. Detects new member via dynamic group membership.
b. Signs EPOCH_ADVANCE event with path update + welcome
package for new employee.
Employee’s device client (SDK):
a. Polls for welcome package.
b. Decrypts welcome with their X25519 private key.
c. Derives current epoch key.
d. Can now decrypt private:bigcorp.com.employees
records.
Welcome package doesn’t arrive: check that
MEMBER_KEY_PACKAGE was published before
EPOCH_ADVANCE. Retry epoch-advance with correct
packaging.
New employee can’t decrypt: verify their X25519 private
key is correctly provisioned on their device. Common
cause: wrong keyring path in SDK configuration.
3.2 Employee offboarding
Trigger: HR removes employee from IAM system.
Time to complete: ~2 minutes automated.
Steps:
IAM webhook fires to offboarding-sync service.
Sync service:
a. Revokes TRUST edge from bigcorp.com.employees to the
departing employee.
b. If immediate cut-off is required (terminations for
cause): signs emergency REMOVE_MEMBER with 1-hour
notice.
Group admin:
a. Detects removed member on next dynamic check.
b. Signs EPOCH_ADVANCE with reasonCode="member-removed".
Departing employee cannot derive the new epoch key;
loses access to all records published from this block
forward.
Epoch advance not honored by cache tier: stale caches
might serve old records to removed employee’s cached
queries briefly. Mitigation: max cache TTL of 60 seconds
for sensitive records.
Key material persistence on employee’s device: employee
could retain cached past-epoch keys and read records they
previously accessed. By design; past access is preserved.
For stricter requirements, rotate to a new group entirely.
3.3 Partner onboarding
Trigger: Business partnership agreement signed.
Time to complete: ~1 day (primarily agreement + trust-
edge establishment workflow).
Steps:
Partner generates (or provides existing) quid.
BigCorp’s legal + partnership team reviews the
partnership terms.
Governance quorum signs TRUST edge:
quidnug-cli trust grant \
--truster bigcorp.com.partners \
--trustee <partner-quid> \
--level 0.8 \ # or 0.5 for loose integration
--domain bigcorp.com.partners \
--valid-until <contract-end-date> \
--sign-with <governance-key>
Partner receives confirmation + documentation on how to
query trust-gated records.
Trigger: Security team detects employee key
compromise OR suspicion.
Time to complete: ~2 minutes.
Steps:
# 1. Immediately revoke the compromised quid's trust edge
quidnug-cli trust revoke \
--truster bigcorp.com.employees \
--trustee <compromised-quid> \
--sign-with <ciso-emergency-key>
# 2. Emergency epoch advance (all groups the compromised
# member was in)
quidnug-cli groups advance-epoch \
--group-id bigcorp.com.employees \
--reason compromise-response \
--removed <compromised-quid> \
--sign-with <ciso-emergency-key>
# 3. Audit: what did the compromised quid read recently?
quidnug-cli audit queries \
--client-quid <compromised-quid> \
--since "7d"
# 4. Forensic analysis + reporting per bigcorp policy.
Within 2 minutes the compromised quid has no access to
future records. Past records they accessed remain a
confidentiality risk (can’t be un-accessed); risk is
assessed in the forensic analysis step.
3.8 Attestation renewal
Trigger: Attestation expiring within 60 days.
Time to complete: ~10 minutes.
Steps:
Automated monitor fires.
CLI publishes renewal request:
quidnug-cli dns renew \
--domain bigcorp.com \
--root quidnug.com \
--owner-key <key>
Root reruns verification (DNS TXT still present, well-
known file still present, TLS fingerprint valid).
Root publishes new DNS_ATTESTATION with updated
validUntil.
If TLS cert has rotated in the meantime: verify CT-log
chain proof is included in the renewal.
4. Daily operations playbook
4.1 Morning (06:00 local)
Validator health check: all 3 validators producing blocks.
Cache health check: all cache replicas responsive.
Overnight metrics review:
Query volume per visibility class
Any anomalous rejection rates (trust-gated failures)
Any failed publishes
Epoch-rotation activity
Attestation status: all paid roots still attesting.
Regional queries fail over to nearest healthy region
(clients automatically try next-best cache per QDP-0014).
Latency increases for affected region (from ~10ms local
to ~50ms cross-region).
Recovery: bring cache nodes back or stand up spare
capacity.
Cost: minor UX impact; no data loss.
5.3 Attestation root goes offline
Detection: Monitoring detects root unresponsive;
attestation can’t be renewed.
Response:
If single root: roll over to backup root (enterprise
should always have ≥2 roots attesting).
If all roots: critical incident. Contact root
operators. Fall back to public DNS during outage.
Long-term: review root-diversification policy.
5.4 Suspected attestation fraud
Detection: A competing attestation appears for
bigcorp.com pointing to a different quid.
Response:
Log the event; file incident ticket.
Verify BigCorp’s owner-quid attestations are still
valid at all known roots.
If competing attestation is via a known root: contact
the root’s governor quorum to revoke.
If via an unknown/sybil root: confirm the sybil root has
near-zero trust weight (it will). Monitor for any
amplification attempts.
Publish a clarifying statement via BigCorp’s website +
attested press release (via content authenticity chain).
5.5 Group-admin key compromise
Detection: Unusual epoch-advance activity, or direct
security-team alert.
Response:
Guardian quorum on the group admin’s key initiates
recovery per QDP-0002.
New group admin key replaces old.
All groups administered by old key: emergency epoch
advance to rotate current epoch key (defense in depth).
Forensic analysis of recent epoch advances for any
unauthorized changes.
5.6 Legal subpoena for employee records
Detection: Legal notice arrives.
Response:
Legal team reviews scope + validity.
If valid: operations generates scoped decryption access.
Either:
a. Temporarily add the requesting party (e.g., regulator
investigator) to the relevant group.
b. Decrypt the specific records and hand over plaintext
(outside the protocol).