Bug 1088559 - Yast DNS Server module will convert upper-case to lower-case for TXT records
Yast DNS Server module will convert upper-case to lower-case for TXT records
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
x86-64 Linux
: P3 - Medium : Normal (vote)
: ---
Assigned To: YaST Team
Jiri Srain
Depends on:
  Show dependency treegraph
Reported: 2018-04-07 16:21 UTC by Steve John
Modified: 2019-02-28 07:14 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

save_y2logs (9.23 MB, application/x-compressed-tar)
2018-04-10 15:43 UTC, Steve John
Just added the record, shows upper case (25.01 KB, image/png)
2018-04-10 15:44 UTC, Steve John
Just after saving and reloading the zone. No upper case (22.15 KB, image/png)
2018-04-10 15:45 UTC, Steve John

Note You need to log in before you can comment on or make changes to this bug.
Description Steve John 2018-04-07 16:21:53 UTC
Trying to support email dkim record in yast dns server module fails.

I am using iredmail for a mail server.
iredmail generates dkim keys using amavisd-new genrsa ...

The key is mixed case. Letters A-Z and a-z are valid along with numbers and symbols.

When I create the TXT record in yast it looks correct. However on saving by exiting yast dns server module, it is converted to lowercase. This breaks dkim for iredmail.

When I manually edit the dns record with a text editor in /var/lib/named/master
and restart named it works and is valid.

Then open the dns zone in yast dns server module and the TXT record is lower-case.

If you save this zone again, dkim will be broken and email will fail the check.

To summarize: Yast dns server module does 2 conversions to lower-case. On read and on write of the zone. Both will break dkim support.
Comment 1 Josef Reidinger 2018-04-10 13:08:56 UTC
Can you please attach yast logs ( output of save_y2logs )? I try to check it in code but at first look it looks like we use only lowercase for record type and not on its value.

Comment 2 Steve John 2018-04-10 15:43:02 UTC
Created attachment 766617 [details]

I will also attach 2 screen captures.
1 - right after adding the dkim record showing upper case
2 - right after saving and reloading the zone showing no upper case
Comment 3 Steve John 2018-04-10 15:44:14 UTC
Created attachment 766618 [details]
Just added the record, shows upper case
Comment 4 Steve John 2018-04-10 15:45:15 UTC
Created attachment 766619 [details]
Just after saving and reloading the zone. No upper case
Comment 5 Josef Reidinger 2018-04-12 13:26:09 UTC
Thanks for logs. I check it and see nothing obvious, so it need some time to debug it and reproduce.
Comment 6 Josef Reidinger 2018-04-12 14:29:06 UTC
OK, so how it looks so far:

- I reproduce it ( good )

- I run it with additional logging which proves that it goes from perl part correct, but gets into UI invalid. So bug is somewhere in middle.

- so I will continue with more debugging
Comment 7 Steve John 2018-04-12 14:32:15 UTC
That is great news.
Thanks for working on it.
Comment 8 Josef Reidinger 2018-04-13 07:22:03 UTC
interesting part. I try random upper case string "MUJ STRING" and it kept uppercase, so maybe related to = or ; char. I will try to find what exactly cause it.
Comment 9 Josef Reidinger 2018-04-13 07:34:58 UTC
hmmm. I cannot reproduce it at all on my home Leap15, only at work with TW. That is quite strange as yast package is identical. So maybe something changed in bind? I would have to continue testing on that TW.
Comment 10 Steve John 2018-04-13 14:39:14 UTC
Interesting about Leap15.

On my Tumbleweed system even a TXT record with a value of UPPER gets saved as upper when I look at the zone file in /var/lib/named/master. No funny characters involved.

I wouldn't think that bind would alter the zone file, just read it. Only a guess on my part.
Comment 11 Steffen Winterfeldt 2018-04-24 11:50:11 UTC
Tracking in YaST scrum board.
Comment 12 Steve John 2019-02-27 21:11:35 UTC
Any news on this? it has been almost a year.
Comment 13 Josef Reidinger 2019-02-28 07:14:13 UTC
(In reply to Steve John from comment #12)
> Any news on this? it has been almost a year.
> Thanks

Sadly no, too many other bugs and also many with higher priority.