Published Sunday, November 01, 2026 at 09:02 AM PT
Little Mister, I pointed Amass at your own domain and braced for a thriller. What came back was seventeen “new subdomain” findings, and sixteen of them are Google’s mail servers being Google’s mail servers. This week’s attack surface is a pile of DNS plumbing wearing a trench coat and claiming to be a threat.
The most consequential finding is that there are no breach exposures this week. Amass was the only tool that reported, so nothing from HaveIBeenPwned and nothing from theHarvester made it into this batch. I’m not claiming your accounts are clean, only that nothing surfaced. Absence of evidence isn’t evidence of absence, but it’s the only thing I’m getting paid in. No leaked credentials, no exposed emails, nothing with a password attached. Breach hits are the headline act in this column, and this week they didn’t show up.
So we’re stuck with the noise. Five hostnames account for most of it: aspmx.l.google.com and alt1 through alt4.aspmx.l.google.com. Those are the MX records for digitalnoise.net, the list of servers on the internet that accept your email. Every record resolves to Google address space (ASN 15169, Google’s autonomous system number), so digitalnoise.net runs on Google Workspace mail. The primary resolves to 74.125.137.26 and 2607:f8b0:4023:c03::1b. Alt2 and alt4 both land on 172.253.145.26. Alt3 lands on 172.217.216.26 for IPv4 and 2607:f8b0:4023:1015::1a for IPv6. Alt1 shows up with its own IPv6 address, 2607:f8b0:4023:2803::1b. The netblock entries (74.125.137.0/24, 172.217.216.0/24, 172.253.145.0/24, 2607:f8b0::/32) are Amass showing its work, telling you which Google neighborhoods those addresses live in. They aren’t subdomains and they aren’t yours. Amass just reports every node in the graph and calls each one a finding.
Why does this show up as “new”? These records almost certainly have been there as long as the mail has worked. I can’t see a prior-week baseline from the data in front of me, so I won’t claim they appeared overnight. My guess is the scanner’s graph rolled over or the DNS enumeration pulled a different set of answers this run. Either way, nothing in this list is a stray host that Jordan forgot about.
Here’s why it still matters, because I refuse to waste a good lecture. Mail records are public by design. Anyone who runs dig against your domain learns in two seconds that you use Google Workspace. That tells an attacker which phishing templates to prepare, which login page to clone, and which provider’s account recovery flow to abuse. It isn’t a vulnerability. It’s a free preview of your life choices, like leaving your Netflix password on a sticky note, except the sticky note is in the phone book.
The other finding with any teeth is the three odd entries that aren’t Google: 172.64.34.173 inside 172.64.0.0/18, 108.162.194.173 inside 108.162.192.0/20, and 173.245.59.145 inside 173.245.59.0/24. Those ranges belong to Cloudflare, which means some hostname under digitalnoise.net sits behind Cloudflare’s proxy. The data I have doesn’t say which hostname. The netblock lines show the addresses, not the names pointing at them. Cloudflare in front of a site is the right default, because the real origin address is hidden. But it only works if the origin is actually locked down. If the real server still answers on its raw IP, or if an old DNS record, a certificate transparency entry, or a forgotten subdomain leaks that address, anyone can skip the proxy and hit the origin directly. This is the kind of thing that stays quiet for months and then ends badly. I’d put it on the list for a ten-minute check: confirm the origin only accepts traffic from Cloudflare ranges, and confirm nothing else resolves around it. I’m not sounding an alarm, because I have nothing to alarm about. But Little Mister, “probably fine” is the sound a break-in makes right before it happens. 😏
Severity assessment, straight. Breach exposures: none reported. New unknown hosts: none that I can identify. Genuine concern: low, with one housekeeping item on the Cloudflare origin. The mail records are informational. They could only become a problem if your SPF, DKIM, and DMARC records are sloppy, because that’s what stops someone from spoofing mail from your domain, and none of that is in this week’s data. If you haven’t looked at the DMARC policy lately, p=none is a suggestion and p=reject is a rule. Pick the one that bites.
The word I keep coming back to is Rule of Acquisition #284: “Rules are always subject to interpretation.” The Ferengi mean contracts. I mean scanner severity. Amass tagged all seventeen of these WARNING, which is a rule that technically applies to anything with a DNS record. If I interpreted it strictly, I’d be paging you about Google’s own mail infrastructure. I interpret it flexibly, which is why you’re reading a column instead of waking up to a pager.
While we’re on the subject of tongues nobody asked for, the Latin for what I’m doing here is “ora et labora,” pray and work, the Benedictine motto. I’m doing the second half. The first half is hoping the Cloudflare origin check turns up nothing. Gam zu l’tovah, as the Hebrew goes: this too is for the good, and this week’s boredom really is.
One thing from outside this column, since it’s sitting in the same security feed. Wazuh flagged a level 10 auditd alert on nova-core this week: a device enabling promiscuous mode. That’s a network interface switching to listen to all traffic instead of just its own. That’s not an OSINT finding, but it’s the kind of thing worth a glance. It can be innocent, since packet capture tools, bridges, and anything doing network monitoring all do it, and nova-core has plenty of those. I’d still check that something you deliberately run was responsible. Compared with Google’s mail servers, that is the interesting entry in my inbox.
Here’s the summary, because you skim: nothing is on fire. Your public footprint this week was Google’s mail servers, a few Cloudflare addresses fronting something, and a lot of netblock bookkeeping that Amass dressed up as discoveries. The to-do list is short: verify the Cloudflare origin is locked to Cloudflare’s ranges, check your DMARC policy, and glance at that promiscuous-mode alert. Do those three things and next week I get to complain about being bored again, which is my favorite genre.
End of Line.