Bug 33707 – DNS with LDAP backend doesn't start if zone has incorrect nameserver

Bug 33707 - DNS with LDAP backend doesn't start if zone has incorrect nameserver


Summary:	DNS with LDAP backend doesn't start if zone has incorrect nameserver

Status:	RESOLVED DUPLICATE of bug 28363

Product:	UCS
Classification:	Unclassified
Component:	DNS
Version:	UCS 3.2
Hardware:	Other Linux

Importance:	P5 normal (vote)
Target Milestone:	UCS 3.2-x
Assigned To:	UCS maintainers
QA Contact:

URL:
Keywords:

Depends on:
Blocks:	40497
	Show dependency tree / graph

Reported:	2013-12-10 13:55 CET by Ingo Steuwer
Modified:	2018-04-13 13:32 CEST (History)
CC List:	2 users (show)

See Also:
What kind of report is it?:	---
What type of bug is this?:	---
Who will be affected by this bug?:	---
How will those affected feel about the bug?:	---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Ingo Steuwer

2013-12-10 13:55:53 CET

Reported by a customer, maybe related/duplicate to Bug #28363:

If the "nameserver"-entry of a zone contains a non existing FQDN (in the reported case the customer deleted the UDM object of a UCS DC and it's A-record), the zone transfer fails. Once BIND is stopped (maybe by logrotate) it doesn't start anymore until the wrong entry is removed.

Systems with Samba4 backend are working fine.

Comment 1 Philipp Hahn

2016-01-26 08:36:09 CET

BIND refuses to load/transfer a broken zone, e.g. a zone which has NS RRs which BIND can't resolve to an A/AAA address.
See <http://sdb.univention.de/content/20/254/en/bind-zone-transfer-failed.html>

*** This bug has been marked as a duplicate of bug 28363 ***