# Network services, DNS, TLS, email, and appliances This is a separate campaign branch: discovering a network service through a website does not automatically authorize testing it. Commands are documentation-verified examples; none were executed against targets. The budgets, sequence, and evidence thresholds below are operational recommendations. ## Stage 1 — define the service boundary Create one inventory row per `owner → environment → address family → IP → transport → port → service → identity/tenant`. Retain the hostname, SNI and HTTP Host when virtual hosting applies. Distinguish a website's public edge from its origin and from the provider's control plane. An IP resolving from an authorized hostname is not automatically a target for every service; a CIDR does not necessarily include unrelated customer workloads inside it. TCP/443, UDP/443 and a VPN on UDP/500 are separate surfaces. An A record does not authorize IPv6; an AAAA record does not authorize an entire IPv6 prefix. Querying an AAAA record over IPv4 is not an IPv6 connectivity test. Expand only into address families, protocols, ports and ownership categories covered by the policy. Avoid brute-force IPv6 address discovery across huge prefixes. **Gate:** save the exact scope entry, exclusions, approved source address, allowed time window, credentials, concurrency/rate budget, and emergency contact. If appliance disruption or parser tests are excluded, move those hypotheses into a local product lab. ## Stage 2 — separate inventory from vulnerability confirmation Start with public vendor documentation, existing network-index records and historical DNS. Searching previously collected records is passive relative to the target; requesting a new third-party scan is active. DNS queries, TCP connections, UDP packets and TLS negotiations are active even when no login or state change occurs. For authorized services, establish a normal protocol exchange and identify the product, build, deployment mode and authentication challenge. Keep the network vantage point and timestamps: `filtered` or `open|filtered` are observations from that vantage, not proof a service is absent or vulnerable. UDP silence is especially ambiguous. [Nmap port states](https://nmap.org/book/man-port-scanning-basics.html). Treat banner-to-CVE matches as candidates. Vendor backports can fix vulnerabilities without adopting the upstream version number that a scanner expects. Match vendor advisory, package build, enabled feature and exploit prerequisites; validate behavior safely before claiming vulnerability. A stale banner is not remote code execution. [Red Hat backporting](https://access.redhat.com/security/updates/backporting). ## Stage 3 — bounded command reference Replace these documentation addresses only with approved assets. Here `192.0.2.53` is an authorized DNS server and `192.0.2.10` an explicitly approved host. Run commands individually; inspect each result before continuing. No default broad scans, NSE script sets, OS detection, traceroute or version detection are enabled. ```bash # 1. One UDP SOA query to an approved authoritative server. dig -r @192.0.2.53 example.com SOA \ +norecurse +notcp +ignore +time=2 +tries=1 # 2. One AAAA lookup; still uses IPv4 transport to this DNS server. dig -r @192.0.2.53 app.example.com AAAA \ +norecurse +notcp +ignore +time=2 +tries=1 # 3. Inspect the domain's published DMARC record. dig -r @192.0.2.53 _dmarc.example.com TXT \ +norecurse +notcp +ignore +time=2 +tries=1 # 4. TLS handshake with the intended SNI and certificate identity. timeout 15 openssl s_client -connect app.example.com:443 \ -servername app.example.com -verify_hostname app.example.com \ -verify_return_error -brief