DNS, TLS and email trust boundaries

Separate dangling records, transfer/recursion exposure, TLS identity and SMTP relay into controlled protocol tests.

Used in these playbooks#

Setup and invariant#

Treat DNS, TLS and SMTP as separate services with explicit owners, addresses, ports and test methods. Use an owned miniature zone, known certificate hostname and researcher-controlled mail sender and receiver. A service must enforce the claimed ownership, peer identity or relay boundary. Define the expected result before probing: public DNS answers are normally intentional; private zone transfer or unauthenticated external relay may not be.

Procedure#

1. Inspect DNS ownership without claiming resources. Record the exact CNAME or delegation chain, provider error, TTL and owner-supplied resource inventory. A missing backing resource creates a takeover candidate; it does not prove that another account can bind the hostname. Check provider validation and reservation rules. Do not claim dangling resources as a generic proof step. Azure dangling DNS guidance

2. Separate transfer and recursion. AXFR requests the zone contents, so test only an owned small zone or an explicitly supplied fixture. Compare the permitted transfer source with the denied source. For recursion, query one unique name in an owned authoritative zone through the tested resolver; correlate the authoritative log with the resolver response. Cached answers and the RA flag alone do not prove unrestricted recursion. AXFR protocol, BIND configuration

3. Verify TLS identity as the real client. Use the intended hostname, SNI, port and trust store. Compare the valid fixture certificate with an owned wrong-host certificate in a local client integration test. OpenSSL diagnostics confirm the fixture but do not establish that the product's client accepts an invalid identity. Certificate-chain trust and hostname matching both matter. OpenSSL s_client

4. Test SMTP relay with one synthetic message. Only when message delivery is allowed, use sender and receiver domains controlled by the researcher and outside the tested relay's local destination domains. Start from an untrusted source address with no SMTP authentication. The secure control rejects external-to-external relay; the permitted control uses the documented authenticated submission path. A test from an allowlisted office or VPN address does not prove an open relay.

5. Correlate SMTP acceptance with delivery. Retain the envelope, transcript, unique subject marker and receiver logs. A successful RCPT response or queue ID alone does not establish final delivery. Keep relay testing separate from SPF, DKIM and DMARC alignment findings. For sender-identity tests, the receiving policy and trusted authentication results determine the demonstrated impact. SMTP protocol

Command card#

Replace all example addresses only with owned fixtures. Run one command at a time. The AXFR example is limited to the small fixture zone; it retrieves that zone.

timeout 10 dig -r @192.0.2.53 fixture.example AXFR \
  +tcp +time=2 +tries=1

timeout 15 openssl s_client -connect tls.fixture.example:443 \
  -servername tls.fixture.example \
  -verify_hostname tls.fixture.example \
  -verify_return_error -brief </dev/null

timeout 20 swaks --config --server relay.fixture.example --port 25 \
  --timeout 10 --from probe@sender.fixture.example \
  --to receiver@recipient.fixture.example \
  --header 'Subject: Bounty relay fixture 2026-01' \
  --body 'Synthetic authorized relay test; no action required.'

Use a clean shell with no SWAKS_OPT_* overrides; --config disables automatic configuration files, not environment settings. Confirm the transcript contains no AUTH and exactly one intended recipient. The fixture message contains no credentials; this example does not claim transport-security testing. BIND dig, Swaks reference

Result and cleanup checklist#

• Public records distinguished from restricted zone contents.
• Dangling DNS labeled candidate unless claimability is established.
• TLS finding reproduced in the product's actual client.
• Relay test source is outside trusted networks.
• Acceptance, queueing and delivered fixture correlated.
• No real recipients contacted; synthetic mail and temporary zone/certificate fixtures removed.

Vulnerability reverse references#

• Dangling DNS reference to a retired service — An owned hostname still points to a released provider resource, creating a possible takeover path if provider binding rules permit it.
• Restricted DNS zone transferable from an unintended source — An unauthorized source can retrieve an entire zone that the owner intends to restrict.
• DNS recursion available outside the intended client network — A resolver performs recursive lookups for a client excluded by its intended access policy.
• SMTP relay allows unauthenticated external delivery — An untrusted unauthenticated client can relay between external domains contrary to the server's relay policy.
• TLS peer certificate or hostname verification failure — Release trust validation accepts an untrusted certificate chain or wrong-host identity on a sensitive connection.

Nearby shared procedures#

Object, function, and property authorization · Authentication, recovery, federation, and session lifecycle · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity · Proxy normalization, cache isolation, and request boundaries