filter tests depend on live DNS records we don't control

[thegushi]

Summary

All nine filter tests in opendmarc/tests/ make live DNS queries to external domains as part of their test logic. Five of them hardcode paypal.com as the From domain and rely on it publishing a p=reject DMARC policy. One test (t-verify-nodata.lua) even documents this assumption with the comment:

-- As of 7/1/2012, paypal.com advertises a "p=reject" DMARC policy

That assumption is now 14 years old. If paypal.com changes their DMARC policy (or if DNS is unavailable in CI), the tests break for reasons entirely unrelated to our code.

Affected tests and their DNS dependencies

Test	Domain	What it assumes
t-verify-nodata	paypal.com	p=reject DMARC policy
t-verify-nodata-reject	paypal.com	p=reject DMARC policy
t-verify-multi-from-reject	paypal.com	DMARC record exists
t-verify-multi-from-malformed	paypal.com	DMARC record exists
t-verify-unspec	paypal.com	DMARC record exists
t-verify-received-spf-good	trusteddomain.org	DMARC record exists
t-verify-received-spf-bad	trusteddomain.org	DMARC record exists
t-verify-authservid-jobid	trusteddomain.org	DMARC record exists
t-verify-self-spf	trusteddomain.org	SPF record fails for 66.220.149.251

The trusteddomain.org tests are more stable since we control that domain. The paypal.com tests are the fragile ones.

Fix

libopendmarc exposes opendmarc_dns_fake_record() specifically for injecting DNS responses in tests. The filter tests should use this (or a test-only config option) to supply a known DMARC record for a placeholder domain (e.g. test.example) rather than querying a live external domain.

This would also make the tests runnable in network-isolated environments (containers, some CI setups).

[thegushi]

Better fix than opendmarc_dns_fake_record(): ship a zonefile snippet in the repo (e.g. opendmarc/tests/testzone.txt) that defines exactly the records the tests need, update the tests to use subdomains of trusteddomain.org (which we control), and keep the snippet as both the authoritative reference for what's deployed and a recipe for anyone who wants to run the tests against their own domain.

Required records for the current test suite:

• A domain with p=reject DMARC policy (currently hardcoded as paypal.com — replace with e.g. dmarc-reject.test.trusteddomain.org)
• A domain with no/absent DMARC policy for unspec tests
• SPF records for the self-SPF test (domain that fails SPF for 66.220.149.251)
• DMARC records for the Received-SPF tests

The snippet would live in-tree, the actual records get deployed to the trusteddomain.org zone, and the tests reference those stable subdomains. No external dependency on paypal.com or any domain whose policy we can't guarantee.

This also closes the documentation gap noted in #414 — the zonefile snippet is machine-readable documentation of exactly what DNS setup the test suite requires.