Selective DNS-Editor problem when adding CNAME type records

[krajenski]

Hi there!

As the following issue is not affecting all our domains in the DNS editor, I post it here before filing a bug in github.
We have an two-parted issue with adding CNAME-records to DNS zones using the Froxlor DNS-Editor.
I have for example two DNS zones here, which behave very differently when adding CNAMES.

-> Please see attached two pictures as information basis

Case A:
Problem 1) When adding an "@" CNAME to this zone this happens: There already exists a resource-record with the same record-name. It can not be used as CNAME.
Problem 2) When adding an "www" CNAME entry to this zone this happens: The entry gets duplicated -> TWO "www" entries exist, and the zone is not loaded due to error. The "custom" enty is not respected in the usual manner: It should be replaced.

Case B:
- Both things simply work like a charm

Neither do I see what I am doing wrong, or in which way there are different that this may happen. I even had a look into 'domain_dns_entry' table, which did not reveal a conclusion for me here.
Froxlor Version: 0.10.21

Many thanks in advance,
Sebastian

 

 

[d00p]

Do the domains differ in terms of settings? Need to try to reproduce this

[krajenski]

I understand, sure, there you go:

-------------------------------------------------------
"Edit domain"-settings for Case "B" (the good case) are:
- No alias domain
- No subdomain of a full domain
- Allow editing: yes
- Next two fields: empty
- Documentroot: /var/customers/webs/msolutions/eicar.eu/
- IP: <IPV4>:80
- ServerAlias value: WWW
- SepLog: No
- Own V-Settings: Empty
- Apply special: yes
- Write an...: yes
- Write an...: yes
- SSL: yes
- SSL-IP: <IPv4>:443
- SSL redirect: off
- LetsEncrypt: yes
- Override...: no
- ProtVersions: TLS1.2 only
- Ciphers: our default string... ECDHE ... and so on
- Next two: empty
- Include non-ssl: Off
- HSTS: 0
- Include HSTS: off
- Include domain HSTS...: off
- OSCP: off
- Honor...: Off
- OpenBase: yes
- PHP enabled: yes
- PHP config: 7.3
- apply php-config to all: yes
- Next two: empty
- Nameserver: Yes
- Zonefile: empty field
- Emaildom: yes
- onlymail: off
- sub as email: Never

-> Additional info: This TLD is quite old an has been in the system for some year(s).

--------------------------------------------------------------------------------------
"Edit domain"-settings for Case "A" (the bad case) are:
- No alias domain
- No subdomain of a full domain
- Allow editing: yes
- Next two fields: empty
- Documentroot: /var/customers/webs/the/customer/dir
- IP: <IPV4>:80
- ServerAlias value: WWW
- SepLog: No
- Own V-Settings: Empty
- Apply special: yes
- Write an...: yes
- Write an...: yes

- SSL: NO (all subsequent SSL-fields empty or implicit default, no checkboxes checked)

- OpenBase: yes
- PHP enabled: yes
- PHP config: 7.3
- apply php-config to all: yes
- Next two: empty
- Nameserver: Yes
- Zonefile: empty field
- Emaildom: yes
- onlymail: off
- sub as email: Never

-> Additional info: This entry is only a few days old and rather newly in the system.
 

[krajenski]

Update: Now I was able to set the "@" CNAME-Record for my "case A", but not in a way that makes sense...
Being desperate, I experimented with deleting the "@ MX" Record (!), and after that, there was no "conflict" anymore and the end result looks like this.
I fortunately was able to do this in this productive case, because, luckily, the MX works also with the implicit default entry in this case, phew
(Some customers have MX-Records not on our server, where this move would not have been possible)

So some bug, after all 🙂

 

[krajenski]

Update #2: And it does not work really. The zone is generated, but not loaded.
Oct 23 13:44:26 server named[8798]: dns_master_load: /etc/bind/domains/domain.de.zone:8: domain.de: CNAME and other data
Oct 23 13:44:26 server named[8798]: zone domain.de/IN: loading from master file /etc/bind/domains/domain.de.zone failed: CNAME and other data

Maybe it is not possible to set a CNAME record for the TLD ("@") itself. Never needed this before. Will look further into it.

[krajenski]

Allright, I think I can sum this issue up to this misbehaviour of the DNS editor after all: Setting a CNAME record for "www" produces a duplicate entry in the zone, which leads to it not being loaded.
(The other "@" issues seems like some non-RFC-conformance thing).

 

[d00p]

okay, i will check that. Can you please open an issue on github with these infos?

[krajenski]

Sure, will do!

[d00p]

Fixed in git and will be in the next release 0.10.22 which will be published on 6th of november