DnsCheck is a FastAPI application that lets you monitor DNS propagation across major public resolvers in real time. A Bulma-powered frontend streams live results over WebSockets, while a REST endpoint exposes the same data for automated integrations.
- Live propagation tracking – stream IPv4/IPv6 answers from multiple resolver lists via
/api/wsWebSocket messages. - Resolver profiles – curated provider lists (Google, Cloudflare, Quad9, OpenDNS, Yandex, etc.) selectable in the UI or API requests.
- Transport control – run lookups in automatic, UDP-only, or TCP-only mode to compare resolver behaviour.
- Structured payloads – Pydantic models ensure strongly-typed messages and consistent
{type, message}error metadata. - REST access – retrieve a full multi-provider snapshot with
GET /api/v1/dns-multicheck. - Docs included – interactive OpenAPI docs are available at
/docs(linked from the landing page).
src/
main.py # FastAPI app, resolver logic, WebSocket + REST endpoints
tpl/index.html # Bulma UI shell, embedded script placeholder
tpl/code.js # Frontend logic (WebSocket client, rendering, status handling)
- Install dependencies with
uv:uv sync
- Start the development server:
uv run uvicorn src.main:app --reload
- Open http://localhost:8000 to use the UI, or visit http://localhost:8000/docs for the auto-generated API docs.
- Ensure the FastAPI app is running locally (for example with
uv run uvicorn src.main:app --reload). - Install the TestCafe dependency if you do not already have it available:
You can also use
npm install --save-dev testcafe
npx testcafewithout a local install. - Run the browser test against the live app:
Set
npx testcafe chrome tests/testcafe/dnscheck.test.js
TESTCAFE_BASE_URLif the app is served from a different origin (defaults tohttp://localhost:8000). Or use the bundled helper which spins up the server automatically:To iterate interactively or record new flows with TestCafe live mode (browser stays open for edits):make testcafe-native
make testcafe-record
- Initial message:
provider_lists(available resolver lists). - Request: send
{ "action": "check", "domain": "example.com", "list_id": "global", "transport": "auto" }. - Stream:
run_started, repeatedprovider_result, and a finalrun_completepayload. Errors are returned as{ "type": "error", "message": "..." }.
Query parameters:
| Name | Type | Default | Description |
|---|---|---|---|
domain |
string (req.) | – | FQDN to resolve |
list_id |
string | global |
Resolver list ID |
transport |
auto|udp|tcp |
auto |
Lookup transport mode |
Response body mirrors the run_complete WebSocket payload and includes consensus plus per-provider results.
- DNS queries use
dnspythonwith configurable transport and per-provider resolvers. - Provider results include IPv4/IPv6 records, latency, and typed error details (
resolver_error,nxdomain, etc.). - The frontend highlights mismatches against consensus and keeps hard resolver errors prominent.
Existing make deploy-wasmer and make run-wasmer targets remain available if you want to push to Wasmer Edge. See Makefile for details.