[Xymon] Hostname validation

[Japheth Cleaver]

I recall this being a debate back in the 4.3.26 timeframe as well, when 
we were tightening restrictions, but I couldn't find any of the messages 
in the archive. Ultimately, I believe slashes were might have been being 
used by some folks, so I wanted to minimize disruption then. Hence in 
the 4.3.26 notes:

    Incoming test names are now restricted to alphanumeric characters,
    colons
    dashes, underscores, and slashes. Slashes and colons may be
    restricted in
    a future release.

    Unconfigured (ghost) host names are now restricted to alphanumerics,
    colons,
    commas, periods, dashes, and underscores. It is strongly recommended
    to use only
    valid hostnames and DNS components in servers names.


So DNS-safe domain components and Unix-safe hostnames would remain the 
suggestion going forward, but not enforced as such in 4.3.

-jc


On 8/5/2019 4:04 PM, Tom Schmidt (tschmidt) wrote:
> I did not mean for this to get into a debate.  The systems I am monitoring with Xymon do not have underscores in their hostnames but many have the hyphen.  When I queried my companies DNS server, a few CNAME records have underscores, but no A records have an underscore.  Xymon could monitor a system using a CNAME record, so IMHO it should still allow it for the reporting and history features.
>
>
> Tom Schmidt
> Sr Manager, IT, Product Engineering
> IT ETD Eng Sites US
> Micron Technology, Inc.
> Office: +1 (208) 368-4058  Fax: (208)368-2807
> Email: tschmidt at micron.com  Website: micron.com
> Micron Technology, Inc., Confidential and Proprietary.
>
>
> -----Original Message-----
> From: Xymon <xymon-bounces at xymon.com> On Behalf Of Axel Beckert
> Sent: Monday, August 5, 2019 3:48 PM
> To: xymon at xymon.com
> Subject: [EXT] Re: [Xymon] Hostname validation (was Re: Xymon 4.3.29 Released - Important Security Update)
>
> Hi,
>
> On Mon, Aug 05, 2019 at 05:21:33PM -0400, 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.
> Hmmm, indeed
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDomain_Name_System%23Domain_name_syntax%2C_internationalization&data=02%7C01%7Ctschmidt%40micron.com%7C7bdb890c737b4e9b908708d719eea31b%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C637006385051444790&sdata=Uo0pyo9e0AkeTihN9nPvLDW%2BizoaHNpp%2BCEuIFBkcVI%3D&reserved=0
> as well as RFC 608, 810 and 952 say that no other characters than letters, digits and hyphens are allowed.
>
> I'm though quite sure to already have seen hostnames with underscore and even a slash in the wild. The latter was though about 20 years ago or so where I saw router names of a university with a slash in their hostname.
>
> Traces of hostnames with slashes can also be found on the web, e.g.
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserverfault.com%2Fquestions%2F963735%2Fsyslog-ng-hostnames-with-slashes&data=02%7C01%7Ctschmidt%40micron.com%7C7bdb890c737b4e9b908708d719eea31b%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C637006385051444790&sdata=YCiH8mRaATsBxF8w9APxCcYMdi81zSz1tzD2JnhWkZY%3D&reserved=0
>
> And underscore is explicitly mentioned in
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHostname%23Restrictions_on_valid_hostnames&data=02%7C01%7Ctschmidt%40micron.com%7C7bdb890c737b4e9b908708d719eea31b%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C637006385051444790&sdata=2TieCKA%2F1VVIIEMVdm7A3hU5q2CDggPp0b2R%2B9iEzhE%3D&reserved=0
>
> So IMHO while not being standard-compliant hostnames, Xymon should accept at least hostnames with underscore, too.
>
> On the other hand, I don't think, it's necessary to also add the slash to the list of valid characters for hostnames as the dot is already in there, too, and hostnames which are allowed to contain "/../" are definitely no good. :-)
>
> 			Kind regards, Axel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20190805/9e39217f/attachment.htm>