Univention Bugzilla – Bug 28363
Zonetransfer nach 3.0 Update nicht mehr möglich "unexpected rcode (SERVFAIL)"
Last modified: 2017-01-05 11:22:35 CET
+++ 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.
Created attachment 4637 [details] Script zum finden (und korrigieren) von DNS-Zonen mit falscher Syntax
Erneut berichtet: Ticket#: 2013052821001188 Sowie im Forum: <http://forum.univention.de/viewtopic.php?f=48&t=2678>
*** Bug 32991 has been marked as a duplicate of this bug. ***
Also reported by another customer.
Bug #33707 describes a similar situation where BIND doesn't start anymore.
See also Bug 25354 and Bug 28367.
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.
*** Bug 33707 has been marked as a duplicate of this bug. ***
*** Bug 40497 has been marked as a duplicate of this bug. ***
AGAIN! Can we please get this fixed? Or at least write a diagnostic module to detect that error?
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.]$')
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.
(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
<http://errata.software-univention.de/ucs/4.1/367.html>