Bug 28363 - Zonetransfer nach 3.0 Update nicht mehr möglich "unexpected rcode (SERVFAIL)"
Zonetransfer nach 3.0 Update nicht mehr möglich "unexpected rcode (SERVFAIL)"
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: DNS
UCS 3.0
Other Linux
: P5 normal (vote)
: UCS 4.1-4-errata
Assigned To: Philipp Hahn
Florian Best
:
: 32991 33707 40497 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-29 13:08 CEST by Janis Meybohm
Modified: 2017-01-05 11:22 CET (History)
7 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 3: A User would likely not purchase the product
User Pain: 0.171
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
Script zum finden (und korrigieren) von DNS-Zonen mit falscher Syntax (3.94 KB, text/x-python)
2012-09-04 13:37 CEST, Janis Meybohm
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Janis Meybohm univentionstaff 2012-08-29 13:08:16 CEST
+++ This bug was initially created as a clone of Bug #23945 +++
Ticket#: 2012082921000871

Das ist bei einem Kunden nach dem 3.0 Update aufgefallen. Diverse reverse und eine forward Zone hatten Nameserver ohne abschließenden Punkt im SOA Record stehen. Das führt dann mehr oder weniger unbemerkt dazu das der Zonetransfer "irgendwann" nicht mehr funktioniert (im konkreten Fall ca. eine Woche nach dem Update).

Korrigieren der Zonen hilft sofort.


Ich denke das könnte man ggf. im Update oder in den Release-Notes mit einem Script abfangen dass die Punkte ergänzt denn anscheinend war es pre 3.0 mal möglich die Einträge ohne abschließenden Punkt über den UDM einzupflegen.
Comment 1 Janis Meybohm univentionstaff 2012-09-04 13:37:03 CEST
Created attachment 4637 [details]
Script zum finden (und korrigieren) von DNS-Zonen mit falscher Syntax
Comment 2 Janis Meybohm univentionstaff 2013-06-04 07:38:04 CEST
Erneut berichtet: Ticket#: 2013052821001188
Sowie im Forum: <http://forum.univention.de/viewtopic.php?f=48&t=2678>
Comment 3 Kevin Dominik Korte univentionstaff 2013-11-11 15:26:00 CET
*** Bug 32991 has been marked as a duplicate of this bug. ***
Comment 4 Jan Christoph Ebersbach univentionstaff 2013-11-18 09:47:17 CET
Also reported by another customer.
Comment 5 Ingo Steuwer univentionstaff 2013-12-10 13:57:08 CET
Bug #33707 describes a similar situation where BIND doesn't start anymore.
Comment 6 Arvid Requate univentionstaff 2013-12-10 19:06:49 CET
See also Bug 25354 and Bug 28367.
Comment 7 Philipp Hahn univentionstaff 2015-07-20 15:35:59 CEST
BIND also fails to serve a zone, when a (no longer existing) DNS server is still mentioned in the SOA record.

 /var/log/daemon.log
 Jul 20 14:54:24 proxy41 named[3803]: zone phahn.pt/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#7777 (source 0.0.0.0#0)

1. We should validate that the SOA-RR only references known hosts.
2. If a DC is deleted, it must be removed from any SOA-RR as well.
Comment 8 Philipp Hahn univentionstaff 2016-01-26 08:36:09 CET
*** Bug 33707 has been marked as a duplicate of this bug. ***
Comment 9 Philipp Hahn univentionstaff 2016-01-26 08:37:48 CET
*** Bug 40497 has been marked as a duplicate of this bug. ***
Comment 10 Philipp Hahn univentionstaff 2016-02-22 11:05:09 CET
AGAIN!

Can we please get this fixed?
Or at least write a diagnostic module to detect that error?
Comment 11 Philipp Hahn univentionstaff 2016-07-18 13:09:51 CEST
Ticket#2016071421000581: According to <https://tools.ietf.org/html/rfc1035#section-3.3.11> an NS-RR requires an NSDNAME, which is a "domain-*name*"; an IPv4 adress is not allowed, so the used syntax class "dnsName" is too lenient:

handlers/dns/forward_zone.py:
144 »···'nameserver': univention.admin.property(
147 »···»···»···syntax=univention.admin.syntax.dnsName,

syntax.py:
1263 class dnsName(simple):
1264 »···_re = re.compile('^[a-zA-Z0-9][a-zA-Z0-9._-]*[a-zA-Z0-9.]$')
Comment 12 Philipp Hahn univentionstaff 2016-11-21 10:57:56 CET
r74604 | Bug #25354 udm: Validate DNS domain name syntax (UCS-4.2)
r74623 | Bug #25354 udm: Validate DNS domain name syntax (UCS-4.1-4)
 DNS labels are now checked

Package: univention-directory-manager-modules
Version: 11.0.3-46.1440.201611211050
Branch: ucs_4.1-0
Scope: errata4.1-4

r74624 | Bug #25354 udm: Validate DNS domain name syntax YAML
 univention-directory-manager-modules.yaml

QA: FYI
1. For DNS servers the more strict syntax check now prevents entering IP addresses. A missing trailing dot is automatically appended by some UDM magic.
2. For MX records the trailing dot is *not* automatically appended, so the zone name gets appended if no explicit trailing dot is entered. I did not change that logic, so it remains broken. We really need an extension for UMC to show a warning: Bug #42904
3. I did not add the script to detect or correct wrong entries as no customer reported the bug again. Support knows how to fix that. IMHO its enough to prevent entering new broken entries.
Comment 13 Florian Best univentionstaff 2016-12-21 16:50:24 CET
(In reply to Philipp Hahn from comment #12)
> QA: FYI
> 1. For DNS servers the more strict syntax check now prevents entering IP
> addresses. A missing trailing dot is automatically appended by some UDM
> magic.
OK, simpleComputer appends the dot automatically. Everywhere else where no trailing dot must be written to ldap it is stripped in the mapping.

> 2. For MX records the trailing dot is *not* automatically appended, so the
> zone name gets appended if no explicit trailing dot is entered. I did not
> change that logic, so it remains broken. We really need an extension for UMC
> to show a warning: Bug #42904
Okay

> 3. I did not add the script to detect or correct wrong entries as no
> customer reported the bug again. Support knows how to fix that. IMHO its
> enough to prevent entering new broken entries.
Yes

OK: YAML
Comment 14 Janek Walkenhorst univentionstaff 2017-01-05 11:22:35 CET
<http://errata.software-univention.de/ucs/4.1/367.html>