DNS/FQDN Enrichment
Automatic FQDN augmentation of infrastructure CIs from DNS zone records
Overview
DNS enrichment is an automatic data augmentation pipeline that maps Fully Qualified Domain Names (FQDNs) from DNS zone records onto infrastructure CIs that have matching IP addresses. When the DNS collector ingests a zone containing A or AAAA records, the enrichment engine resolves each record's IP against every active CI in the database. Matching CIs receive the corresponding FQDN, along with provenance metadata that records where the name came from and when it was added.
This enables a critical operational workflow: alert triage by hostname. When an FQDN appears in a monitoring alert, a log entry, or a firewall rule, you can search Parascope for that name and immediately find the exact infrastructure CI -- without needing to know which system manages it or what its internal identifier is.
DNS enrichment complements two other Parascope features. The correlation engine discovers relationships between CIs from different sources, while enrichment adds attributes to existing CIs. And infrastructure lineage surfaces inherited FQDNs from ancestor CIs, so a Kubernetes pod can inherit the DNS names of the node it runs on.
Architecture
The enrichment pipeline runs entirely within Parascope. When the DNS collector publishes zone data, the enrichment pipeline creates or updates a dns.zone CI, then immediately triggers the DNS enricher against that zone's records.
The enricher performs four steps for each A or AAAA record in the zone:
- Construct the FQDN from the record name and zone name (e.g.,
web-01in zoneprod.company.combecomesweb-01.prod.company.com) - Query the database for active CIs whose
ip_addressesfield contains the record's IP value - Add the FQDN to each matching CI's
fqdnslist, skipping duplicates - Record provenance in the CI's
fqdn_sourcesfield, noting the source type (correlated), the DNS zone CI that provided it, and a timestamp
Supported DNS Sources
The DNS collector supports five source types, each with its own connection method and zone discovery strategy.
| Source Type | Protocol | Zone Discovery | Configuration |
|---|---|---|---|
| CoreDNS | Zone transfer (AXFR) | Explicit zone list required | DNS_SERVER, DNS_PORT, DNS_ZONES |
| BIND | Zone transfer (AXFR) | Explicit zone list required | DNS_SERVER, DNS_PORT, DNS_ZONES |
| Route53 | AWS boto3 SDK | Auto-discovers all hosted zones | AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION |
| Infoblox | WAPI REST API | Auto-discovers all authoritative zones | INFOBLOX_URL, INFOBLOX_USERNAME, INFOBLOX_PASSWORD |
| Active Directory | LDAP | Auto-discovers AD-integrated zones | AD_SERVER, AD_USERNAME, AD_PASSWORD, AD_BASE_DN |
CoreDNS and BIND rely on DNS zone transfers (AXFR), which require explicit zone names because the DNS protocol does not support zone enumeration. Route53 and Infoblox automatically discover all available zones, so new zones are collected without configuration changes. TSIG authentication is supported for secured zone transfers.
FQDN Fields on CIs
Every Configuration Item in Parascope carries three FQDN-related fields. Together they provide both the name data and the audit trail for how each name was discovered.
| Field | Type | Description | Example |
|---|---|---|---|
hostnames | list of strings | Short names without domain suffix | ["web-prod-01", "api-gateway"] |
fqdns | list of strings | Fully qualified domain names | ["web-prod-01.prod.company.com"] |
fqdn_sources | object | Provenance metadata keyed by FQDN | See below |
The fqdn_sources dictionary tracks where each FQDN came from. Each entry records the source type, the source CI or system that provided the name, and a timestamp:
{
"web-prod-01.prod.company.com": {
"type": "correlated",
"source": "dns.zone:550e8400-e29b-41d4-a716-446655440000",
"enriched_at": "2026-01-25T10:30:00+00:00"
},
"web-prod-01.k8s.local": {
"type": "derived"
}
}Provenance Types
Parascope distinguishes three provenance types for FQDNs. This distinction matters because it tells you whether a name was directly observed, computed, or inferred from an external source.
| Provenance Type | Meaning | Typical Source |
|---|---|---|
| explicit | Set directly by a collector from the source system's own data | Kubernetes node addresses, Netbox device custom fields |
| derived | Computed by a handler from other fields on the same CI | Pod DNS from namespace and pod name, service cluster DNS |
| correlated | Added by the DNS enrichment pipeline from zone records | A/AAAA records matching the CI's IP address |
Explicit and derived FQDNs are populated during normal collection processing. Correlated FQDNs are added asynchronously by the enricher after DNS zone data arrives.
Automatic FQDN Extraction by Source
Each collector extracts hostnames and FQDNs in source-specific ways. The following table summarizes the extraction logic for each source.
| Source | CI Type | Extraction Logic | Provenance |
|---|---|---|---|
| Kubernetes | kubernetes.pod | Hostname from spec.hostname; FQDN from {hostname}.{subdomain}.{namespace}.svc.cluster.local if subdomain is set | explicit / derived |
| Kubernetes | kubernetes.service | Name as hostname; FQDN as {name}.{namespace}.svc.cluster.local | explicit / derived |
| Kubernetes | kubernetes.node | Hostnames from InternalDNS and ExternalDNS address types in status.addresses | explicit |
| Proxmox | proxmox.vm, proxmox.container | Hostname from config; FQDN from {hostname}.{searchdomain} when search domain is configured | explicit / derived |
| OpenStack | openstack.instance | Hostname from metadata.hostname or instance name; FQDN from {name}.{metadata.domain} if domain metadata is present | explicit / derived |
| Netbox | netbox.device | FQDNs from custom fields: fqdn, hostname_fqdn, or dns_name | explicit |
| Ceph | ceph.host | If hostname contains dots, the short hostname is extracted as the hostname and the full value kept as FQDN | explicit |
All of these are populated during the normal collection cycle. The DNS enrichment pipeline then adds additional correlated FQDNs from zone records, filling in names that the original collectors could not discover on their own.
Enrichment Behavior
The DNS enricher is designed to run automatically, safely, and efficiently.
Fully automatic. Enrichment triggers on every DNS zone collection cycle. When a dns.zone CI is created or updated, the enrichment engine immediately processes that zone's records. There is no manual step or separate schedule.
Idempotent. The enricher checks each CI's existing fqdns list before adding a name. If the FQDN is already present, it is skipped. This means enrichment is safe to run repeatedly -- reprocessing a zone produces no duplicates and no unnecessary database writes.
Scoped to active CIs. Only CIs with status = "active" and a populated ip_addresses field are considered for enrichment. Deleted or inactive CIs are not enriched, which prevents stale data from accumulating.
Bidirectional enrichment. In addition to zone-triggered enrichment, the enricher supports the reverse direction: when a new CI with IP addresses is created, it can be enriched against all existing DNS zones. This ensures that CIs created before the DNS zone was collected still receive their FQDNs.
Searching by FQDN
Once FQDNs are populated on CIs, Parascope's search and filtering capabilities make them immediately queryable.
Full-Text Search
The global search bar searches across hostnames and fqdns fields. Typing a full FQDN or even a partial hostname will match any CI that carries that name:
web-prod-01.prod.company.com -- matches exact FQDN
web-prod-01 -- matches hostname across all domains
prod.company.com -- matches CIs in that domainFilter Syntax
For precise filtering, use the CONTAINS operator to check array membership:
# Find CIs with a specific FQDN
curl -H "X-API-Key: $API_KEY" \
"https://your-company.parascope.io/api/v1/configuration-items?filter=fqdns:CONTAINS:web-prod-01.prod.company.com"
# Find CIs with a specific hostname
curl -H "X-API-Key: $API_KEY" \
"https://your-company.parascope.io/api/v1/configuration-items?filter=hostnames:CONTAINS:web-prod-01"Search Workflow: Alert Triage
The typical workflow for using DNS enrichment in alert triage:
- An alert fires referencing
db-primary.prod.company.com - Search Parascope for that FQDN
- The search returns the matching CI (e.g., a
proxmox.vmnameddb-primary) - Open the CI detail page to see its full context: relationships, lineage, change history
- Use infrastructure lineage to trace down to the physical host, rack, and site
Viewing Enrichment Data
CI Detail Page
The CI detail page displays hostnames and FQDNs in the overview section alongside IP addresses and other identity fields. Hostnames appear as compact labels, and FQDNs are shown with their full domain suffix.
FQDN Provenance
The fqdn_sources field is visible in the CI's raw data view. Each FQDN entry shows:
- type -- whether the name is
explicit,derived, orcorrelated - source -- for correlated FQDNs, the
dns.zoneCI that provided the mapping - enriched_at -- the timestamp when the enrichment occurred
DNS Zone CIs
DNS zones themselves appear as dns.zone CIs in the main CI list. Each zone CI carries the full set of records in its raw_data, along with metadata like the zone serial number and record count. You can browse these to understand which zones are being collected and what records they contain.
Example: End-to-End Enrichment
Consider a DNS zone example.com collected from a CoreDNS server. The zone contains these A records:
| Record Name | Type | Value |
|---|---|---|
| app-server-01 | A | 10.0.1.60 |
| worker-node-01 | A | 10.0.1.67 |
| api-gateway | A | 10.0.1.102 |
When the zone is processed:
- Parascope creates a
dns.zoneCI namedexample.comwith all records stored - The enrichment engine iterates through the three A records
- For
app-server-01(IP10.0.1.60), it finds aproxmox.nodeCI with that IP and adds FQDNapp-server-01.example.com - For
worker-node-01(IP10.0.1.67), it finds akubernetes.nodeCI and adds FQDNworker-node-01.example.com - For
api-gateway(IP10.0.1.102), it finds the API service CI and adds FQDNapi-gateway.example.com
After enrichment, searching for app-server-01.example.com immediately returns the Proxmox node CI -- even though the Proxmox collector itself had no knowledge of DNS naming.
Related Documentation
- Correlation Engine -- Discovers relationships between CIs from different sources
- Infrastructure Lineage -- Traces full infrastructure stacks with inherited FQDN attributes
- Managing Collectors -- Configure and monitor the DNS collector
- Searching CIs -- Full-text search and filter syntax
- API Reference -- Complete endpoint documentation