Bug 50386 - S4-Connector removes SOA in Samba/AD when dns/host_record with name @ is deleted in UDM
S4-Connector removes SOA in Samba/AD when dns/host_record with name @ is dele...
Status: NEW
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: Samba maintainers
Samba maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-10-17 17:26 CEST by Arvid Requate
Modified: 2022-12-20 09:58 CET (History)
3 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 4: A User would return the product
User Pain: 0.137
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): bitesize
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2019-10-17 17:26:10 CEST
+++ This bug was initially created as a clone of Bug #50385 +++

I saw two cases, one in-house and one customer where an Administrator created a host record named @ in some forward_zone, triggering a chain of actions that finally led to a full DNS blackout for that forward_zone. Here is how:

The Admin opens the DNS module in UMC, clicks on the zone and add a host record with name @. The attached screenshot shows the result in the UMC DNS treeview: It lokks as if the zone has been duplicated as a child of itself.

In named/bind9 terms, the Admin has just written a second resource record named @ into his zone file. The UMC should not allow this.

Since UMC/UDM currenlty allow this, the Admin is now in a very dangerous situation:

With a high probability, the Admin right-clicks the unwanted object and deletes it. If Samba/AD is installed in the domain, then the S4-Connector interprets this as the removal of an SOA record and removes the SOA record of that zone in Samba/AD. That's silent and nobody notices until the nameserver services (bind9) gets restarted at some point in the future and the nameserver doesn't recognize the zone as valid any longer and the customer experiences severe DNS issues for the entire domain.
Comment 1 Arvid Requate univentionstaff 2019-10-17 17:26:45 CEST
The S4-Connector should not mistake a host_record removal for an SOA-record removal.