DNS CNAMEs for services #3837

Closed
opened 2025-12-29 18:31:32 +01:00 by adam · 4 comments
Owner

Originally created by @garbled1 on GitHub (Jul 6, 2020).

Environment

  • Python version: 3.7
  • NetBox version: 2.8

Proposed Functionality

A Service should have a cname field, that lets you set an alternate name for that service.

Use Case

I can use netbox as a source of truth for my network, such as, create a service named "ZABBIX", and then use it inside ansible when configuring a VM. Connect to netbox, lookup the ZABBIX service, find the associated device, and configure the server to use that ip/name for it's zabbix server in the conf file.

However, it would also be nice if I had a cname for that service, like "zabbix.foo.com" instead of "machinename.foo.com" or ip. Then I don't have to rewrite the zabbix conf files on 100 machines if I move that service. I can do this manually, but there is no way to store this cname in netbox so I can look it up dynamically.

Database Changes

unknown

External Dependencies

n/a

Originally created by @garbled1 on GitHub (Jul 6, 2020). <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/forum/#!forum/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.7 * NetBox version: 2.8 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality A Service should have a cname field, that lets you set an alternate name for that service. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case I can use netbox as a source of truth for my network, such as, create a service named "ZABBIX", and then use it inside ansible when configuring a VM. Connect to netbox, lookup the ZABBIX service, find the associated device, and configure the server to use that ip/name for it's zabbix server in the conf file. However, it would also be nice if I had a cname for that service, like "zabbix.foo.com" instead of "machinename.foo.com" or ip. Then I don't have to rewrite the zabbix conf files on 100 machines if I move that service. I can do this manually, but there is no way to store this cname in netbox so I can look it up dynamically. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes unknown <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies n/a
adam closed this issue 2025-12-29 18:31:32 +01:00
Author
Owner

@jeremystretch commented on GitHub (Jul 10, 2020):

This sounds a bit redundant, since the corresponding CNAME for a service is likely to be the same as the service's name in many cases.

@jeremystretch commented on GitHub (Jul 10, 2020): This sounds a bit redundant, since the corresponding CNAME for a service is likely to be the same as the service's name in many cases.
Author
Owner

@garbled1 commented on GitHub (Jul 10, 2020):

That depends alot on the complexity of your network. A good example:

preprod_zabbix: CNAME = zabbix.uat.garbled.net
prod_zabbix: CNAME = zabbix.garbled.net

I mean, I guess I could just name the services zabbix.uat and zabbix, but what if the cname was zabbix.not_garbled.net ?

I dunno.. I guess I can work around it, I'm just saying it would be nice. At a certain point, if I have to name the service "zabbix.garbled.net", then there is basically no point in retrieving that from netbox as I've already hardcoded "zabbix.garbled.net" into my automation.

@garbled1 commented on GitHub (Jul 10, 2020): That depends alot on the complexity of your network. A good example: preprod_zabbix: CNAME = zabbix.uat.garbled.net prod_zabbix: CNAME = zabbix.garbled.net I mean, I guess I could just name the services zabbix.uat and zabbix, but what if the cname was zabbix.not_garbled.net ? I dunno.. I guess I can work around it, I'm just saying it would be nice. At a certain point, if I have to name the service "zabbix.garbled.net", then there is basically no point in retrieving that from netbox as I've already hardcoded "zabbix.garbled.net" into my automation.
Author
Owner

@steffann commented on GitHub (Jul 13, 2020):

I wrote a plugin some time ago which allows you to let NetBox automatically create DNS records using DNS Update messages. It allows for multiple hostnames attached to an IP address. Would that be something you can use?

@steffann commented on GitHub (Jul 13, 2020): I wrote a [plugin](https://github.com/sjm-steffann/netbox-ddns) some time ago which allows you to let NetBox automatically create DNS records using DNS Update messages. It allows for multiple hostnames attached to an IP address. Would that be something you can use?
Author
Owner

@jeremystretch commented on GitHub (Jul 13, 2020):

IMO the service record shouldn't have any statically-defined data that isn't directly tied to the service itself. If you include the FQDN as the CNAME record (as opposed to concatenating only the host portion with a domain portion sourced elsewhere), then you need to update all applicable service records in a non-trivial way should the domain change.

It just feels like this is pushing a bit into DNS management territory, which we've intentionally avoided for the sake of limiting scope. It's probably best to just use a custom field on the Service model for this particular use case.

@jeremystretch commented on GitHub (Jul 13, 2020): IMO the service record shouldn't have any statically-defined data that isn't directly tied to the service itself. If you include the FQDN as the CNAME record (as opposed to concatenating only the host portion with a domain portion sourced elsewhere), then you need to update all applicable service records in a non-trivial way should the domain change. It just feels like this is pushing a bit into DNS management territory, which we've intentionally avoided for the sake of limiting scope. It's probably best to just use a custom field on the Service model for this particular use case.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#3837