Bugzilla – Bug 1219920
openSUSE Leap 15.5, YaST DNS Server Configuration, DomainKey and Underscore Problems
Last modified: 2024-03-13 12:30:08 UTC
Recently upgraded to openSUSE Leap 15.5 (with all updates applied) and came across a problem using YaST DNS Server Configuration tool. With Google on the verge of requiring SPF, DKIM, DMARC DNS changes, lest your outgoing mail not being delivered, I suspect this should be addressed quickly. I am attempting to add a CNAME record with the following information: Type: CNAME Name: selector1._domainkey Value: selector1-domain-com._domainkey.domain.onmicrosoft.com. When submitted, I get the following error: A valid domain name consists of components separated by dots. Each component contains letters, digits, and hyphens. A hyphen may not start or end a component and the last component may not begin with a digit. Through testing, I’ve found that is is complaining about the underscore character, '_', that the domain key requires. The problem is that Microsoft, Amazon SES, SendGrid, Constant Contact, HappyFox, etc require folks to enter CNAME records containing the underscore character, '_', within your DNS. This isn’t currently possible within the YaST DNS Server Configuration tool. With the tidal wave of Google SPF, DKIM, DMARC DNS changes that must be made before April 1 to ensure that your mail is delivered, this is a major issue. For example, if you use Microsoft Office/Microsoft 365, you will have to make the following change to your DNS which are currently impossible from within the YaST DNS Server Configuration tool. https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dkim-configure?view=o365-worldwide#syntax-for-dkim-cname-records
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.