On Sat, Oct 31, 2026, 13:55 Jay A via NANOG .
(SNIP) For example; A domain that is currently reporting that it is for sale is probably a higher-risk domain to accept traffic related to.
Generally true. But your proposed mechanisms have some issues. See below.
Also, If the domain changes underlying legal owners or registrants, then Ideally it should be treated the same as a new domain registration: Ensure that any built-up positive reputation is removed/reset, and the Old domain holder might have gotten TLS certificates issued which ought to require a forced revalidation after a change in the domain's ownership.
This just leads to "domain straw purchases" and "reputation laundering". 1. Alice buys example.com and runs a phishing campaign from it, burning it. 2. Alice sells example.com to a direct associate, Bob. 3. example.com rep is cleared. 4. Bob runs a phishing campaign from example.com. 5. Bob sells to Cathy. 6. (And so on and so on, etc.) 7. ??? sells example.com to Alice. Repeat from step 1. It would actually be useful if the domain registries were required to
publish
much more info on domains and domain holders than "whether it is for sale".
Well, they used to, and then started charging money to hide that info, and then other people made it required to hide that info (or offer to hide it) for free because by and large it was considered a security liability at that point because bored and angry teenagers figured out how to make WHOIS queries. For example, the Tenure start and End timestamps of the underlying owners and contacts
(Not whatever "privacy" proxy can be listed in WHOIS)
See above, but this also doesn't help much if you have a vast network of straw purchasers and "mules" at your disposal. As criminal organizations large enough to be a problem generally do.
The actual country-code regions' of every domains' underlying registrant, payment method, and contacts.
See above on both points; this hurts good-faith operators more than it does domain/registrar abusers. The actual number of updates of each type for a domain's current
registration year.
These people have many, many domains. They can sit on any given domain for quite some time. Alice can sell to Bob and Bob can sit on that for years because they're currently running a campaign from a domain that they last sold 2 years ago. Renew term (number years), and the Counts of domains that have
underlying contacts or accounts in common. [For example, the account that holds this domain has 100 other domains in it and the same billing entity holds 20 other domains]
How do you distinguish this from MSPs and/or shared webhosts handling registration for their customers, and how do you differentiate that valid company from a spam/phish farm at the org level? In machine-readable format. I don't know, perhaps they could use a
DNS hierarchy like a example._domaininfo.com. TXT "[protobuf structure]" to denote basic registration metadata for example.com. In a way that can be queried without needing additional network protocols such as WHOIS.
You're capped at a bit less than 65535 B (64 KiB) for TCP DNS responses in total for a single RR, which means a TXT content of about 65227 B. Less if there's RRSIGs.
Don't get me wrong, 64 KiB is a sizable amount of data. For reference, the plaintext version of RFC 3740 <https://www.rfc-editor.org/rfc/rfc3740.txt> [0] is 65531 B - just 4 B short - and it's a decently-sized one. But given you want to include historical data, plus structuring overhead, etc. - that's a limitation to keep in mind to avoid truncation attacks, etc.. You can, of course, serve multiple TXT records (read: multiple RR) under the same name, and *generally* they'd be *concatenated* together, but you have *no control whatsoever* over the order the querier receives or assembles/concatenates them (RFC 1034 ยง3.6). This is something that ANY kind of structured data - JSON, Protobuf, whatever - absolutely hates and will choke and die on - they all require strict ordering for segmenting/reassembly, otherwise there's no guarantee you get a valid document/data piece. (DNS-SD solves this interestingly in that it specifies *key=value* TXT records, but DNS-SD is... not served by public resolvers, as it's intended for local network service discovery. Hell, most network boundaries are likely to filter it since it shouldn't even be trying to route in the first place. All the modern implementations I've seen in the wild use mDNS for it.) And if the resolver or querier doesn't support TCP fallback, or have more restrictive length limits in place? The querier won't even get the content at all because you aren't fitting that response in a single UDP RDATA/RR - about 1.2 to 1.4 KiB depending on e.g. domain name length, etc. (Resolvers/clients are *supposed* to support TCP DNS per RFC 7766 and BCP 235/RFC 9210, but.... well. There's "should" and "do", and they don't always agree.) Of course, *ALL* of this is *moot, null, and void*: *Registrars* don't serve records, *nameservers* do. Do registrars typically *offer* (usually *gratis*, sometimes not) record hosting for domains you register through them via their *own* nameservers? Absolutely! But you aren't obligated to use them. If you're using your own (or third-party, e.g. Cloudflare DNS or whatever-it's-called, or Amazon's thing, or whatever) nameservers, the registrar isn't even hit. Say you look up '*A foo.example.com <http://foo.example.com>*' (which technically is '*A foo.example.com <http://foo.example.com>.*' because the DNS root, '.', is its own zone.). 'example.com', in this example, is registered through registrar BazCo Biz, Ltd. ("B"). 1. The client (you; "Q") asks its resolver ("R") for that QType + QName. 2. If that resolver doesn't have the response cached (or it's expired), it queries the root nameservers ('.'; owned/maintained by an ICANN committee) ("I") for the NS for 'com.' (Try it yourself: `*dig +short NS com.`*). 3. The resolver (R) then queries one of (or sometimes all, depending on how its operator has configured it/what software it's running/etc.) those nameservers ("N") for the NS for 'example.com.' - these are commonly called the "authoritative nameservers" ("A") for a domain. 4. FINALLY, the resolver (R) queries one (or all of) the domain's nameservers (A) for '*A foo.example.com <http://foo.example.com>.*' (and caches the response so it doesn't have to go through that whole rigamarole again the next time one of its clients wants to know what '*A foo.example.com <http://foo.example.com>.*' resolves to.). 5. The resolver (R) then answers the client that made the first query (Q) with the answer it got from its cache/from the domain's nameserver(s) (A). In brief: Q -> R [ -> I, R -> N, R -> A ] -> Q (Square brackets are skipped if it's a valid cache hit, followed if not.) You will notice that at *no point* in this process does it query the registrar as such an entity/role (B). That means the registrar has no opportunity to "inject" or serve a TXT record for a domain (unless example.com has *set* its nameservers - "A" - to those offered as a service by the registrar). The resolver (R) (nor the client (Q), even) knows, nor cares, who owns the nameservers (A). It could be some guy named Joe in the middle of Kentucky running it off a bunch of OpenWRT off-the-shelf things in his garage using a Perl script he hired his grandson to write, for all it cares - if it's set as the NS for example.com via the NS for .com, and it serves valid DNS, it's using it. Theoretically, you could *maybe* do this via RDAP (the modern replacement for WHOIS; ICANN sunset WHOIS on Jan. 25 last year) - but RDAP (and WHOIS) isn't DNS at all. It's a totally different flow and protocol (HTTPS, specifically, in the case of RDAP). It'd require an update to the RDAP spec, though - one that, in my opinion, would not serve beneficial enough to warrant as you laid it out. I can only see it causing more issues for good-faith domain owners and not effective enough in combating bad-faith domain owners. *TL;DR:* "No, DNS doesn't work like that; it'd need a new protocol explicitly bound to querying the registrar instead of a server/service/protocol the domain owner can host/serve themselves but IMHO it's the wrong approach anyways." [0] If your client doesn't support links, that's https://www.rfc-editor.org/rfc/rfc3740.txt