Parascope Docs

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.

Loading diagram...

The enricher performs four steps for each A or AAAA record in the zone:

  1. Construct the FQDN from the record name and zone name (e.g., web-01 in zone prod.company.com becomes web-01.prod.company.com)
  2. Query the database for active CIs whose ip_addresses field contains the record's IP value
  3. Add the FQDN to each matching CI's fqdns list, skipping duplicates
  4. Record provenance in the CI's fqdn_sources field, 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 TypeProtocolZone DiscoveryConfiguration
CoreDNSZone transfer (AXFR)Explicit zone list requiredDNS_SERVER, DNS_PORT, DNS_ZONES
BINDZone transfer (AXFR)Explicit zone list requiredDNS_SERVER, DNS_PORT, DNS_ZONES
Route53AWS boto3 SDKAuto-discovers all hosted zonesAWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION
InfobloxWAPI REST APIAuto-discovers all authoritative zonesINFOBLOX_URL, INFOBLOX_USERNAME, INFOBLOX_PASSWORD
Active DirectoryLDAPAuto-discovers AD-integrated zonesAD_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.

FieldTypeDescriptionExample
hostnameslist of stringsShort names without domain suffix["web-prod-01", "api-gateway"]
fqdnslist of stringsFully qualified domain names["web-prod-01.prod.company.com"]
fqdn_sourcesobjectProvenance metadata keyed by FQDNSee 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 TypeMeaningTypical Source
explicitSet directly by a collector from the source system's own dataKubernetes node addresses, Netbox device custom fields
derivedComputed by a handler from other fields on the same CIPod DNS from namespace and pod name, service cluster DNS
correlatedAdded by the DNS enrichment pipeline from zone recordsA/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.

SourceCI TypeExtraction LogicProvenance
Kuberneteskubernetes.podHostname from spec.hostname; FQDN from {hostname}.{subdomain}.{namespace}.svc.cluster.local if subdomain is setexplicit / derived
Kuberneteskubernetes.serviceName as hostname; FQDN as {name}.{namespace}.svc.cluster.localexplicit / derived
Kuberneteskubernetes.nodeHostnames from InternalDNS and ExternalDNS address types in status.addressesexplicit
Proxmoxproxmox.vm, proxmox.containerHostname from config; FQDN from {hostname}.{searchdomain} when search domain is configuredexplicit / derived
OpenStackopenstack.instanceHostname from metadata.hostname or instance name; FQDN from {name}.{metadata.domain} if domain metadata is presentexplicit / derived
Netboxnetbox.deviceFQDNs from custom fields: fqdn, hostname_fqdn, or dns_nameexplicit
Cephceph.hostIf hostname contains dots, the short hostname is extracted as the hostname and the full value kept as FQDNexplicit

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.

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 domain

Filter 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:

  1. An alert fires referencing db-primary.prod.company.com
  2. Search Parascope for that FQDN
  3. The search returns the matching CI (e.g., a proxmox.vm named db-primary)
  4. Open the CI detail page to see its full context: relationships, lineage, change history
  5. 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, or correlated
  • source -- for correlated FQDNs, the dns.zone CI 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 NameTypeValue
app-server-01A10.0.1.60
worker-node-01A10.0.1.67
api-gatewayA10.0.1.102

When the zone is processed:

  1. Parascope creates a dns.zone CI named example.com with all records stored
  2. The enrichment engine iterates through the three A records
  3. For app-server-01 (IP 10.0.1.60), it finds a proxmox.node CI with that IP and adds FQDN app-server-01.example.com
  4. For worker-node-01 (IP 10.0.1.67), it finds a kubernetes.node CI and adds FQDN worker-node-01.example.com
  5. For api-gateway (IP 10.0.1.102), it finds the API service CI and adds FQDN api-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.