Bug Report: Underscore in CNAME Record Name Treated as Invalid DNS Hostname

[erfanian7]

Versions

NetBox Version: 4.1.4
NetBox DNS Version: 1.1.5
Python Version: 3.12.3

Describe the bug

While attempting to create a CNAME record with an underscore in the name, such as _test.example.com, the following error was encountered:
'_test.example.com is not a valid DNS host name'

This indicates that the plugin validates the CNAME record's owner name based on the hostname convention, disallowing underscores. However, per RFC 1034, Section 3.6, underscores are allowed in the context of DNS names, including for CNAME record owners.

Expected Behavior
The owner name of a CNAME record should not be validated strictly as a hostname, as underscores are permissible in DNS names. For example:

_test.example.com should be treated as a valid owner name.
According to RFC 1034, Section 3.6:

Owner: "The domain name where the RR is found." This encompasses any valid domain name, not just a hostname.
RDATA for CNAME: "A domain name," which does not prohibit the use of underscores.

It is easy to test with named-checkzone.
You can find more information at this link.
https://serverfault.com/questions/834679/is-underscore-illegal-in-a-cname-record

Observed Behavior
The plugin enforces hostname rules for CNAME owner names, leading to rejection of valid use cases, such as _test.example.com.

To Reproduce

Steps to reproduce the behavior:
1.Navigate to the DNS plugin in NetBox.
2. Attempt to add a CNAME record with _test.example.com as the owner name.
3. Observe the error message: _test.example.com is not a valid DNS host name.

Impact

This limitation prevents the creation of valid CNAME records for use cases such as:

DKIM (_domainkey subdomains).
Service discovery (_service._protocol subdomains.

Suggested Resolution

Update the plugin's validation logic to:

Differentiate between hostnames and DNS names when validating the owner field.
Allow underscores (_) in DNS names for CNAME records, in line with RFC 1034 and RFC 2181.

[kollross]

https://github.com/peteeckel/netbox-plugin-dns/blob/main/docs/using_netbox_dns.md

The settings can be set or overridden in the file /opt/netbox/netbox/netbox/configuration.py by defining new values in PLUGINS_CONFIG as follows:

PLUGINS_CONFIG = {
    'netbox_dns': {
        ...
        'tolerate_underscores_in_labels': True,
        'tolerate_characters_in_zone_labels': "/",
        'tolerate_leading_underscore_types': ["TXT", "SRV", "TLSA", "CNAME"]
        'tolerate_non_rfc1035_types': ["X25"]
    },
}

[peteeckel]

@erfanian: Thanks for reporting this. I'll look into the RFCs in detail shortly and if your findings are correct (named-checkzone is a strong indication that they are) I'll update the validation code accordingly.

Meanwhile you can use the workaround provided by @kollross so you can continue working.

[peteeckel]

When you work through the RFCs you'll find some very interesting things that don't exactly make the approach to validating DNS names more obvious - this is a good example for it.

It's well known that there are apparently conflicting definitions in the RFCs. While RFC 1035 is quite restrictive at first sight, there's also RFC2181 that basically says "anything is possible", but then delegates responsibility for the decision what is a valid owner or value to the user of the records.

In some cases this can also have strange effects. When you use named-checkzone as an indication, you can construct the following example:

test1._schroedinger.example.com    IN    A        10.0.0.1
test2._schroedinger.example.com    IN    CNAME    test1._schroedinger.example.com

At first sight, this seems inconspicuous.

Then you'll notice that according to named-checkzone the first name is invalid, while the second one is valid. The invalid part is, however, in the name of the (sub)domain, not in the name itself - so the domain name is both valid and invalid, depending on what type of records you add. That doesn't really make it easier to create a sensible validator for DNS record and zone names ...

As a first solution that will cover the use case you mentioned (leading undescore in CNAME owner) I will add CNAME and DNAME to the list of record types that allow leading underscores in their owner name. In the longer run, I'll look into the validation issue again from scratch and see if I can come up with a more generic approach.

[erfanian7]

Thank you very much for your prompt response and suggested solution.