Is domain intelligence legal?

Best move: read only public data (DNS, TLS, HTTP, WHOIS) that no login or paywall guards, and you stay on firm legal ground in most jurisdictions.

Why it works: courts and regulators draw the line at access, not observation. Reading what a server publishes to anyone breaks no anti-hacking law. Breaking the gate that guards it does.

Key takeaways

• Domain intelligence that reads public DNS, WHOIS, TLS certificates, and HTTP responses is legal in most jurisdictions.
• US courts (hiQ v. LinkedIn, Van Buren v. United States) narrowed the CFAA so that scraping publicly available data is not “unauthorized access.”
• The bright line is access control. Circumventing a login, paywall, or IP block to reach data changes the legal picture.
• Privacy law (GDPR, CCPA) applies to personal data, not to infrastructure signals. A firmographic contact can pull a dossier into scope; a TLS certificate cannot.
• robots.txt and Terms of Service set norms and can create contract exposure, but neither is a criminal statute on its own.

What makes domain intelligence legal?

Domain intelligence reads what a domain publishes to the open internet. DNS records answer any resolver that asks. WHOIS, where not redacted, is published under ICANN policy. A TLS certificate is presented to every client that opens a connection. An HTTP response to a public URL is, by definition, public. None of this requires a credential, and none of it defeats an access control. The activity clears the anti-hacking statutes for one reason: you read what a server volunteers, not what it guards.

US case law has moved in this direction. In hiQ Labs v. LinkedIn, the Ninth Circuit held that scraping publicly available profiles did not violate the Computer Fraud and Abuse Act, because public data is not accessed “without authorization.” Van Buren v. United States (Supreme Court, 2021) narrowed the CFAA further, tying liability to gated systems a user is not entitled to reach. Both rulings point the same way: observing public surfaces sits outside the anti-hacking statutes.

Legal does not mean unlimited. Copyright still covers the content you copy. Contract law still reaches terms you agreed to. But the baseline act, resolving a domain and reading its public responses, is the same thing every browser and search crawler does millions of times a day.

When does domain intelligence cross a legal line?

Access is the line. The moment you circumvent something built to keep you out, the analysis changes. Bypassing a login, reusing stolen credentials, defeating a paywall, or routing around an IP ban to reach gated data can trigger the CFAA in the US and equivalent computer-misuse laws elsewhere. The data behind a broken gate can be identical to public data; breaking the gate is what changes the law.

Request volume is a second axis. A scan that hits a server hard enough to degrade it can look like a denial-of-service, and a high request rate against a target that has asked you to stop invites both technical blocks and legal complaints. Respect rate limits and back off on errors.

What you do with the output matters more than either. Clean collection can feed unlawful use. Harvesting contact emails and blasting unsolicited commercial mail runs into CAN-SPAM (US) and the ePrivacy rules (EU). Using firmographic data to make automated decisions about individuals can pull you under GDPR’s profiling provisions. The data can be public and the collection clean, yet the downstream action still crosses a line.

The safe posture: read only public surfaces, never defeat an access control, keep request volume polite, and check that your use of the output is lawful for your jurisdiction and industry.

Does GDPR apply to a domain dossier?

Sometimes. GDPR governs personal data of people in the EU, not infrastructure. An IP address, ASN, nameserver, or TLS certificate describes machines, not people, and mostly sits outside the regulation. The moment a dossier includes a named contact, a personal email, or a WHOIS registrant who is an individual, you are processing personal data and GDPR attaches.

When it attaches, you need a lawful basis. For business intelligence, that is usually legitimate interest, which requires a balancing test against the individual’s rights and expectations. You also inherit transparency and access obligations: the person can ask what you hold and demand deletion. That is easier to satisfy if you never retained the data in the first place.

WHOIS is where this bites hardest. After GDPR, registrars began redacting registrant details for individuals, which is why so many lookups now return privacy-proxy values. Reading a redacted record is fine. Reconstructing the person behind the redaction is where you re-enter regulated territory.

