Best Practices where to store Domain Names

[Holger Buchner]

Dear Community,

we are currently discussing, how and on which CI classes to document Domain Names. We want to cover the following:

• Self hosted infrastructure (servers (virtual & physical), loadbalancers,
• Self hosted endpoints (https, tcp) if not covered by the before (http servers, database instances)
• Hyper scaler deployed endpoints (web application gateways, loadbalancers, application services, servers, database instances, docker instances
• SaaS services and their endpoints provided by other third party providers (e.g. ServiceNow, SAP, Salesforce, Adobe)
• TLS certificates (at least some of them are issued for domain names and aliases (alternate domain names)

One option would be to store all domain names (in most cases identical with FDQN) in a separate class cmdb_ci_endpoint, but that would create a large volume plus maintaining 10,000th of relationships (hard to keep update).

Are there best practices to focus on some base classes (e.g. server (generic), database instance (generic), cloud service (generic)) or use one common class like mapped application service to store the domain names with the downside, that 1 to many relationships are difficult to document.

Benefit would be, that we could do a full-text search across the CMDB & APM to find out, which application belongs to what domain name.

Processes like internet domain name services (ICAN) for ownership, risk mitigation and renewals would be easy to handle, similarly the handling and renewal of internal issued TLS certificates.
Does anyone have a recommendation to use either a separate object with relationships or in case of using pre-defined CI classes a recommendation for a subset of classes where to store the domain names.
Any hint highly appreciated.

[CMDB Whisperer · Accepted solution]

This might help to put the picture together for you:

[rohtomar]

@CMDB Whisperer 

Hi Whisperer, If we are unable to capture FDQN field by discovery. Then what is the best practice to capture the FDQN field for cmdb class like IP router or ip switch. 

[CMDB Whisperer]

There is a FQDN field provided out-of-box for this on all CI classes.  Just use the one that is provided.  Yes, it is true that fqdn is not populated consistently across difference classes and device manufacturers.  Discoverability of attributes can be due to several factors due to inconsistencies in discovery patterns, credentials, or even limitations of the devices themselves.  If it is important to maintain a specific field that is not consistently discoverable, you can look into using CMDB Health to manage the completeness of that data.