Univention Bugzilla – Bug 15687
UDM - IPv6 im Backend
Last modified: 2011-12-13 15:47:08 CET
Im Univention Directory Manager sollen die DNS - Einstellungen IPv6 unterstützen.
univention-directory-modules 5.1.2: * udm dns/host_record create und modify erstellen / bearbeiten jetzt die LDAP Attribute aRecord oder aAAARecord in Abhängigkeit davon, ob eine IPv4 oder IPv6 - Adresse erkannt wurde * udm dns/host_record modify ... --append und --remove prüft auf IPv4 / IPv6, --set ersetzt alle alten Einträge univention-directory-modules 5.1.3: * udm reverse_zone kann mit IPv6-Adressen umgehen * Syntax-Checking für IPv6-Subnetze univention-directory-modules 5.1.4: * auch alias, forward_zone und ptr_record sollten jetzt IPv6 können
univention-directory-modules 5.1.7: * Syntax Checks erweitert * IPv6 forward und reverse - Zonen (PTR) werden jetzt korrekt im ldap gespeichert und können über das Computers - DNS Tab im UDM Web angelegt werden (univention-directory-manager 7.1.1) * Neues Python - Module ipaddr ist notwendig
Created attachment 1963 [details] Patch: univention-directory-manager-modules 5.1.12 für univention-directory-manager-modules 5.0.42 aus trunk
Created attachment 2016 [details] Patch: univention-directory-manager-modules 5.1.13 für univention-directory-manager-modules 5.0.45 aus trunk
Created attachment 2038 [details] Patch: univention-directory-manager-modules 5.1.14-2 für univention-directory-manager-modules 5.0.45-1 aus trunk
Bug umbenannt von UDM - IPv6 im DNS in UDM - IPv6 im Backend da dies den Änderungen und dem Patch eher entspricht.
Die Änderungen wurden überarbeitet und übernommen: univention-directory-manager-modules (7.0.150-1) unstable; urgency=low * support IPv6 in UDM backend (Bug #15687) Das Subnetz für Reverse-Zonen-Objekte muss für IPv6 als eine abgeschnittene Adresse mit führenden Nullen und ohne ::-Ersetzung angegeben werden, z.B.: 2001:0db8:010
Die Änderungen sind wie folgt: * __init__.py → Hier wurden einige Hilfsfunktionen für IPv6 erweitert. * syntax.py → ipAddress akzeptiert jetzt v4 und v6 → hostOrIp akzeptiert jetzt v4 und v6 → reverseLookupZoneName akzeptiert jetzt auch ip6.arpa. → reverseLookupSubnet (siehe Reverse-Syntax unten) * dns/reverse_zone → lookup/identify-Filter für v6 angepasst → unmap/mapSubnet für v6 angepasst (siehe Reverse-Syntax unten) * dns/host_record → lookup/identify-Filter für v6 angepasst und vereinheitlicht → anstatt einem einfachen Mapping von "a" auf aRecord wird jetzt von aRecord und aAAARecord auf "a" und zurück gemappt * dns/ptr_record → lookup/identify-Filter für v6 angepasst * dns/forward_zone → lookup/identify-Filter für v6 angepasst → einen nicht mehr verwendeten RegEx entfernt * dns/alias → lookup/identify-Filter für v6 angepasst * dns/srv_record → lookup/identify-Filter für v6 angepasst Reverse-Syntax: Die IPv4 Reverse-Lookup-Syntax basiert auf 8b Teilen (Byte). Dies ist die gleiche Einteilung wie in der üblichen Address-Darstellung - daher kann die IP "einfach umgedreht" werden. Es werden so viele (1-3) Teile angegeben wie für die Reverse-Zone gewünscht. Beispiel: 192.168.0.0/24 wird als 192.168.0 angegeben und wird zu 0.168.192.in-addr.arpa. Die IPv6 Reverse-Lookup-Syntax basiert auf 4b Teilen (Nibble). Dies ist _nicht_ die gleiche Einteilung wie in der üblichen Address-Darstellung, die Einteilung dort ist 16b. Dies führt zu dem Problem, dass 2001:db8:100/44 nicht als 2001:db8:100 angegeben werden kann, denn es ließe sich nicht von 2001:db8:100/{36,40,48} unterscheiden. Daher müssen die IPv6 Reverse-Zonen mit führenden Nullen und ohne die ::-Ersetzung angegeben werden. Es wird einfach direkt nach dem Nibble aufgehört mit dem die gewünschte Genauigkeit erreicht ist. Beispiel: 2001:db8:100/44 wird als 2001:0db8:010 angegeben und wird zu 0.1.0.8.b.d.0.1.0.0.2.ip6.arpa.
Changelog angepasst
Beim Ändern einer IP per UDM CLI eines DC Master bekomme ich den folgenden Traceback: root@master51:~# udm computers/domaincontroller_master modify --dn "cn=master51,cn=dc,cn=computers,dc=deadlock5,dc=local" --set ip=10.201.5.87 Traceback (most recent call last): File "/usr/share/univention-directory-manager-tools/univention-cli-server", line 233, in doit output = univention.admincli.admin.doit(arglist) File "/usr/lib/pymodules/python2.6/univention/admincli/admin.py", line 938, in doit dn=object.modify() File "/usr/lib/pymodules/python2.6/univention/admin/handlers/__init__.py", line 344, in modify return self._modify(modify_childs,ignore_license=ignore_license) File "/usr/lib/pymodules/python2.6/univention/admin/handlers/__init__.py", line 865, in _modify self._ldap_post_modify() File "/usr/lib/pymodules/python2.6/univention/admin/handlers/computers/domaincontroller_master.py", line 566, in _ldap_post_modify univention.admin.handlers.simpleComputer._ldap_post_modify( self ) File "/usr/lib/pymodules/python2.6/univention/admin/handlers/__init__.py", line 1837, in _ldap_post_modify self.__modify_dns_forward_object( self[ 'name' ], None, self.__changes[ 'ip' ][ 'add' ][ 0 ], self.__changes[ 'ip' ][ 'remove' ][ 0 ] ) File "/usr/lib/pymodules/python2.6/univention/admin/handlers/__init__.py", line 1605, in __modify_dns_forward_object old_aAAARecord = attr['aAAARecord'] KeyError: 'aAAARecord' root@master51:~#
univention-directory-manager-modules * Der Traceback wurde behoben. * Die Rechner-Objekte speichern IPv6-Adressen jetzt in aAAARecord * Das Auswählen der DNS-ReverseZone beim Ändern der IP-Adresse wurde korrigiert. univention-ldap * Das Attribut aAAARecord wurde zu univentionHost hinzugefügt.
*** Bug 15555 has been marked as a duplicate of this bug. ***
DNS-Objekte über UMC angelegt und via CLI und dig geprüft: root@mas55:~# udm dns/forward_zone list DN: zoneName=test6net.de,cn=dns,dc=example,dc=de ARG: None expire: 7 days ttl: 3 hours serial: 1 txt: None a: 10.200.18.55 a: 2001:4dd0:ff00:8c42:ff18::55 retry: 2 hours zone: test6net.de zonettl: 1 seconds refresh: 8 hours contact: root@example.de. nameserver: mas55.test6net.de. mx: 10 mail.test6net.de root@mas55:~# dig -6 -t ANY test6net.de +noquestion +nocomments ; <<>> DiG 9.8.0-P4 <<>> -6 -t ANY test6net.de +noquestion +nocomments ;; global options: +cmd test6net.de. 900 IN NS mas55.test6net.de. test6net.de. 10800 IN SOA mas55.example.de. root.example.de. 1 28800 7200 604800 0 test6net.de. 900 IN A 10.200.18.55 test6net.de. 900 IN AAAA 2001:4dd0:ff00:8c42:ff18::55 test6net.de. 3600 IN MX 10 mail.test6net.de. ;; Query time: 1 msec ;; SERVER: ::1#53(::1) ;; WHEN: Tue Nov 29 18:13:31 2011 ;; MSG SIZE rcvd: 184 root@mas55:~# root@mas55:~# udm dns/reverse_zone list DN: zoneName=8.1.f.f.2.4.c.8.0.0.f.f.0.d.d.4.1.0.0.2.ip6.arpa,cn=dns,dc=example,dc=com ARG: None subnet: 2001:4dd0:ff00:8c42:ff18 contact: root@example.com. retry: 2 hours expire: 7 days ttl: 3 hours nameserver: mas55.test6net.de. serial: 1 zonettl: 8 hours refresh: 8 hours root@mas55:~# dig -6 -t ANY -x 2001:4dd0:ff00:8c42:ff18::55 +noquestion +nocomments ; <<>> DiG 9.8.0-P4 <<>> -6 -t ANY -x 2001:4dd0:ff00:8c42:ff18::55 +noquestion +nocomments ;; global options: +cmd 8.1.f.f.2.4.c.8.0.0.f.f.0.d.d.4.1.0.0.2.ip6.arpa. 0 IN SOA mas55.example.com. root.example.com. 1 28800 7200 604800 0 ;; Query time: 49 msec ;; SERVER: ::1#53(::1) ;; WHEN: Tue Nov 29 18:33:39 2011 ;; MSG SIZE rcvd: 144 root@mas55:~# root@mas55:~# udm dns/host_record list --filter=name=ipv6 --superordinate=zoneName=test6net.de,cn=dns,dc=example,dc=com name=ipv6 DN: relativeDomainName=ipv6,zoneName=test6net.de,cn=dns,dc=example,dc=com ARG: None a: 2001:4dd0:ff00:8c42:ff18:0:1234:4567 txt: This is my TXT record mx: 10 6mail.example.com name: ipv6 zonettl: 1 seconds root@mas55:~# dig -6 -t ANY ipv6.test6net.de +noall +answer ; <<>> DiG 9.8.0-P4 <<>> -6 -t ANY ipv6.test6net.de +noall +answer ;; global options: +cmd ipv6.test6net.de. 900 IN AAAA 2001:4dd0:ff00:8c42:ff18:0:1234:4567 root@mas55:~# root@mas55:~# udm dns/dns list DN: zoneName=example.de,cn=dns,dc=example,dc=com ARG: None DN: zoneName=test6net.de,cn=dns,dc=example,dc=com ARG: None DN: zoneName=18.200.10.in-addr.arpa,cn=dns,dc=example,dc=com ARG: None DN: zoneName=8.1.f.f.2.4.c.8.0.0.f.f.0.d.d.4.1.0.0.2.ip6.arpa,cn=dns,dc=example,dc=com ARG: None root@mas55:~#
Ein Rechnerobjekt wurde im UDM angelegt: IPv6-Adresse: 2001:4dd0:ff00:8c42:ff18:1111:22:3333 Man beachte, dass im vorletzten Segment die führenden Nullen ausgelassen wurden. Selbst wenn man diese angibt, werden sie automatisch entfernt, da sie optional sind. Das DNS-PTR-Objekt enthält diese führenden Nullen ebenfalls nicht, so dass der PTR-Record nicht korrekt funktioniert. root@mas55:~# udm dns/ptr_record list --superordinate zoneName=8.1.f.f.2.4.c.8.0.0.f.f.0.d.d.4.1.0.0.2.ip6.arpa,cn=dns,dc=example,dc=com DN: relativeDomainName=3.3.3.3.2.2.1.1.1.1,zoneName=8.1.f.f.2.4.c.8.0.0.f.f.0.d.d.4.1.0.0.2.ip6.arpa,cn=dns,dc=example,dc=com ARG: None ptr_record: ipmit6.example.info. address: 3.3.3.3.2.2.1.1.1.1 root@mas55:~#
Ein neues Rechnerobjekt (IP-Managed-Client) wurde in der UMC mit IPv6-Adresse 2001:4dd0:ff00:8c42:ff18::1 erstellt. Anschließend wurde das Rechnerobjekt geöffnet und die IP-Adresse auf 2001:4dd0:ff00:8c42:ff18::2 geändert. Beim Speichern wird ein LDAP-Fehler angezeigt: 29.11.11 23:46:59.138 ADMIN ( INFO ) : we should modify a dns forward object: zoneDn="None", name="test1", new_ip="2001:4dd0:ff00:8c42:ff18::2", old_ip="2001:4dd0:ff00:8c42:ff18::1" 29.11.11 23:46:59.142 MODULE ( WARN ) : Failed to modify LDAP object cn=test1,cn=computers,dc=nstx,dc=de: ldapError: Type or value exists: aAAARecord: value #0 provided more than once Das DNS-Host-Objekt wird nicht korrekt aktualisiert. Es wird nur die neue IP-Adresse hinzugefügt, aber nicht die alte entfernt. Eintrag des DNS-Objektes vor dem Ändern: root@mas55:~# udm dns/host_record list --superordinate zoneName=nstx.de,cn=dns,dc=nstx,dc=de --filter=name=test1 name=test1 DN: relativeDomainName=test1,zoneName=nstx.de,cn=dns,dc=nstx,dc=de ARG: None a: 2001:4dd0:ff00:8c42:ff18::1 txt: None mx: None name: test1 zonettl: None DNS-Objekt nach dem Ändern: root@mas55:~# udm dns/host_record list --superordinate zoneName=nstx.de,cn=dns,dc=nstx,dc=de --filter=name=test1 name=test1 DN: relativeDomainName=test1,zoneName=nstx.de,cn=dns,dc=nstx,dc=de ARG: None a: 2001:4dd0:ff00:8c42:ff18::1 a: 2001:4dd0:ff00:8c42:ff18::2 txt: None mx: None name: test1 zonettl: None root@mas55:~#
root@mas55:~# udm computers/memberserver list --filter=name=mem8| egrep 'Reverse|ip' ip: 2001:4dd0:ff00:8c42:ff50:1111:0:4 description: None dnsEntryZoneReverse: zoneName=0.5.f.f.2.4.c.8.0.0.f.f.0.d.d.4.1.0.0.2.ip6.arpa,cn=dns,dc=nstx,dc=de 20:014d:d0ff:008c:42ff:5011:1104 root@mas55:~# udm dns/ptr_record list --superordinate zoneName=0.5.f.f.2.4.c.8.0.0.f.f.0.d.d.4.1.0.0.2.ip6.arpa,cn=dns,dc=nstx,dc=de --filter=ptr_record=mem8.nstx.de. ptr_record=mem8.nstx.de. DN: relativeDomainName=4.0.1.1.1.1,zoneName=0.5.f.f.2.4.c.8.0.0.f.f.0.d.d.4.1.0.0.2.ip6.arpa,cn=dns,dc=nstx,dc=de ARG: None ptr_record: mem8.nstx.de. address: 4.0.1.1.1.1
Vorher: ipaddr.IPv6Address('1:2:3:4:5:6:7:8').exploded '1:2:3:4:5:6:7:8' ipaddr.IPv6Address('1:2:3:4:5:6:7::').exploded '1:2:3:4:5:6:7:0' ipaddr.IPv6Address('1:2:3:4:5:6::').exploded '0001:0002:0003:0004:0005:0006:0000:0000' Der Fix für python-ipaddr Issue #77 http://code.google.com/p/ipaddr-py/issues/detail?id=77 wurde als Patch zurückportiert. Nachher: ipaddr.IPv6Address('1:2:3:4:5:6:7:8').exploded '0001:0002:0003:0004:0005:0006:0007:0008' ipaddr.IPv6Address('1:2:3:4:5:6:7::').exploded '0001:0002:0003:0004:0005:0006:0007:0000' ipaddr.IPv6Address('1:2:3:4:5:6::').exploded '0001:0002:0003:0004:0005:0006:0000:0000'
Ein Memberserver wurde mit der IPv6-Adresse 2001:4dd0:ff00:8c42:ff50:1111::5 angelegt. Nach dem Öffnen wird der Eintrag der Reverse-Zone nicht mehr angezeigt. Ein "udm dns/ptr_record list ..." zeigt jedoch den Reverse-Zonen-Eintrag. Ein "udm computers/memberserver list" zeigt diesen nicht. Bei dem Memberserver wird die IPv6-Adresse von 2001:4dd0:ff00:8c42:ff50:1111::5 auf 2001:4dd0:ff00:8c42:ff50:1111::7 geändert: - es existieren hinterher zwei PTR-Records (in SimpleComputer wurde die Löschfunktion für FwdZonenEinträge noch nicht angepasst) - es wird ein LDAP-Fehler geworden: 30.11.11 09:36:35.016 ADMIN ( INFO ) : we should modify a dns forward object: zoneDn="None", name="mem10", new_ip="2001:4dd0:ff00:8c42:ff50:1111:0:7", old_ip="2001:4dd0:ff00:8c42:ff50:1111:0:6" 30.11.11 09:36:35.016 ADMIN ( INFO ) : mod dn=relativeDomainName=mem10,zoneName=nstx.de,cn=dns,dc=nstx,dc=de ml=[('aAAARecord', ['2001:4dd0:ff00:8c42:ff50:1111:0:5', '2001:4dd0:ff00:8c42:ff50:1111:0:6', '2001:4dd0:ff00:8c42:ff50:1111:0:7'], ['2001:4dd0:ff00:8c42:ff50:1111:0:5', '2001:4dd0:ff00:8c42:ff50:1111:0:7', '2001:4dd0:ff00:8c42:ff50:1111:0:7'])] 30.11.11 09:36:35.016 ADMIN ( INFO ) : mod dn=relativeDomainName=mem10,zoneName=nstx.de,cn=dns,dc=nstx,dc=de err={'info': 'aAAARecord: value #1 provided more than once', 'desc': 'Type or value exists'}
IPv6 Adressen werden jetzt "explodiert" im LDAP gespeichert Es wurde eine Funktion zum Löschen von ForwardZonen um IPv6 erweitert. Es wurden ein paar Fehler beim Löschen von Forward/ReverseZonen am Rechner behoben.
(In reply to comment #15) > Ein neues Rechnerobjekt (IP-Managed-Client) wurde in der UMC mit IPv6-Adresse > 2001:4dd0:ff00:8c42:ff18::1 erstellt. Anschließend wurde das Rechnerobjekt > geöffnet und die IP-Adresse auf 2001:4dd0:ff00:8c42:ff18::2 geändert. Beim > Speichern wird ein LDAP-Fehler angezeigt: > > 29.11.11 23:46:59.138 ADMIN ( INFO ) : we should modify a dns forward > object: zoneDn="None", name="test1", new_ip="2001:4dd0:ff00:8c42:ff18::2", > old_ip="2001:4dd0:ff00:8c42:ff18::1" > 29.11.11 23:46:59.142 MODULE ( WARN ) : Failed to modify LDAP object > cn=test1,cn=computers,dc=nstx,dc=de: ldapError: Type or value exists: > aAAARecord: value #0 provided more than once → Fehler tritt nicht mehr auf > Das DNS-Host-Objekt wird nicht korrekt aktualisiert. Es wird nur die neue > IP-Adresse hinzugefügt, aber nicht die alte entfernt. > > Eintrag des DNS-Objektes vor dem Ändern: > > root@mas55:~# udm dns/host_record list --superordinate > zoneName=nstx.de,cn=dns,dc=nstx,dc=de --filter=name=test1 > name=test1 > DN: relativeDomainName=test1,zoneName=nstx.de,cn=dns,dc=nstx,dc=de > ARG: None > a: 2001:4dd0:ff00:8c42:ff18::1 > txt: None > mx: None > name: test1 > zonettl: None > > DNS-Objekt nach dem Ändern: > > root@mas55:~# udm dns/host_record list --superordinate > zoneName=nstx.de,cn=dns,dc=nstx,dc=de --filter=name=test1 > name=test1 > DN: relativeDomainName=test1,zoneName=nstx.de,cn=dns,dc=nstx,dc=de > ARG: None > a: 2001:4dd0:ff00:8c42:ff18::1 > a: 2001:4dd0:ff00:8c42:ff18::2 > txt: None > mx: None > name: test1 > zonettl: None > > root@mas55:~# AAAA-Record wird jetzt korrekt aktualisiert bzw. das alte gelöscht und ein neues Objekt angelegt. (In reply to comment #16) > root@mas55:~# udm computers/memberserver list --filter=name=mem8| egrep > 'Reverse|ip' > ip: 2001:4dd0:ff00:8c42:ff50:1111:0:4 > description: None > dnsEntryZoneReverse: > zoneName=0.5.f.f.2.4.c.8.0.0.f.f.0.d.d.4.1.0.0.2.ip6.arpa,cn=dns,dc=nstx,dc=de > 20:014d:d0ff:008c:42ff:5011:1104 > > root@mas55:~# udm dns/ptr_record list --superordinate > zoneName=0.5.f.f.2.4.c.8.0.0.f.f.0.d.d.4.1.0.0.2.ip6.arpa,cn=dns,dc=nstx,dc=de > --filter=ptr_record=mem8.nstx.de. > ptr_record=mem8.nstx.de. > DN: > relativeDomainName=4.0.1.1.1.1,zoneName=0.5.f.f.2.4.c.8.0.0.f.f.0.d.d.4.1.0.0.2.ip6.arpa,cn=dns,dc=nstx,dc=de > ARG: None > ptr_record: mem8.nstx.de. > address: 4.0.1.1.1.1 Der Reverse-Zone-Eintrag weist jetzt die korrekte Länge auf. Es wird jetzt immer die expandierte IPv6-Adresse im LDAP gespeichert. Hinweis: IPv6-Adressen MÜSSEN im LDAP generell in der expandierten Form und mit Kleinbuchstaben gespeichert werden (39 Zeichen lang). Die LDAP-Suchfilter verlassen sich darauf. Dies ist auch die einzige Notation der Adressen, die in jedem Fall eindeutig ist. (In reply to comment #18) > Ein Memberserver wurde mit der IPv6-Adresse 2001:4dd0:ff00:8c42:ff50:1111::5 > angelegt. Nach dem Öffnen wird der Eintrag der Reverse-Zone nicht mehr > angezeigt. Ein "udm dns/ptr_record list ..." zeigt jedoch den > Reverse-Zonen-Eintrag. Ein "udm computers/memberserver list" zeigt diesen > nicht. → die Reversezone wird jetzt für IPv6-Zonen wieder korrekt angezeigt. > Bei dem Memberserver wird die IPv6-Adresse von > 2001:4dd0:ff00:8c42:ff50:1111::5 auf 2001:4dd0:ff00:8c42:ff50:1111::7 geändert: > - es existieren hinterher zwei PTR-Records (in SimpleComputer wurde die > Löschfunktion für FwdZonenEinträge noch nicht angepasst) > - es wird ein LDAP-Fehler geworden: > > 30.11.11 09:36:35.016 ADMIN ( INFO ) : we should modify a dns forward > object: zoneDn="None", name="mem10", > new_ip="2001:4dd0:ff00:8c42:ff50:1111:0:7", > old_ip="2001:4dd0:ff00:8c42:ff50:1111:0:6" > 30.11.11 09:36:35.016 ADMIN ( INFO ) : mod > dn=relativeDomainName=mem10,zoneName=nstx.de,cn=dns,dc=nstx,dc=de > ml=[('aAAARecord', ['2001:4dd0:ff00:8c42:ff50:1111:0:5', > '2001:4dd0:ff00:8c42:ff50:1111:0:6', '2001:4dd0:ff00:8c42:ff50:1111:0:7'], > ['2001:4dd0:ff00:8c42:ff50:1111:0:5', '2001:4dd0:ff00:8c42:ff50:1111:0:7', > '2001:4dd0:ff00:8c42:ff50:1111:0:7'])] > 30.11.11 09:36:35.016 ADMIN ( INFO ) : mod > dn=relativeDomainName=mem10,zoneName=nstx.de,cn=dns,dc=nstx,dc=de err={'info': > 'aAAARecord: value #1 provided more than once', 'desc': 'Type or value exists'} → fixed
Beim Löschen der letzten IPv4-Adresse aus den Forward-Zone-Einträgen wurde der gesamte Forward-Zone-Eintrag entfernt und damit auch ggf. noch vorhandene IPv6-Einträge. Dieser Bug ist jetzt behoben → verified
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"