Bug 1219920

That would be this message:

https://github.com/yast/yast-yast2/blob/master/library/types/src/modules/Hostname.rb#L55-L57

which AFAICS checks against those characters:

https://github.com/yast/yast-yast2/blob/master/library/types/src/modules/Hostname.rb#L44-L45

i.e.  [0-9a-zA-Z-], not including the underscore.

Be advised that this yast2-dns-server module is on its way out; it's still supported in SLE-15 / Leap 15.x, and there will be a SLE-15-SP6 and consequently also a Leap 15.6, but for Tumbleweed and for future products this is already dropped.

https://github.com/yast/yast-dns-server/blob/master/README.md

Having said that, it still has considerable life in it; SLE-15 will be around for a while. I am not sure, but it is entirely possible that there will be an SP7, which probably means a Leap 15.7 as well.

Michal, Knut, how about it? Can we / should we / do we need to add the underscore '_' as a valid character here as well?

Is it really just that one line (and the message text, of course), or does it have wider implications?

(In reply to Stefan Hundhammer from comment #3)
> Michal, Knut, how about it? Can we / should we / do we need to add the
> underscore '_' as a valid character here as well?
> 
> Is it really just that one line (and the message text, of course), or does
> it have wider implications?

As it sounds, it would be nice to have. Reasoning is described in rfc6376. Basically it allows to define an organization responsibility for messages, ... So, we can expect that big providers will want to use it (as already stated in the description e.g. for google

Problem is that if we want to implement validation according to the rfc, it will become more complex (underscore can be placed only at particular place, ....)

So, we can either go
1) stupid way - just allow '_' to pass domain validation. But it will also allow creating records like "goo_gle.com" which are invalid, or
2) invest little bit more into the validation, and do it according to the rfc. It means, that underscore is valid for a particular DNS record type, can be located only in subdomain (valid: brisbane._domainkey.example.com) but not everywhere (invalid: example.c_m)

So 1 or 2? Should be decided and planned for it.

It will depend in how many places this validation is actually needed.

If it's only for this yast2-dns-server, we need to consider that it's already dropped for Factory / Tumbleweed and future products, supported only for the remaining life time of SLE-15 SPx and Leap 15.x. Since during all the time until just now nobody asked for this, it can't be that important, so we probably shouldn't invest too much into it.

If we also need it for many other networking-related YaST modules, that's different; but only if it's about creating NEW domain names, not connect to an existing one. If you need to use an existing domain with such a name, you don't have much choice. But if you are creating a new one, that's different.

(In reply to Stefan Hundhammer from comment #5)
> It will depend in how many places this validation is actually needed.
> 
> If it's only for this yast2-dns-server, we need to consider that it's
> already dropped for Factory / Tumbleweed and future products, supported only
> for the remaining life time of SLE-15 SPx and Leap 15.x. 

yes, depends on PMs how much do we want to bring "new" features into those products. However, they are still going to be here with us for 10 years or so.

> Since during all
> the time until just now nobody asked for this, it can't be that important,
> so we probably shouldn't invest too much into it.

well ... nobody asked for that bcs there still were "less secure ways" how to configure your system available. Might be that huge players are stripping these ways off. (i don't know just guessing)
> 
> If we also need it for many other networking-related YaST modules, that's
> different; but only if it's about creating NEW domain names, not connect to
> an existing one. If you need to use an existing domain with such a name, you
> don't have much choice. But if you are creating a new one, that's different.

hostname validation is part of core library (yast2.rpm) and hostname validation is used at several places. However, DNS records are validated at one place only (AFAIK; and this is a change for particular DNS records not generic domains) - the dns server module. So, it should be an additional check in dns module only (if hostname validation fails, just check if it is valid '_' scenario or not) - no big deal at first view in my POV. 

But as usual, we have priorities in Agama now, so someone has to decide how much is needed and plan for this.

We just discussed this, and we agreed to simply be more permissive with the allowed characters in hostnames in general, adding the '_' underscore for them all.

Fix for SLE-15-SP5 / Leap 15.5:

  https://github.com/yast/yast-yast2/pull/1301

This will become available with yast2-4.5.26.

IBS submit request (SUSE-internal):

  https://build.suse.de/request/show/321665

Notice that yast2-dns-server remains unchanged since the check is in that more generic part.


If you would like to do an advance test, download the changed file

https://raw.githubusercontent.com/yast/yast-yast2/SLE-15-SP5/library/types/src/modules/Hostname.rb

and copy it to your /usr/share/YaST2/modules directory.

Merge PR for SLE-15-SP6:

https://github.com/yast/yast-yast2/pull/1302


Merge PR for master / Factory / Tumbleweed:

https://github.com/yast/yast-yast2/pull/1303

SUSE-RU-2024:0865-1: An update that has one fix can now be installed.

Category: recommended (moderate)
Bug References: 1219920
Sources used:
openSUSE Leap 15.5 (src): yast2-4.5.26-150500.3.3.2
SUSE Linux Enterprise Micro 5.5 (src): yast2-4.5.26-150500.3.3.2
Basesystem Module 15-SP5 (src): yast2-4.5.26-150500.3.3.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.