[Xymon] Hostname validation (was Re: Xymon 4.3.29 Released - Important Security Update)

[Jeremy Laidman]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20190806/90715972/attachment.htm>