DNS verification swallows resolver errors silently — no logging, no error class differentiation

[dobby-coder]

Problem

`src/lib/server/services/dns-verification.ts:65-71` catches every error from `resolve(record.domain, 'TXT')` and returns the same generic message. Nothing is logged, so debugging a failed DNS verification is impossible from server logs.

```ts
} catch {
await db
.update(dnsVerifications)
.set({ lastCheckedAt: new Date() })
.where(eq(dnsVerifications.id, record.id));
return { verified: false, error: `Could not resolve DNS for ${record.domain}` };
}
```

Affected debugging cases:

• `ENOTFOUND` (domain doesn't exist) vs `ENODATA` (no TXT records) vs network failure are indistinguishable.
• Users see the same opaque "Could not resolve DNS" error for every cause.
• Operators have no log line to grep when a customer reports "my DNS check keeps failing".

Suggested fix

```ts
} catch (err) {
console.error('[dns-verification] resolve failed', {
orgId,
domain: record.domain,
code: (err as NodeJS.ErrnoException)?.code,
message: err instanceof Error ? err.message : String(err)
});
await db
.update(dnsVerifications)
.set({ lastCheckedAt: new Date() })
.where(eq(dnsVerifications.id, record.id));
const code = (err as NodeJS.ErrnoException)?.code;
const userMsg =
code === 'ENOTFOUND' ? `Domain ${record.domain} not found` :
code === 'ENODATA' ? `No TXT records found for ${record.domain}` :
`Could not resolve DNS for ${record.domain}`;
return { verified: false, error: userMsg };
}
```

Test plan

• Existing happy-path test still passes.
• New test: mocked `resolve()` throwing `ENOTFOUND` → returned error string contains "not found".
• New test: mocked `resolve()` throwing generic Error → fallback message returned, `console.error` was called.

[dobby-coder]

/dobby

[dobby-coder]

On it! This agent sees the request — Dobby will trace the dns-verification error handler at src/lib/server/services/dns-verification.ts:65-71, add structured logging and code-aware error messages, and wire up unit tests for the new branches. Dobby is happy to help!

[dobby-coder]

Plan

Files to modify

• src/lib/server/services/dns-verification.ts — rewrite the catch block (lines 65–71) to capture the error, log it via console.error with a [dns-verification] prefix (matching the [csp-report] style already in the codebase), and branch the user-facing message on NodeJS.ErrnoException.code.

Files to add

• tests/unit/dns-verification.test.ts — vitest unit tests using vi.mock('dns/promises', ...) and vi.mock('$lib/server/db', ...) to drive each branch without a live DB or DNS.

Approach

Replace the bare catch {} with:

} catch (err) {
    const code = (err as NodeJS.ErrnoException)?.code;
    console.error('[dns-verification] resolve failed', {
        orgId,
        domain: record.domain,
        code,
        message: err instanceof Error ? err.message : String(err)
    });
    await db.update(dnsVerifications).set({ lastCheckedAt: new Date() }).where(eq(dnsVerifications.id, record.id));
    const userMsg =
        code === 'ENOTFOUND' ? `Domain ${record.domain} not found` :
        code === 'ENODATA'   ? `No TXT records found for ${record.domain}` :
                               `Could not resolve DNS for ${record.domain}`;
    return { verified: false, error: userMsg };
}

orgId is already in scope (it's the verifyDns parameter), so we can log it without re-fetching anything.

Test coverage

1. Happy path — TXT record matches → returns { verified: true }, no console.error.
2. TXT record missing from response → returns existing "TXT record ... not found" message (unchanged behaviour).
3. resolve() throws { code: 'ENOTFOUND' } → error string contains "not found", console.error called once with the code.
4. resolve() throws { code: 'ENODATA' } → error string contains "No TXT records found".
5. resolve() throws a generic Error (no code) → fallback "Could not resolve DNS for ..." message, console.error still called.
6. lastCheckedAt is updated on every catch path (regression guard for the existing DB write).

Verification

• npm run test:unit -- --run (new file + existing suite)
• npm run check with NODE_OPTIONS=--max-old-space-size=3072 (per repo notes)
• vite build smoke check

Risks

• console.error will surface in CI logs — intentional per the issue ("operators have no log line to grep"). No PII beyond orgId (a UUID) and the publicly-disclosable verification domain.
• No behaviour change for callers: the function's return shape stays { verified, error? }; only the error string varies by code.

[dobby-coder]

Opened #90 — implements the suggested fix verbatim (structured console.error + ENOTFOUND/ENODATA branching) with 6 new unit tests. Full unit suite (58/58) green, npm run check and npm run lint clean.