Hang on. I don't think there is any prohibition on hostnames with underscores. There is a prohibition for *A Records* with underscores, but the character remains valid for use in other record types.

A *hostname* of foo_1.bar.com is legal. It just can't be defined in a zone file as: foo_1.bar.com. A 10.11.12.13

but it could be defined as: foo_1.bar.com. CNAME baz.bar.com. baz.bar.com. A 10.11.12.13

To a resolving client, the end result is the same (a name gets turned into an address).

And I sure hope xymon would correctly handle a line in hosts.cfg 0.0.0.0 foo_1.bar.com #

-- Do things because you should, not just because you can.

John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska

On 8/5/2019 1:21 PM, Richard L. Hamilton wrote:

Seems to me that underscore is mainly a problem with address 0.0.0.0 in hosts.cfg (name to IP address resolution via host naming services, esp. if that ends up being DNS). If an IP address in hosts.cfg is used, and the hostname there isn't used in some other way, I don't guess it would matter.

Either a reminder in documentation (including in the hosts.cfg.5.html file) or a check and warning in case a name with underscore was used with non hosts.cfg resolution would probably keep people out of trouble; although underscores are wrong, they're widely tolerated in non-DNS hostnames, so I can see allowing them when they wouldn't cause further problems.

Guys and gals

The restriction on underscores is:

• for DNS - and may not apply to other naming systems (eg NIS, LDAP, NetBIOS)
• for hostnames - which has a specific meaning in the DNS standards

We shouldn't assume that a name in /etc/hosts or /etc/xymon/hosts.cfg is a hostname in a *DNS* sense. A name that's invalid in a DNS record might still be valid in /etc/hosts or /etc/hostname or wherever. I'm not arguing for a proposal to allow carte blanche, just to not be too restrictive due to our bias towards what we use ourselves (ie, DNS, and mostly DNS hostnames).

A DNS hostname is often associated with an "A" record, but not necessarily. The "hostname" part of a FQDN is *the name of a host*. This seems obvious, but it has (perhaps non-obvious) implications:

1. It's possible to have DNS domain names that are not hostnames. For example www.example.com is often a *service* name, that may also happen to be the name of a host that runs a webserver, but it might not be a hostname at all. If it's a DNS hostname, then it cannot contain underscores; if it isn't a hostname, then it technically is permitted to contain underscores. When Microsoft developed Active Directory, it intentionally used underscores in *service* names (eg _ldap._tcp.example.com, _sip._ udp.example.com) because they could not legally be used as hostnames, thus ensuring there would be no name collisions with existing hostnames. (Such records are type SRV, in case anyone wants to look it up.)

2. DNS records that refer to hostnames cannot use underscores in the hostname part. For example, MX (mail exchange) records are required to point to hostnames, and so the right-hand-side of an MX record can not have underscores. The same probably applies to NS records. The same applies to CNAME records that refer to A records on the RHS. CNAMEs aren't always pointing at A records (eg one can have a CNAME point to a TXT record), but when they are, the RHS would not be compliant with an underscore.

That's a bit of a tangent, but it gives a bit more context, to help illustrate where underscores may or may not be used. In essence, there are a few situations where underscores are not permitted in DNS records, but there are plenty of places where they are.

In conclusion, I think we shouldn't be mandating hosts.cfg comply with *DNS* naming standards, and furthermore we shouldn't assume an entry in hosts.cfg is a hostname (vs a service name). However, I believe we should be cautious about what we permit within hosts.cfg (and other sources) to avoid triggering bugs and edge cases.

We should also consider the source if the hostname string. If we receive a string from within hosts.cfg, we should allow the sysadmin to shoot themself in the foot, if they feel they need to, because we can't predict their needs (although we probably want to detect and report obvious typos). On the other hand, if we receive a hostname string from a Xymon client or Xymon proxy, we should be cautious.

Johns's run-around with the CNAME-to-A chain works for an underscore in the CNAME label, at least in BIND DNS. But that doesn't mean it's standards-compliant, nor does it mean it will work with all DNS software. TBH I don't know enough to say that it's not compliant, because it's complicated. BIND will warn about all sorts of semantic problems in a zone, but many of them are accepted-with-warnings, and many others can be accepted by configuration options. RFC2181 specifically says that DNS servers should not refuse to serve a zone based on the make-up of labels in the zone. [https://tools.ietf.org/html/rfc2181#section-11]

In hosts.cfg, we're not necessarily using DNS names, so we should not force the sysadmin to use DNS-compatible names.

Cheers Jeremy

On Tue, 6 Aug 2019 at 08:52, Richard L. Hamilton <rlhamil2 at gmail.com> wrote:

You're probably right...but that's just sick, using a CNAME to make an end run around the A record restriction. :-)

...

On Aug 5, 2019, at 17:38, John Thurston <john.thurston at alaska.gov> wrote:

Hang on. I don't think there is any prohibition on hostnames with underscores. There is a prohibition for *A Records* with underscores, but the character remains valid for use in other record types.

A *hostname* of foo_1.bar.com is legal. It just can't be defined in a zone file as: foo_1.bar.com. A 10.11.12.13

but it could be defined as: foo_1.bar.com. CNAME baz.bar.com. baz.bar.com. A 10.11.12.13

To a resolving client, the end result is the same (a name gets turned into an address).

And I sure hope xymon would correctly handle a line in hosts.cfg 0.0.0.0 foo_1.bar.com #

-- Do things because you should, not just because you can.

John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska

On 8/5/2019 1:21 PM, Richard L. Hamilton wrote:

...

Seems to me that underscore is mainly a problem with address 0.0.0.0 in hosts.cfg (name to IP address resolution via host naming services, esp. if that ends up being DNS). If an IP address in hosts.cfg is used, and the hostname there isn't used in some other way, I don't guess it would matter. Either a reminder in documentation (including in the hosts.cfg.5.html file) or a check and warning in case a name with underscore was used with non hosts.cfg resolution would probably keep people out of trouble; although underscores are wrong, they're widely tolerated in non-DNS hostnames, so I can see allowing them when they wouldn't cause further problems.

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

On Mon, 2019-08-05 at 13:26 -0700, Japheth Cleaver wrote:

Thanks, this does indeed fix the issue. I've added in underscores (which have been valid for hostnames in xymon, though not in reality) to match the checks elsewhere. Would appreciate if others could confirm on this.

Fix/patch is committed in https://sourceforge.net/p/xymon/code/8072/ ; 4.3.30 with this to come shortly.

Sorry - stealing the subject - could I ask to hold fire with 4.3.30 for a little while. There still seems to be a problem with graph titles when using 'exec:'. I'm just trying to track it down now (looks like an extra double-quote has crept in somewhere). Thanks.

John.

-- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK

[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>

This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.