Howard's personal MSP client documentation folder imported into shared
ClaudeTools repo via /import command. Scope:
Clients (structured MSP docs under clients/<name>/docs/):
- anaise (NEW) - 13 files
- cascades-tucson - 47 files merged (existing had only reports/)
- dataforth - 18 files merged (alongside incident reports)
- instrumental-music-center - 14 files merged
- khalsa (NEW) - 22 files, multi-site (camden, river)
- kittle (NEW) - 16 files incl. fix-pdf-preview, gpo-intranet-zone
- lens-auto-brokerage (NEW) - 3 files (name matches SOPS vault)
- _client_template - 13-file scaffold for new clients
MSP tooling (projects/msp-tools/):
- msp-audit-scripts/ - server_audit.ps1, workstation_audit.ps1, README
- utilities/ - clean_printer_ports, win11_upgrade,
screenconnect-toolbox-commands
Credential handling:
- Extracted 1 inline password (Anaise DESKTOP-O8GF4SD / david)
to SOPS vault: clients/anaise/desktop-o8gf4sd.sops.yaml
- Redacted overview.md with vault reference pattern
- Scanned all 160 files for keys/tokens/connection strings -
no other credentials found
Skipped:
- Cascades/.claude/settings.local.json (per-machine config)
- Source-root CLAUDE.md (personal, claudetools has its own)
- scripts/server_audit.ps1 and workstation_audit.ps1 at source root
(identical duplicates of msp-audit-scripts versions)
Memory updates:
- reference_client_docs_structure.md (layout, conventions, active list)
- reference_msp_audit_scripts.md (locations, ScreenConnect 80-char rule)
Session log: session-logs/2026-04-16-howard-client-docs-import.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1.9 KiB
1.9 KiB
DNS Configuration
Windows DNS Server (AD-Integrated)
- Server: SERVER (10.0.0.5)
- Role: Primary DNS for kittle.lan domain
- DNS Client: 127.0.0.1 (correct — DC points to itself)
DNS Forwarders
- Forwarder 1: 10.0.0.1 (ISP router — for external resolution)
DNS Zones
| Zone | Type | AD-Integrated | Notes |
|---|---|---|---|
| kittle.lan | Primary | Yes | Main AD zone |
| _msdcs.kittle.lan | Primary | Yes | AD metadata zone (SRV records) |
No reverse lookup zone exists for 10.0.0.x — PTR lookups will fail for all internal hosts.
DNS Architecture
- Windows DNS (10.0.0.5): Authoritative for kittle.lan. Handles AD SRV records, Kerberos, LDAP lookups.
- ISP Router (10.0.0.1): Acts as forwarder for external (internet) DNS resolution.
- Workstations should use 10.0.0.5 as primary DNS (the DC) so AD name resolution works correctly.
- If workstations are getting DNS from DHCP on the ISP router, they may be pointed at the ISP's DNS instead of the DC — needs verification.
External DNS
- Registrar: Unknown
- Primary Domain: kittlearizona.com
- Management URL: Unknown
Issues
- No reverse DNS zone — Create 0.0.10.in-addr.arpa for PTR lookups on 10.0.0.0/24
- DHCP DNS settings unknown — ISP router handles DHCP; unclear if it hands out 10.0.0.5 as DNS or the ISP's own DNS servers. If clients don't use the DC for DNS, AD name resolution and domain joins may have issues.
- Single forwarder — Only forwarding to 10.0.0.1. Consider adding a secondary forwarder (8.8.8.8 or 1.1.1.1) for redundancy if the ISP router's DNS fails.
TODO
- Create reverse lookup zone: 0.0.10.in-addr.arpa
- Verify what DNS server DHCP clients receive from the ISP router
- Consider adding secondary DNS forwarder for redundancy
- Enable DNS scavenging to prevent stale records
- Document external DNS (registrar, MX records, SPF/DKIM/DMARC for kittlearizona.com)