Designing DNS Record Documentation and Relationships in ServiceNow CMDB

[fabricebles]

Context
We are implementing an automated process for managing DNS records through ServiceNow.
Our automation uses PowerShell scripts via the MID Server to create or update DNS entries (A and CNAME records).
The results are then stored in ServiceNow, and we would like to properly document and link these DNS records within the CMDB data model.

Current Setup

We currently leverage the following tables:

• dns_record_a: Stores technical information about A records (hostname, IP address, TTL, zone, etc.)
• dns_record_cname: Stores CNAME alias mappings
• cmdb_ci_ip_address: Represents the IP address CIs linked to infrastructure (via cmdb_ci)

The PowerShell script inserts data into dns_record_a, and we have added a relationship (Depends on) between dns_record_a and cmdb_ci_ip_address to model the technical dependency:

dns_record_a → (Depends on) → cmdb_ci_ip_address → (Belongs to) → cmdb_ci

Observation
While the relationship entry in cmdb_rel_ci is created successfully and works for logical/flow-based processing, it does not appear in the Dependency View or other CMDB visualizations.

After inspecting the data model, it seems that:

• The dns_record_* tables do not extend cmdb_ci,
• Therefore, ServiceNow does not treat DNS records as Configuration Items (CIs),
• The ip_address field in dns_record_a is a string, not a reference to cmdb_ci_ip_address.

This makes it difficult to visualize or analyze DNS dependencies within the CMDB UI.

Goal
We would like to design a clean, CMDB-compliant way to document DNS records (especially A and CNAME records) and link them to IPs and related CIs.

Ideally, we want:

• DNS records to be visible in dependency maps / CI relationships
• A clear linkage between DNS name → IP → CI
• The model to stay compatible with Discovery, IPAM, and CSDM principle

I would be very thankful if someone could help me with this question:)

[Mathew Hillyard]

Hi @fabricebles 

From this link it seems the DNS records are CIs: https://www.servicenow.com/docs/bundle/zurich-servicenow-platform/page/product/configuration-managem...

I’ve confirmed this in my PDI. DNS Zone A Records and DNS Zone CNAME tables extend DNS Resource, which itself extends Configuration Item. They’re all installed as part of the CMDB CI Class Records application.

I hope this helps!

Mat

[fabricebles]

Hi Mat

Thank you very much for your reply:)

I have now activated the classes for DNS Zone A Record and DNS Zone CNAME Record in our instance and integrated them into the CMDB structure. The basic structure works well – the entries are now CIs and also appear cleanly in the Dependency View.

What I'm still interested in is:
In your opinion, what is the best way to model the relationships?

A Record → IP Address: I assume there is a "Depends on" relationship from cmdb_ci_dns_zone_a_record to cmdb_ci_ip_address, correct?

CNAME → Target host/A record: Would you also link to the A record or another CI with "Depends on" here?

If you have an example of this in your PDI or know whether ServiceNow uses certain relationship types or conventions, that would be extremely helpful!

Thank you again, this is really helping us move forward!
Fabrice

[Mathew Hillyard · Accepted solution]

Hi @fabricebles 

I don't believe Discovery will populate these attributes so you will have to define the necessary data model.

When I want to relate objects in the CMDB and I'm not sure, I always attempt to model the actual reality. Does a DNS A Record DEPEND on an IP Address? If so then yes, that's the right CI Relationship Type.

Typically we use Depends on::Used by for impact analysis (to trace upwards and understand service impact). DNS could have issues but it's not going to be reflected by these CIs as they're logical rather than actual - they won't notify if "down". So it probably doesn't matter all that much in terms of impact - but will matter that the relationships reflect reality. Looking at these tables, I think they're just designed for you to store the DNS information in, rather than to run a process or other logic - as you mentioned, the IP address in the DNS Zone A Record is a string and not a reference to the IP Address table.

I hope this helps!

Mat

[fabricebles]

Hi Mat

Thank you very much for your reply:)

I have now activated the classes for DNS Zone A Record and DNS Zone CNAME Record in our instance and integrated them into the CMDB structure. The basic structure works well – the entries are now CIs and also appear cleanly in the Dependency View.

What I'm still interested in is:
In your opinion, what is the best way to model the relationships?

A Record → IP Address: I assume there is a "Depends on" relationship from cmdb_ci_dns_zone_a_record to cmdb_ci_ip_address, correct?

CNAME → Target host/A record: Would you also link to the A record or another CI with "Depends on" here?

If you have an example of this in your PDI or know whether ServiceNow uses certain relationship types or conventions, that would be extremely helpful!

Thank you again, this is really helping us move forward!
Fabrice