What to prove
- The resolver is running and healthy.
- The dataset is large, current, and exportable.
- Blocked domains resolve predictably through NoorDNS.
- Operators can change category state without code changes.
Walk through NoorDNS with the same composed story that the landing page promises.
This runbook keeps the technical proof, the blocked-page experience, and the operator workflow in one deliberate sequence for client calls and recorded demos.
First proveResolver health and dataset scale
Then showBlocked journey and operator control
Finish withOne category toggle and re-export
Call handling
- Show terminal proof first, browser proof second.
- Use the blocked page to explain guidance, not just failure.
- Keep fallback commands ready if browser behavior varies on HTTPS.
- End by toggling one category and regenerating export data.
1
Step 1
Confirm stack health
Start with service status so the rest of the demo reads as a controlled environment.
docker compose ps curl -s http://localhost:8000/health
2
Step 2
Show blocklist dataset volume
Make the scale concrete before you move into the live browser or DNS moments.
docker compose exec db psql -U noor -d noor -c "SELECT category_slug, COUNT(*) FROM domains GROUP BY category_slug ORDER BY category_slug;"
3
Step 3
Show DNS export generation
This proves enabled policies are actually being transformed into resolver data.
./scripts/sync_dns_hosts.sh head -n 10 dns/blocklist/hosts
4
Step 4
Prove live domain blocking
Use a local resolver check to demonstrate deterministic blocking without browser ambiguity.
dig @127.0.0.1 pornhub.com +short dig @127.0.0.1 bet365.com +short
5
Step 5
Toggle a category and re-export
Use this at the end of the call to show the operator workflow is not hardcoded.
curl -s -X POST "http://localhost:8000/categories/gambling/toggle?enabled=false" ./scripts/sync_dns_hosts.sh curl -s -X POST "http://localhost:8000/categories/gambling/toggle?enabled=true" ./scripts/sync_dns_hosts.sh