Domain Security Info
Data Dictionary
Updated May 1, 2026, 8:27 AM
Data dictionary#
This page describes every piece of data that Domain Security Information stores, how it is used, and who can see it. The system stores two kinds of data: data it shows to the public during lookups, and data it keeps for administrators to manage the platform.
Who sees what#
The tool has two audiences. Understanding who sees what helps you make sense of the data fields below.
| Audience | What they see | Where |
|---|---|---|
| Public users | Live DNS records, WHOIS data, identified services, brand badges, and security status for any domain or IP they look up | domainsecurityinfo.com |
| Administrators | Everything public users see, plus the full knowledge base, analytics, audit logs, user management, scan history, and historical analysis data | admin.domainsecurityinfo.com |
Historical analysis data is only available to administrators. The public API (/raw/{domain}) returns a live, real-time snapshot of a domain's current state. It does not include past analysis results, change history, or scan records. Only the admin interface stores and displays historical information.
Brands#
Brands represent organizations that operate internet services. They are the foundation of the identification system โ every tag, verified domain, IP prefix, and verified ASN connects back to a brand.
| Field | What it stores | Example |
|---|---|---|
| Brand ID | A short, unique text identifier chosen when the brand is created. Cannot be changed later. | google, cloudflare, microsoft |
| Name | The display name shown in badges on lookup results. | Google, Cloudflare, Microsoft 365 |
| Color | A hex color code that sets the badge background color. White text appears on this background, so the color needs enough contrast to be readable. | #4285F4 (Google blue) |
| URL | A link to the brand's website. When set, clicking the badge opens this link. | https://cloud.google.com |
| Location | The brand's headquarters or primary location. This is for reference only and does not affect lookups. | San Francisco, CA |
| Created at | When the brand was first added to the system. Set automatically. | 2024-03-15T10:30:00Z |
| Updated at | When the brand was last changed. Updates automatically on every edit. | 2025-01-20T14:15:00Z |
| Version | A number that increases by one with every edit. Starts at 1. Used for tracking changes over time. | 5 |
Brand revision history (admin only)#
Every time a brand is created, edited, or deleted, the system saves a snapshot of the change. This history is only visible to administrators.
| Field | What it stores |
|---|---|
| Brand ID | Which brand was changed. |
| Change type | Whether the brand was created, updated, or deleted. |
| Changed by | Who made the change (defaults to system for automated changes). |
| Changed at | When the change happened. |
| Previous version | The version number before the change. |
| New version | The version number after the change. |
| All brand fields | A copy of every brand field at the time of the change (name, color, URL, location). |
TXT record tags#
TXT record tags are patterns that identify services in a domain's TXT DNS records. When a TXT record matches a tag's pattern, the lookup results show a colored badge with the service name.
| Field | What it stores | Example |
|---|---|---|
| Pattern | The text to match against TXT records. The system uses this for prefix matching (record starts with this text) or exact matching (record equals this text exactly). Must be unique across all TXT tags. | google-site-verification= |
| Brand | The brand this tag belongs to. Determines the badge color and name unless overridden. Optional โ tags without a brand show a default gray badge. | |
| Service name | A custom name for the badge. If left blank, the brand's name is used. | Google Search Console |
| Color | Overrides the brand's default color for this specific tag. Optional. | #34A853 |
| URL | A link that makes the badge clickable. Optional. | https://search.google.com/search-console |
| Created at | When the tag was first added. | |
| Updated at | When the tag was last changed. | |
| Version | Increases by one with every edit. |
MX record tags#
MX record tags identify email providers by matching patterns in a domain's MX (mail exchange) DNS records. The system uses suffix matching โ it checks whether the MX hostname ends with the tag's pattern.
| Field | What it stores | Example |
|---|---|---|
| Pattern | The text to match against MX record hostnames. The system checks whether the hostname ends with this text. Include the leading dot to prevent partial matches. | .google.com |
| Brand | The brand this tag belongs to. | |
| Service name | A custom name for the badge. | Google Workspace |
| Color | Overrides the brand's default color. Optional. | |
| URL | A clickable link on the badge. Optional. | https://workspace.google.com |
| Created at | When the tag was first added. | |
| Updated at | When the tag was last changed. | |
| Version | Increases by one with every edit. |
NS record tags#
NS record tags identify DNS providers by matching patterns in a domain's nameserver records. Like MX tags, NS tags use suffix matching by default.
| Field | What it stores | Example |
|---|---|---|
| Pattern | The text to match against nameserver hostnames. | .ns.cloudflare.com |
| Brand | The brand this tag belongs to. | cloudflare |
| Service name | A custom name for the badge. | Cloudflare DNS |
| Color | Overrides the brand's default color. Optional. | |
| URL | A clickable link on the badge. Optional. | |
| Created at | When the tag was first added. | |
| Updated at | When the tag was last changed. | |
| Version | Increases by one with every edit. |
All three tag types (TXT, MX, NS) store revision history with the same fields as brand revisions: what changed, when, who made the change, and previous and new version numbers.
Regex patterns#
Regex patterns provide advanced matching for TXT records that have variable formats and can't be matched by simple prefix or exact text matching.
| Field | What it stores | Example |
|---|---|---|
| Pattern | A regular expression that the system tests against each TXT record. | ^[a-f0-9]{32}$ |
| Service name | The name shown in the badge when this pattern matches a record. | Hex Verification Token |
| Color | The badge background color. | #6C757D |
| URL | A clickable link on the badge. Optional. | |
| Priority | A number that controls matching order. Lower numbers are checked first. If two regex patterns could match the same record, the one with the lower priority number wins. | 10 |
| Active | Whether this pattern is currently used during lookups. Inactive patterns are stored but ignored. | true |
Verified domains#
Verified domains are apex domains that an administrator has confirmed belong to a specific brand. When someone looks up a verified domain, they see the brand's badge at the top of the results.
| Field | What it stores | Example |
|---|---|---|
| Apex domain | The registered domain name, without subdomains. Each domain can only appear once. | google.com |
| Brand | The brand this domain belongs to. Required. | |
| Secondary line | Extra context shown below the brand name on the badge. | Cloud Division |
| Tertiary line | A third line of context on the badge. | Mountain View, CA |
| Subdomain treatment | Controls whether subdomains of this domain also show the brand badge. Options: noSubdomains (only the exact apex domain), allSubdomains (any subdomain), or pattern (custom matching). | allSubdomains |
| Verification type | How the domain's ownership was confirmed. For reference only. | manual, dns, cname |
| Created at | When the verified domain was first added. | |
| Updated at | When it was last changed. | |
| Version | Increases by one with every edit. |
Verified domains also affect how NS records are identified. If a nameserver hostname falls under a verified domain, it automatically inherits that domain's brand. For example, if cloudflare.com is verified as Cloudflare, then ns1.cloudflare.com is automatically tagged as a Cloudflare nameserver โ even without a matching NS tag.
Verified domain revisions are stored with the same structure as other revision histories.
Known IP prefixes#
Known IP prefixes map ranges of IP addresses to brands. When someone looks up an IP address that falls within a known prefix, the results show the brand's badge.
| Field | What it stores | Example |
|---|---|---|
| IP prefix | The IP address range in CIDR notation. Must be unique. | 8.8.8.0/24 |
| IP version | Whether this is an IPv4 (4) or IPv6 (6) prefix. Detected automatically from the address format. | 4 |
| Brand | The brand that owns this IP range. Required. | |
| Description | A note about what this prefix is used for. | Google Public DNS |
| Created at | When the prefix was first added. | |
| Updated at | When it was last changed. | |
| Version | Increases by one with every edit. |
How IP prefix matching works#
When someone looks up an IP address, the system checks it against all known prefixes for the matching IP version (IPv4 or IPv6). If the IP address falls within multiple prefixes, the system picks the most specific one โ the prefix with the longest prefix length.
For example, if the database has 8.8.8.0/24 (256 addresses) and 8.8.8.8/32 (1 address), and someone looks up 8.8.8.8, the system returns the /32 match because it is more specific.
IP prefix revisions are stored with the same structure as other revision histories.
Verified ASNs#
Verified ASNs link autonomous system numbers to brands. An ASN identifies a network operator on the internet. When someone looks up an IP address and the WHOIS data includes a verified ASN, the results can show the brand's badge.
| Field | What it stores | Example |
|---|---|---|
| ASN | The full ASN identifier, including the "AS" prefix. | AS15169 |
| ASN number | The numeric part of the ASN. | 15169 |
| Brand | The brand that operates this ASN. Required. | |
| Description | A note about this ASN. | Primary Google network |
| Additional line 1 | Extra context shown with the brand badge. | Google LLC |
| Additional line 2 | A second line of extra context. | Mountain View, CA |
| Created at | When the ASN was first added. | |
| Updated at | When it was last changed. | |
| Version | Increases by one with every edit. |
Known service domains#
Known service domains categorize domains by the type of service they provide. Unlike verified domains, which link a domain to a brand, known service domains describe what a domain does.
| Field | What it stores | Example |
|---|---|---|
| Domain | The domain name. Must be unique. | sendgrid.net |
| Service type | The kind of service this domain provides. | email, cdn, hosting |
| Notes | Additional context about the service. Optional. | SendGrid transactional email platform |
When someone looks up a domain, the public results include a "services" section that shows any matching known service domains. The system checks both the queried domain and its apex domain.
WHOIS cache#
The system caches WHOIS data to reduce the number of calls to the external WHOIS API. This cache is invisible to users โ they see WHOIS data as if it were fetched live.
| Field | What it stores |
|---|---|
| Domain | The domain that was looked up. |
| WHOIS data | The full WHOIS response, stored as JSON. |
| Expires at | When the cached data becomes stale. Set to 24 hours after the lookup. After this time, the next lookup fetches fresh data. |
| Created at | When the cached entry was stored. |
Domain analysis history (admin only)#
Every domain lookup produces an analysis. The system saves these analyses so administrators can track how a domain's configuration changes over time. This data is not available through the public API or public website. The public API only returns the current, real-time state.
| Field | What it stores | Example |
|---|---|---|
| Domain | The domain that was analyzed. | example.com |
| Is apex domain | Whether the analyzed domain is an apex domain (not a subdomain). | true |
| Analysis timestamp | When the analysis ran. | 2025-06-15T08:00:00Z |
| DNS resolvable | Whether the domain's DNS records could be resolved. | true |
| DNS resolution time | How long the DNS queries took, in milliseconds. | 45 |
| TXT records count | How many TXT records the domain has. | 8 |
| TXT records (JSON) | The full list of TXT records at the time of analysis. | ["v=spf1 ...", "google-site-verification=..."] |
| TXT tags found | Which known tags matched the TXT records. | ["SPF", "Google Search Console"] |
| TXT security score | A score from 0 to 100 rating the quality of TXT record security. | 75 |
| MX records count | How many MX records the domain has. | 5 |
| MX records (JSON) | The full list of MX records. | |
| MX tags found | Which known tags matched the MX records. | ["Google Workspace"] |
| MX security score | A score from 0 to 100. | 80 |
| NS records count | How many NS records the domain has. | 2 |
| NS records (JSON) | The full list of NS records. | |
| NS tags found | Which known tags matched the NS records. | ["Cloudflare DNS"] |
| NS security score | A score from 0 to 100. | 90 |
| CAA records count | How many CAA records the domain has. | 3 |
| CAA records (JSON) | The full list of CAA records. | |
| SPF record | The full text of the SPF record. | v=spf1 include:_spf.google.com ~all |
| SPF security score | A score from 0 to 100. | 70 |
| DMARC record | The full text of the DMARC record. | v=DMARC1; p=reject; ... |
| DMARC security score | A score from 0 to 100. | 95 |
| Overall security score | A combined score from 0 to 100 that summarizes the domain's security posture. | 78 |
| Security issues | A list of problems found during analysis. | ["No CAA records", "SPF uses ~all instead of -all"] |
| Recommendations | Suggested improvements. | ["Add CAA records", "Switch SPF to -all"] |
| Processing time | How long the full analysis took, in milliseconds. | 1200 |
| Had error | Whether the analysis encountered any errors. | false |
| Error message | The error message, if one occurred. | |
| Has changes | Whether this analysis detected differences from the previous one. | true |
| Changes summary | A text description of what changed. | TXT record added: stripe-verification=... |
| Source | How the analysis was triggered. | public-lookup, scheduled, manual, admin-search |
Domain changes (admin only)#
When the system detects that a domain's DNS records changed between analyses, it stores a record of each change. This data is only available to administrators.
| Field | What it stores | Example |
|---|---|---|
| Domain | The domain where the change was detected. | example.com |
| Change type | What kind of change happened. | txt_added, txt_removed, mx_changed, ns_changed |
| Record type | Which DNS record type changed. | txt, mx, ns, caa, spf, dmarc |
| Old value | The previous value of the record. | v=spf1 include:old-provider.com ~all |
| New value | The new value of the record. | v=spf1 include:new-provider.com ~all |
| Old count | How many records of this type existed before. | 3 |
| New count | How many records of this type exist now. | 4 |
| Security impact | Whether the change improved, worsened, or had no effect on security. | positive, negative, neutral |
| Security score change | How much the security score changed. | +5, -10 |
| Detected by | How the change was found. | automated, manual, import |
| Notes | Any additional context. |
Known apex domains (admin only)#
The system tracks a large database of apex domains for ongoing monitoring. This data is only available to administrators.
| Field | What it stores | Example |
|---|---|---|
| Apex domain | The registered domain. | google.com |
| TLD | The top-level domain. | .com, .co.uk |
| Domain level | How many parts make up the TLD. 2 for .com, 3 for .co.uk, 4 or more for complex TLDs. | 2 |
| Is active | Whether the system is actively monitoring this domain. | true |
| First seen | When the domain was first added to the tracking system. | |
| Last checked | When the domain was last analyzed. | |
| Last analysis | When the most recent full analysis ran. | |
| Check frequency (hours) | How often the system should re-analyze this domain. Default is every 24 hours. | 24 |
| Priority level | How important this domain is. 1 = normal, 2 = high, 3 = critical. Higher-priority domains are analyzed more frequently. | 1 |
| Brand | The brand this domain belongs to, if known. | |
| Estimated traffic level | A rough estimate of the domain's traffic. 0 = unknown, 1 = low, 2 = medium, 3 = high. | 3 |
| Domain type | How the domain entered the system. | verified, discovered, imported, unknown |
| Source | Where the domain came from. | bulk-import, manual, zone-file |
| Metadata | Additional structured data stored as JSON. |
Analytics data (admin only)#
The system records detailed analytics about how the public tool is used. All analytics data is only visible to administrators.
Request tracking#
Each domain or IP lookup is logged with:
| Field | What it stores |
|---|---|
| Domain | The domain or IP that was looked up. |
| Apex domain | The apex domain extracted from the query. |
| Timestamp | When the lookup happened. |
| Country, region, city | The approximate location of the person who made the request, based on Cloudflare headers. |
| Is verified domain | Whether the looked-up domain is in the verified domains database. |
| Brand | The associated brand, if any. |
| Has TXT/MX/NS tags | Whether the domain had records matching known tags. |
| Has WHOIS data | Whether WHOIS data was available. |
| WHOIS cache hit | Whether the WHOIS data came from cache or required a fresh API call. |
| Response time | How long the full response took, in milliseconds. |
| DNS lookup time | How long the DNS queries took, in milliseconds. |
| WHOIS lookup time | How long the WHOIS lookup took, in milliseconds. |
| Had error | Whether the request encountered an error. |
| Error type and message | Details about the error, if one occurred. |
Daily statistics#
Aggregated numbers calculated once per day:
| Field | What it stores |
|---|---|
| Total requests | How many lookups happened that day. |
| Unique domains | How many different domains were looked up. |
| Verified domain requests | How many lookups matched a verified domain. |
| WHOIS cache hits | How many WHOIS lookups were served from cache. |
| WHOIS API calls | How many fresh WHOIS API calls were needed. |
| Error count | How many requests returned errors. |
| Average response time | The mean response time for the day, in milliseconds. |
| Peak hour | The hour of day (0โ23) with the most traffic. |
| Peak hour requests | How many requests happened during the busiest hour. |
Popular domains#
The most-requested domains, calculated for different time periods:
| Field | What it stores |
|---|---|
| Period | The time window: daily, weekly, monthly, or all time. |
| Domain | The domain name. |
| Request count | How many times it was looked up during the period. |
| Rank | Its position in the list (1 = most popular). |
| Brand | The associated brand, if any. |
| Is verified | Whether the domain is in the verified domains database. |
Brand analytics#
How often each brand appears in lookups:
| Field | What it stores |
|---|---|
| Brand | The brand being tracked. |
| Period | The time window: daily, weekly, or monthly. |
| Domain count | How many unique domains are associated with this brand. |
| Request count | How many lookups involved this brand. |
| Unique visitors | How many different people triggered this brand. |
Tag usage#
How often each tag matches records in lookups:
| Field | What it stores |
|---|---|
| Tag type | TXT, MX, or NS. |
| Tag pattern | The pattern text. |
| Period | The time window. |
| Match count | How many times this tag matched a record. |
| Domain count | How many different domains triggered this tag. |
Geographic analytics#
Where requests come from:
| Field | What it stores |
|---|---|
| Country | The country code and name. |
| Region | The state or region. |
| City | The city. |
| Request count | How many requests came from this location. |
| Unique domains | How many different domains were looked up from this location. |
Users (admin only)#
The system tracks administrator accounts. Users are created automatically the first time someone logs in through Cloudflare Access.
| Field | What it stores | Example |
|---|---|---|
| ID | A unique identifier from Cloudflare Access. | a1b2c3d4-... |
| The admin's email address. | admin@example.com | |
| Name | The admin's display name. | Jane Smith |
| Role | The admin's permission level. | super_admin, admin, editor, viewer |
| Status | The account's current state. | active, suspended, deleted |
| First login | When the admin first accessed the system. | |
| Last login | When the admin most recently logged in. | |
| Login count | How many times the admin has logged in. | 42 |
Audit logs (admin only)#
Every action in the admin interface is recorded in the audit log.
| Field | What it stores |
|---|---|
| Timestamp | When the action happened. |
| User email | Who did it. |
| Action type | What they did: create, read, update, delete, login, logout, export, or import. |
| Entity type | What kind of data was affected: brand, txt_tag, mx_tag, ns_tag, verified_domain, user, or system. |
| Entity ID | The specific item's identifier. |
| Entity name | A human-readable name for the item. |
| Action details | A description of what happened. |
| Changes (JSON) | The exact fields that changed, including old and new values. |
| Request method and path | The HTTP method and URL path of the request. |
| Response status | The HTTP status code returned. |
| Response time | How long the request took, in milliseconds. |
| Risk score | An automatically calculated score (0โ100) based on the action's characteristics. Higher scores mean more unusual activity. |
| Flags | Automatically generated labels for unusual patterns, such as unusual_ip, bulk_delete, off_hours_activity, or rapid_changes. |
The audit log also captures network and security metadata from Cloudflare, including: IP address, country, Cloudflare Ray ID, bot score, threat score, ASN, and whether the request came through Cloudflare WARP.
User sessions (admin only)#
Each time an administrator accesses the system, a session is created and tracked.
| Field | What it stores |
|---|---|
| Session ID | A unique identifier for this session. |
| User | The admin's ID and email. |
| Started at | When the session began. |
| Last activity | When the admin last did something. |
| Ended at | When the session ended. |
| IP address | Where the session came from. |
| User agent | The browser or client used. |
| Location | Country, region, and city. |
| Authentication method | How the admin logged in: SAML, OIDC, or service token. |
Scan queue and batches (admin only)#
The system schedules and processes domain scans in batches. These records track scanning operations.
Scan queue#
| Field | What it stores |
|---|---|
| Domain | The domain to scan. |
| Priority | 1 = normal, 2 = high, 3 = critical. |
| Scheduled for | When the scan should run. |
| Status | Current state: pending, running, completed, failed, or cancelled. |
| Attempts | How many times the scan has been tried. |
| Max attempts | The maximum number of tries before giving up (default: 3). |
| Last error | The error message from the most recent failed attempt. |
| Processing time | How long the scan took, in milliseconds. |
Scan batches#
| Field | What it stores |
|---|---|
| Batch name | A human-readable name for the batch. |
| Batch type | How the batch was created: daily, priority, manual, or backfill. |
| Total domains | How many domains are in the batch. |
| Completed domains | How many have finished scanning. |
| Failed domains | How many failed. |
| Status | Current state: running, completed, failed, or cancelled. |
What the public API returns#
When someone uses the public JSON API (/raw/{domain}), the response includes the following data โ all of which reflects the domain's current, real-time state:
| Field | What it contains |
|---|---|
| domain | The queried domain. |
| apexDomain | The extracted apex domain. |
| nameservers | NS records, each with any matching tag (name, color, URL, brand). |
| txtRecords | TXT records, each with any matching tag. |
| mxRecords | MX records, each with any matching tag. |
| aRecords | IPv4 addresses (A records). |
| aaaaRecords | IPv6 addresses (AAAA records). |
| dnssecStatus | Whether DNSSEC is enabled, plus algorithm and key details. |
| spfStatus | The SPF record and whether it is valid. |
| dmarcStatus | The DMARC record and policy details. |
| dkimStatus | Whether a DKIM selector was found, and which one. |
| hstsStatus | Whether the HSTS header is present and its settings. |
| hstsPreloadStatus | Whether the domain is on the browser HSTS preload list. |
| mtaStsStatus | Whether MTA-STS is configured. |
| tlsRptStatus | Whether TLS-RPT is configured. |
| whoisData | Registration details: registrar, dates, status codes, contacts, nameservers. |
| services | Known service associations detected from the domain or its DNS records. |
The public API does not include:
- Past analysis results
- Change history
- Security scores
- Scan records
- Analytics data
- Audit logs
- User information