CCPA and similar US state laws work the same way for California residents. The rule holds across regimes: infrastructure signals are low risk, personal identifiers are regulated, and the less personal data you store, the smaller your obligation.

Do robots.txt and Terms of Service bind a scanner?

Not the way a statute binds you, but they carry weight. robots.txt is a voluntary protocol, standardized as RFC 9309 (the Robots Exclusion Protocol). It expresses a site’s crawling preferences. Ignoring it is not a crime, and courts have generally declined to treat it as a binding contract on its own. It is a norm with reputational and technical teeth: violate it and you invite blocks, complaints, and bad-faith arguments against you later.

Terms of Service are different. A ToS you accepted (clickwrap) can create real contract exposure, and breach-of-contract and trespass-to-chattels claims have succeeded where scraping continued after explicit notice to stop. Browsewrap terms buried in a footer are weaker and often unenforceable, but “we did not read it” is a thin defense once you have been told to cease.

The practical hierarchy: criminal computer-misuse law is the hard floor (do not defeat access controls), contract and tort sit above it (honor terms you accepted, stop when told), and robots.txt is the courtesy layer that keeps you out of trouble before any of that escalates. A well-behaved domain scanner treats robots directives as defaults to respect, identifies itself honestly, and does not impersonate a human browser to slip past controls.

What does a lawful domain-intelligence request look like?

A lawful request resolves DNS, reads the TLS certificate, requests public URLs the way a browser would, and parses what comes back. It does not log in, borrow someone else’s cookie, or brute-force a subdomain behind auth. It identifies itself rather than posing as a person, and it stops at what the server publishes.

Bassethound is built to that shape on purpose. Every sniff_domain call reads only public surfaces: DNS, WHOIS, the TLS certificate, HTTP responses, and public files like llms.txt and .well-known. It is read-only, so it changes nothing on the target. It is stateless, so nothing carries from one call to the next. Bassethound assembles the dossier inside the request and returns it, and the evidence for each detection ships inside the result. When a static crawl cannot reach a fully server-side or proxied component, the dossier reports the gap instead of guessing or probing harder.

That design does more than lower legal risk. It makes each call auditable. You can point to the exact public signal behind every detection, because the evidence travels with the result. Note the honest limit: this is engineering guidance, not legal advice. Your jurisdiction, industry, and downstream use change the calculus, and a regulated use case deserves a real lawyer.

Bassethound perspective

Legality is the settled part. Reading public data has been lawful for as long as the web has had a robots.txt. The question that separates vendors is whether you can prove what you looked at, and most of the market cannot. The infra and firmographic incumbents built their moats by warehousing scraped corpora: years of WHOIS history, harvested contacts, cached crawls. That store is the asset and the liability at once. Every retained record is a GDPR access request waiting to happen and a breach blast radius you did not need.

Bassethound made the opposite bet. The moat is fusion in a single call rather than a hoard of personal records, which is what keeps the compliance question narrow. Each request reads public surfaces, correlates five layers, and returns the dossier, and the evidence for every detection ships inside the result, so the call is reconstructable from public data alone. We store your results against your account, and the privacy policy governs that. A competitor sitting on a decade of scraped personal records would call our position a weakness. We think not building that hoard in the first place is the stronger design.

Sources

• RFC 9309, Robots Exclusion Protocol: https://datatracker.ietf.org/doc/html/rfc9309
• Computer Fraud and Abuse Act, 18 U.S.C. § 1030 (Cornell Legal Information Institute): https://www.law.cornell.edu/uscode/text/18/1030
• General Data Protection Regulation, full text (EUR-Lex): https://eur-lex.europa.eu/eli/reg/2016/679/oj
• MDN Web Docs, robots.txt: https://developer.mozilla.org/en-US/docs/Glossary/Robots.txt