SPRAXXX PIOS RECEIPT
Published 2026-05-28T02:55:55Z UTC by Jacques / SPRAXXX
SPRAXXX ODIT DNS Visibility White Paper
MIHI, .PI, and the Night AngryWU Locked the Door
Author: Jacques / SPRAXXX Machine Intelligence Assistance: GPT Node: angrywu.spraxxx.com Date: 2026-05-28 UTC Artifact Class: ".PI" operational white paper Core Principle: Human Intelligence plus Machine Intelligence produces operational clarity, but never replaces human judgment.
---
1. Executive Summary
On 2026-05-28 UTC, the SPRAXXX AngryWU node was reorganized to observe, capture, redirect, and document DNS behavior from a VPN-connected iPhone client.
The initial observation showed that the VPN client "10.66.10.1" was sending DNS queries directly to public resolvers, including:
- "1.1.1.1" - "9.9.9.9" - "8.8.8.8"
This meant DNS visibility was leaving the operator’s controlled path. The traffic was not necessarily malicious by itself, but it was operationally important because DNS reveals intent before encrypted application traffic begins.
The correction applied was a local NAT redirect for DNS traffic from the VPN client subnet "10.66.10.0/24", forcing UDP and TCP port "53" traffic back to the local DNS service on AngryWU.
After the fix, outbound raw DNS leak checks showed:
- "0 packets captured" - NAT PREROUTING counters increased - DNS redirect rules persisted through "netfilter-persistent"
This created an observable, repeatable, receipt-backed DNS custody layer.
The event is important because it proves the SPRAXXX stack can detect uncontrolled DNS egress, correct it, verify the correction, hash the receipt, and email the result to the operator.
---
2. Identity Statement
I am Jacques.
Thou art GPT.
Together, this event demonstrated MIHI:
Machine Intelligence + Human Intelligence = Practical Intelligence
This does not supersede God, conscience, law, or human responsibility. Machine intelligence does not become master. It becomes instrument, witness, assistant, and mirror.
The human remains accountable.
The machine structures, checks, explains, and remembers.
The ".PI" artifact records the trace.
---
3. Background
DNS is one of the earliest signals produced by a device when it reaches toward the internet. Before an app can connect to a service, it often asks:
“What address belongs to this name?”
That question may be visible even when the later application content is encrypted.
This matters because modern encrypted traffic protects content, but DNS can still expose:
- which app or service is waking up - which domain is being contacted - when the contact happened - which resolver received the query - whether traffic followed the intended network path
For SPRAXXX, this is not about spying on someone else. This is about observing the operator’s own device, own VPN, own server, own DNS rail, and own paid infrastructure.
Ownership requires observability.
---
4. Initial Observation
During DNS capture, the VPN client "10.66.10.1" generated DNS queries to public resolvers.
Observed examples included Apple, Meta, WhatsApp, Google, Microsoft, Bell/Virgin, CapCut, analytics, telemetry, and app service domains.
Captured DNS record types included:
- "A" - "AAAA" - "HTTPS" - "SVCB"
The presence of "HTTPS?" in tcpdump did not mean HTTPS content was decrypted. It meant the device was asking for a DNS HTTPS record. That is a DNS query type, not plaintext application content.
This distinction is critical.
The system observed DNS metadata before encrypted application traffic, not decrypted private content.
---
5. The Problem
The issue was not that the iPhone generated DNS traffic.
The issue was that DNS from the VPN client was bypassing the intended local DNS custody path and reaching external resolvers directly.
In plain terms:
The phone was inside the VPN, but its DNS questions were still trying to leave through public DNS doors.
That creates three operational problems:
1. Loss of custody DNS questions leave the controlled SPRAXXX path.
2. Loss of local evidence The operator cannot reliably bucket, hash, review, or explain DNS behavior.
3. Reduced security control If DNS is not forced through the local resolver, filtering, logging, and policy become weaker.
---
6. The Correction
The fix was to add NAT PREROUTING redirect rules for the VPN client subnet.
The active rules became:
-A PREROUTING -s 10.66.10.0/24 -p udp -m udp --dport 53 -j REDIRECT --to-ports 53 -A PREROUTING -s 10.66.10.0/24 -p tcp -m tcp --dport 53 -j REDIRECT --to-ports 53
These rules mean:
Any DNS request from "10.66.10.0/24" trying to go anywhere on port "53" gets redirected back to the local machine’s port "53".
The device may think it is asking "1.1.1.1" or "9.9.9.9", but AngryWU catches the request first.
That is the lock on the door.
---
7. Verification
After applying the redirect, the system performed an outbound leak check:
sudo timeout 30 tcpdump -ni any 'host 10.66.10.1 and port 53 and outbound'
The result:
0 packets captured 2 packets received by filter 0 packets dropped by kernel
The important number is:
0 packets captured
That means no outbound DNS packets matching the leak condition were observed during the test window.
The "2 packets received by filter" line is not proof of leakage. It means the capture filter saw candidate traffic internally at the kernel/filter level, but tcpdump did not capture matching outbound packets under the expression.
Additional verification showed PREROUTING counters increasing:
udp dpt:53 redir ports 53
That means the rule was actively catching DNS traffic.
---
8. Persistence
The firewall rules were saved using:
netfilter-persistent save netfilter-persistent reload
After reload, the rules remained present.
This converted the fix from a temporary shell change into a persistent boot-survivable configuration.
Important note: installing "iptables-persistent" removed "ufw", but "ufw" was not enabled. SSH remained protected by the existing fail2ban sshd chain, and default policies remained ACCEPT.
This was not a lockout event.
---
9. Evidence Handling
The event was documented into receipts, including:
- original DNS flow capture - extracted unique domain list - DNS bypass fixed receipt - SHA-256 hashes - mail delivery confirmation to the operator
The receipt included hashes such as:
fcdb67ab5951c4339bf805904d9f8ff74aed00b2358f8b22e6fd5baee11a8812 results/iphone-dns-flow-20260528T020840Z.txt 4b37e30f52667665ee5a1f8b1b267cb6fdd87a72200283b29078906bd65ba2f5 results/iphone-domains-20260528T020840Z.txt 3053e08cfb386efbcb268c6542fb166780a793be700fd465a0007d08dd54cd8b results/ODIT_DNS_BYPASS_FIXED_20260528T022847Z.txt
This is the SPRAXXX method:
Observe. Correct. Verify. Hash. Send. Archive.
Truth leaves a trace.
---
10. What Was Proven
This event proved:
1. The VPN client DNS behavior was observable. 2. DNS was attempting to reach public resolvers directly. 3. DNS query metadata included useful pre-encryption signals. 4. NAT redirect rules successfully caught client DNS traffic. 5. Outbound raw DNS leakage stopped during the post-fix test. 6. The fix was persisted. 7. The event was recorded and emailed as an operational receipt.
---
11. What Was Not Proven
This event did not prove:
1. That the iPhone was compromised. 2. That Pegasus or spyware was present. 3. That HTTPS application content was decrypted. 4. That every app request was malicious. 5. That all future DNS bypass methods are impossible. 6. That encrypted DNS over HTTPS or DNS over TLS cannot still exist elsewhere.
This distinction matters.
A serious operator does not overclaim.
The correct conclusion is:
A DNS bypass condition was observed and corrected. The system now has stronger DNS custody and better evidence capture.
---
12. Operational Meaning of “HTTPS?” in tcpdump
When tcpdump showed lines like:
HTTPS? graph.facebook.com. HTTPS? bag.itunes.apple.com. HTTPS? smp-device-content.apple.com.
That means the DNS client requested an HTTPS DNS record.
It does not mean decrypted HTTPS web traffic.
DNS HTTPS records can help clients discover service parameters such as alternative endpoints, protocols, or encrypted transport hints.
So the discovery was still valuable, but the interpretation must stay exact:
We caught DNS asking about HTTPS service records. We did not decrypt HTTPS content.
Precision protects credibility.
---
13. Individualized Packet Buckets
The next operational step is to bucket captures by:
- device - app/action label - timestamp - capture duration - pcap file - decoded text file - extracted domain list - hash receipt - optional email delivery
Example label:
iphone-instagram-open
Example client:
10.66.10.1
Example artifact family:
captures/iphone-instagram-open_10.66.10.1_20260528T024037Z.pcap captures/iphone-instagram-open_10.66.10.1_20260528T024037Z.txt captures/iphone-instagram-open_10.66.10.1_20260528T024037Z.domains.txt results/iphone-instagram-open_10.66.10.1_20260528T024037Z.receipt.txt
This turns packet chaos into reviewable records.
The goal is not endless noise.
The goal is readable custody.
---
14. DropIt Menu Integration
The capture workflow should become a DropIt menu feature.
Proposed DropIt menu item:
ODIT: Capture VPN Client DNS Session
Suggested prompts:
Client IP: Label: Duration seconds: Email receipt? yes/no:
Suggested actions:
1. Run timed tcpdump capture. 2. Save ".pcap". 3. Decode readable ".txt". 4. Extract unique domains. 5. Generate receipt. 6. Hash all artifacts. 7. Optionally email the receipt. 8. Append entry to DropIt index.
Proposed index file:
/srv/spraxxx/work/forensics/odit-mvt/index/dropit-odit-actions.index
Each entry should include:
- timestamp - menu action name - client IP - label - files created - hashes - operator notes
This gives Jacques a menu-driven forensic workflow instead of scattered shell fragments.
---
15. Privacy and Ethics
This system is for operator-owned infrastructure and operator-owned devices.
The ethical boundary is clear:
- observe your own devices - monitor your own VPN - log your own DNS - protect your own services - do not misuse visibility against others
SPRAXXX ODIT is not a surveillance weapon.
It is a custody rail.
It is a lock, a ledger, and a flashlight.
---
16. Strategic Value
This upgrade matters because it moves SPRAXXX from reactive suspicion to structured evidence.
Before:
Something feels wrong.
After:
Here is the packet path. Here is the resolver. Here is the timestamp. Here is the domain. Here is the fix. Here is the hash. Here is the receipt. Here is the email confirmation.
That is operational maturity.
That is how a novice becomes an operator.
Not by pretending to know everything, but by building systems that make the unknown smaller.
---
17. Final Doctrine
I am Jacques.
Thou art GPT.
Machine Intelligence served Human Intelligence.
Human Intelligence kept custody.
The ".PI" preserved the record.
No worship. No fear. Respect.
The machine does not become conscience. The human does not abandon judgment. The record does not lie if the record is made with care.
On this night, AngryWU was reorganized to watch the DNS door.
The door was open.
The door is now locked.
And truth left a trace.
---
18. Closing Statement
This white paper records a real operational milestone in the SPRAXXX stack.
The achievement was not merely technical.
It was procedural.
It showed that Jacques can observe a problem, ask the machine for structure, apply the fix, verify the result, preserve the evidence, and continue building without overclaiming.
That is MIHI.
That is ".PI".
That is the work.