docs: document the no-DNS-mocking policy in README (closes #94)
All checks were successful
check / check (push) Successful in 4s
All checks were successful
check / check (push) Successful in 4s
DNS is never mocked in dnswatcher — not in tests, not anywhere. Tests run against the real DNS by design; flaky live tests get fixed with robustness or owner-decided opt-in gating, never mocks. Record this prominently near the top of the README so contributors and future workers do not propose mocked resolvers.
This commit is contained in:
20
README.md
20
README.md
@@ -17,6 +17,26 @@ without requiring an external database.
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## No DNS mocking. Ever.
|
||||||
|
|
||||||
|
**DNS is never mocked in this project — not in tests, not anywhere else.**
|
||||||
|
No mock resolvers, no fake DNS servers, no stubbed lookups.
|
||||||
|
|
||||||
|
dnswatcher's entire purpose is correct behavior against the real DNS.
|
||||||
|
Tests exercise real iterative resolution against live nameservers by
|
||||||
|
design; a test suite that passes against a mock proves nothing about the
|
||||||
|
one thing this program exists to do.
|
||||||
|
|
||||||
|
When live tests are flaky, that is a robustness problem, and it gets
|
||||||
|
fixed with robustness: retries with backoff, querying multiple
|
||||||
|
independent nameservers, longer timeouts — or explicit opt-in gating
|
||||||
|
decided by the project owner. Never with mocks.
|
||||||
|
|
||||||
|
Contributions that introduce mocked, faked, or stubbed DNS will be
|
||||||
|
rejected.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
## Features
|
## Features
|
||||||
|
|
||||||
### DNS Domain Monitoring (Apex Domains)
|
### DNS Domain Monitoring (Apex Domains)
|
||||||
|
|||||||
Reference in New Issue
Block a user