Ghost DNS PTR in RSAT that show up in UCS UDM - no rejects - suspect dnsRecord RANK flags wrong

[pp303]

Hi all, I had issues with DNS PTR records last year that Moritz tried to help me with. Seemed to be a few overlapping issues involved (rejects, SAML, certificates etc).

4.2-1 upgrade Samba4 DNS reverse lookup zone has broken (corrupted?) PTR records

Found a new issue after upgrade to 4.2-1. This one seems related to DNS resolution. DNS information in the OpenLDAP directory appears to be correct, however reverse lookup zones in samba4 DNS under RSAT show badly formatted records (nonsense extra octet in IP address - which confuses RSAT). Assuming came with upgrade (will check logs) as I wouldn’t think RSAT input validation would allow a bad IP entry and we haven’t edited any entries after upgrade. [image] Additionally these PTR records ar…

I’ve since upgraded to 4.3-1 and sorted out my s4-connector rejects, certificate and SAML issues and everything is running as smoothly as it ever has been using UCS.

Thanks for the help Moritz!

What I have noticed is that despite having a clean bill of health from the diagnostics and no rejects logged, some ghost DNS PTR entries on the samba AD side are not visible in the DNS RSAT but are visible in the ADSI edit MMC.

I’ve used the univention-s4search scripts to potentially work out the cause for this (dnsRecord RANK flags set to 0 instead of 240) but want to get advice on how to fix it without breaking anything in the s4 AD or with the UCS s4 sync processes.

Here’s what I’ve got:
In UCS UDM web interface I have the correct PTR entries listed for reverse lookup zones.

Some reverse lookup zones do not display all entries in the RSAT DNS MMC. They do however seem to resolve from the commandline (dns backend is samba) so must still be in AD.

Indeed looking at the domaindnszones with ADSI edit, the missing entries are listed in there.

Using the univention search scripts, they also show up there. The only thing that is different between the ones that are visible and the ones that aren’t are that the dnsRecord blob has a different RANK set (0) for the ones that are missing and (240) for the ones that work.

root@dcm1:/var/log/univention# univention-s4search -b "DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au"|s4search-d
ecode
# record 1
dn: DC=5.20,DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au
objectClass: top
objectClass: dnsNode
instanceType: 4
whenCreated: 20160713062352.0Z
whenChanged: 20160713062352.0Z
uSNCreated: 6642
uSNChanged: 6642
showInAdvancedViewOnly: TRUE
name: 5.20
objectGUID: 8d1bf107-62d8-435f-8ecd-7585b74853cb
dnsRecord:: JQAM <snipped> EDY29tAmF1AA==
# decoded:
#     dnsp_DnssrvRpcRecord: struct dnsp_DnssrvRpcRecord
#         wDataLength              : 0x0025 (37)
#         wType                    : DNS_TYPE_PTR (12)
#         version                  : 0x05 (5)
#         rank                     : DNS_RANK_NONE (0)
#         flags                    : 0x0000 (0)
#         dwSerial                 : 0x00000001 (1)
#         dwTtlSeconds             : 0x00000e10 (3600)
#         dwReserved               : 0x00000000 (0)
#         dwTimeStamp              : 0x00000000 (0)
#         data                     : union dnsRecordData(case 12)
#         ptr                      : cnscopier.<removedrealdomain>.com.au
objectCategory: CN=Dns-Node,CN=Schema,CN=Configuration,<removedrealdomain>,DC=com,DC=au
dc: 5.20
distinguishedName: DC=5.20,DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au

# record 2
dn: DC=7.20,DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au
objectClass: top
objectClass: dnsNode
instanceType: 4
whenCreated: 20160713062706.0Z
whenChanged: 20160713062706.0Z
uSNCreated: 6649
uSNChanged: 6649
showInAdvancedViewOnly: TRUE
name: 7.20
objectGUID: 06a17ef5-ed54-454d-a4c7-8c44ea7c677c
dnsRecord:: LAAM <snipped> QA=
# decoded:
#     dnsp_DnssrvRpcRecord: struct dnsp_DnssrvRpcRecord
#         wDataLength              : 0x002c (44)
#         wType                    : DNS_TYPE_PTR (12)
#         version                  : 0x05 (5)
#         rank                     : DNS_RANK_NONE (0)
#         flags                    : 0x0000 (0)
#         dwSerial                 : 0x00000001 (1)
#         dwTtlSeconds             : 0x00000e10 (3600)
#         dwReserved               : 0x00000000 (0)
#         dwTimeStamp              : 0x00000000 (0)
#         data                     : union dnsRecordData(case 12)
#         ptr                      : cnswarehouse-340.<removedrealdomain>.com.au
objectCategory: CN=Dns-Node,CN=Schema,CN=Configuration,<removedrealdomain>,DC=com,DC=au
dc: 7.20
distinguishedName: DC=7.20,DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au

# record 3
dn: DC=11.20,DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au
objectClass: top
objectClass: dnsNode
instanceType: 4
whenCreated: 20160909041215.0Z
whenChanged: 20160909041215.0Z
uSNCreated: 34397
uSNChanged: 34397
showInAdvancedViewOnly: TRUE
name: 11.20
objectGUID: d92e3a87-2dfa-438a-b2bf-d2ed5780de3e
dnsRecord:: MAAMA <snipped> hc2F1c3RyYWxpYQNjb20CYXUA
# decoded:
#     dnsp_DnssrvRpcRecord: struct dnsp_DnssrvRpcRecord
#         wDataLength              : 0x0030 (48)
#         wType                    : DNS_TYPE_PTR (12)
#         version                  : 0x05 (5)
#         rank                     : DNS_RANK_ZONE (240)
#         flags                    : 0x0000 (0)
#         dwSerial                 : 0x00000001 (1)
#         dwTtlSeconds             : 0x00000384 (900)
#         dwReserved               : 0x00000000 (0)
#         dwTimeStamp              : 0x00000000 (0)
#         data                     : union dnsRecordData(case 12)
#         ptr                      : cns-invoice-lbp251dw.<removedrealdomain>.com.au
objectCategory: CN=Dns-Node,CN=Schema,CN=Configuration,<removedrealdomain>,DC=com,DC=au
dc: 11.20
distinguishedName: DC=11.20,DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au

# record 4
dn: DC=10.20,DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au
objectClass: top
objectClass: dnsNode
instanceType: 4
whenCreated: 20160909041150.0Z
whenChanged: 20160909041150.0Z
uSNCreated: 34392
uSNChanged: 34392
showInAdvancedViewOnly: TRUE
name: 10.20
objectGUID: a2a98a24-4951-4f8d-a40d-c3758a54627c
dnsRecord:: LAAM <snipped> zdHJhbGlhA2NvbQJhdQA=
# decoded:
#     dnsp_DnssrvRpcRecord: struct dnsp_DnssrvRpcRecord
#         wDataLength              : 0x002c (44)
#         wType                    : DNS_TYPE_PTR (12)
#         version                  : 0x05 (5)
#         rank                     : DNS_RANK_ZONE (240)
#         flags                    : 0x0000 (0)
#         dwSerial                 : 0x00000001 (1)
#         dwTtlSeconds             : 0x00000384 (900)
#         dwReserved               : 0x00000000 (0)
#         dwTimeStamp              : 0x00000000 (0)
#         data                     : union dnsRecordData(case 12)
#         ptr                      : cns-copier-c5240.<removedrealdomain>.com.au
objectCategory: CN=Dns-Node,CN=Schema,CN=Configuration,<removedrealdomain>,DC=com,DC=au
dc: 10.20
distinguishedName: DC=10.20,DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au


# record 5
dn: DC=@,DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au
objectClass: top
objectClass: dnsNode
instanceType: 4
whenCreated: 20160704035722.0Z
uSNCreated: 5619
showInAdvancedViewOnly: TRUE
name: @
objectGUID: f1ac1d4d-a24a-433f-9520-b9e65c4d2adc
objectCategory: CN=Dns-Node,CN=Schema,CN=Configuration,<removedrealdomain>,DC=com,DC=au
dc: @
whenChanged: 20170707143635.0Z
uSNChanged: 290713
dnsRecord:: IAACAAXwA <snipped> XVzdHJhbGlhA2NvbQJhdQA=
# decoded:
#     dnsp_DnssrvRpcRecord: struct dnsp_DnssrvRpcRecord
#         wDataLength              : 0x0020 (32)
#         wType                    : DNS_TYPE_NS (2)
#         version                  : 0x05 (5)
#         rank                     : DNS_RANK_ZONE (240)
#         flags                    : 0x0000 (0)
#         dwSerial                 : 0x00000001 (1)
#         dwTtlSeconds             : 0x00000384 (900)
#         dwReserved               : 0x00000000 (0)
#         dwTimeStamp              : 0x00000000 (0)
#         data                     : union dnsRecordData(case 2)
#         ns                       : dcm1.<removedrealdomain>.com.au
dnsRecord:: UwAGA <snipped> bQJhdQA=
# decoded:
#     dnsp_DnssrvRpcRecord: struct dnsp_DnssrvRpcRecord
#         wDataLength              : 0x0053 (83)
#         wType                    : DNS_TYPE_SOA (6)
#         version                  : 0x05 (5)
#         rank                     : DNS_RANK_ZONE (240)
#         flags                    : 0x0000 (0)
#         dwSerial                 : 0x00000001 (1)
#         dwTtlSeconds             : 0x00015180 (86400)
#         dwReserved               : 0x00000000 (0)
#         dwTimeStamp              : 0x00000000 (0)
#         data                     : union dnsRecordData(case 6)
#         soa: struct dnsp_soa
#             serial                   : 0x00000001 (1)
#             refresh                  : 0x00007080 (28800)
#             retry                    : 0x00001c20 (7200)
#             expire                   : 0x00093a80 (604800)
#             minimum                  : 0x00000e10 (3600)
#             mname                    : dcm1.<removedrealdomain>.com.au
#             rname                    : domains.<removedrealdomain>.com.au
distinguishedName: DC=@,DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au

# record 6
dn: DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au
objectClass: top
objectClass: dnsZone
instanceType: 4
whenCreated: 20160704035722.0Z
whenChanged: 20160704035722.0Z
uSNCreated: 5618
uSNChanged: 5618
showInAdvancedViewOnly: TRUE
name: 30.10.in-addr.arpa
objectGUID: cad078d1-cf95-407b-84b7-c689610b5dbd
objectCategory: CN=Dns-Zone,CN=Schema,CN=Configuration,<removedrealdomain>,DC=com,DC=au
dc: 30.10.in-addr.arpa
distinguishedName: DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au

# returned 6 records
# 6 entries
# 0 referrals

Searching google leads to this MS-DNSP protocol document that specifies the rank flag of 240 to be from a local authoritative zone (DNS_RANK_ZONE).

There’s no mention of a zero value (DNS_RANK_NONE in s4search-decode), so I suppose that is causing the problem that is hiding the PTR records and the s4-connector must not be aware of or correcting the DNS_RANK_NONE field in the dnsRecord?

In any case although I’m pretty sure this is the problem, I don’t know how to fix it. Do I delete the s4 side and force a resync from UCS LDAP side?

Hoping univention staff or the linet guys can tell me best way to resolve this

[Moritz_Bunkus]

Hey,

interesting problem and great analysis. Trying to change the rank flag to 240 sounds sensible to me; I’d give that a try.

Removing the object on the S4 side will trigger a sync request and therefore a deletion on the OpenLDAP side, too. However, that isn’t critical: just wait until the sync’s been done and recreate the entry on the OpenLDAP side. Then see what flags the entry is recreated with on the S4 side. This seems to be the quickest way to change the flags to me, especially given that the S4’s dnsRecord attribute contains binary content that isn’t easy to modify with tools such as ldapmodify.

As these are just PTR records, doing the above should be safe in the sense that nothing else but the PTR objects should be removed or changed.

Just give it a try.

Oh, and you’re welcome

Kind regards,
mosu

[pp303]

Hi Mosu, here’s what I’ve tried in terms of experimenting.

Use ADSI edit to delete the single entry from the domaindnszones tree.
There’s a s4-sync message about deleting the dns entry, and no rejects, but doesn’t seem to change anything in OpenLDAP.

22.06.2018 08:30:35,943 LDAP        (PROCESS): sync to ucs:   [           dns] [    delete] relativedomainname=5.20,zonename=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au

I then deleted the whole 30.10 reverse zone out of the RSAT DNS, and receive the following sync messages :

22.06.2018 08:37:40,69 LDAP        (PROCESS): sync to ucs:   [           dns] [    delete] relativeDomainName=@
DEL:f1ac1d4d-a24a-433f-9520-b9e65c4d2adc,zoneName=30.10.in-addr.arpa
DEL:cad078d1-cf95-407b-84b7-c689610b5dbd,cn=dns,<removedrealdomain>,dc=com,dc=au
22.06.2018 08:37:40,81 LDAP        (PROCESS): sync to ucs:   [           dns] [    delete] relativeDomainName=7.20
DEL:06a17ef5-ed54-454d-a4c7-8c44ea7c677c,zoneName=30.10.in-addr.arpa
DEL:cad078d1-cf95-407b-84b7-c689610b5dbd,cn=dns,<removedrealdomain>,dc=com,dc=au
22.06.2018 08:37:40,122 LDAP        (PROCESS): sync to ucs:   [           dns] [    delete] relativeDomainName=10.20
DEL:a2a98a24-4951-4f8d-a40d-c3758a54627c,zoneName=30.10.in-addr.arpa
DEL:cad078d1-cf95-407b-84b7-c689610b5dbd,cn=dns,<removedrealdomain>,dc=com,dc=au
22.06.2018 08:37:40,133 LDAP        (PROCESS): sync to ucs:   [           dns] [    delete] relativeDomainName=11.20
DEL:d92e3a87-2dfa-438a-b2bf-d2ed5780de3e,zoneName=30.10.in-addr.arpa
DEL:cad078d1-cf95-407b-84b7-c689610b5dbd,cn=dns,<removedrealdomain>,dc=com,dc=au
22.06.2018 08:37:40,140 LDAP        (PROCESS): sync to ucs:   [           dns] [    delete] zoneName=30.10.in-addr.arpa
DEL:cad078d1-cf95-407b-84b7-c689610b5dbd,cn=dns,<removedrealdomain>,dc=com,dc=au

and no rejects:

root@dcm1:~# univention-s4connector-list-rejected

UCS rejected


S4 rejected


There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.


        last synced USN: 776359

But in the OpenLDAP DNS that reverse zone is still listed.

root@dcm1:~# univention-ldapsearch -b "zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au"
# extended LDIF
#
# LDAPv3
# base <zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# 30.10.in-addr.arpa, dns, <removedrealdomain>.com.au
dn: zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au
nSRecord: dcb.<removedrealdomain>.com.au.
nSRecord: dcm1.<removedrealdomain>.com.au.
objectClass: dNSZone
objectClass: top
objectClass: univentionObject
univentionObjectType: dns/reverse_zone
dNSTTL: 10800
relativeDomainName: @
zoneName: 30.10.in-addr.arpa
sOARecord: dcb.<removedrealdomain>.com.au. root.<removedrealdomain>.com.au. 7 28800
 7200 604800 86400

# 5.20, 30.10.in-addr.arpa, dns, <removedrealdomain>.com.au
dn: relativeDomainName=5.20,zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au
objectClass: dNSZone
objectClass: top
objectClass: univentionObject
univentionObjectType: dns/ptr_record
relativeDomainName: 5.20
pTRRecord: cnscopier.<removedrealdomain>.com.au.
zoneName: 30.10.in-addr.arpa

# 7.20, 30.10.in-addr.arpa, dns, <removedrealdomain>.com.au
dn: relativeDomainName=7.20,zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au
objectClass: dNSZone
objectClass: top
objectClass: univentionObject
univentionObjectType: dns/ptr_record
relativeDomainName: 7.20
pTRRecord: cnswarehouse-340.<removedrealdomain>.com.au.
zoneName: 30.10.in-addr.arpa

# 10.20, 30.10.in-addr.arpa, dns, <removedrealdomain>.com.au
dn: relativeDomainName=10.20,zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au
objectClass: dNSZone
objectClass: top
objectClass: univentionObject
univentionObjectType: dns/ptr_record
relativeDomainName: 10.20
pTRRecord: cns-copier-c5240.<removedrealdomain>.com.au.
zoneName: 30.10.in-addr.arpa

# 11.20, 30.10.in-addr.arpa, dns, <removedrealdomain>.com.au
dn: relativeDomainName=11.20,zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au
objectClass: dNSZone
objectClass: top
objectClass: univentionObject
univentionObjectType: dns/ptr_record
relativeDomainName: 11.20
pTRRecord: cns-invoice-lbp251dw.<removedrealdomain>.com.au.
zoneName: 30.10.in-addr.arpa

# search result
search: 3
result: 0 Success

# numResponses: 6
# numEntries: 5

So seems the S4->UCS sync is not working properly? At a bit of a loss what to do next. Delete the reverse zone in OpenLDAP? Restart services?

A few other links I’ve found online mentioning rank flags:

1. https://forge.univention.org/bugzilla/show_bug.cgi?id=41006
2. https://groups.google.com/forum/#!topic/linux.samba/IjRKmATbPpg
3. https://lists.samba.org/archive/samba/2016-January/197109.html
4. https://lists.samba.org/archive/samba-technical/2016-December/117594.html

[pp303]

Adding a new reverse zone in S4,

22.06.2018 08:56:47,589 LDAP        (PROCESS): sync to ucs:   [           dns] [    modify] relativedomainname=sunnycoastnuc,zonename=<removedrealdomain>.com.au,cn=dns,<removedrealdomain>,dc=com,dc=au
22.06.2018 08:57:03,739 LDAP        (PROCESS): sync to ucs:   [           dns] [       add] zoneName=90.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au
22.06.2018 08:57:03,776 LDAP        (PROCESS): sync to ucs:   [           dns] [       add] zoneName=90.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au
22.06.2018 08:57:03,833 LDAP        (PROCESS): sync to ucs:   [           dns] [    modify] relativedomainname=scwh2,zonename=<removedrealdomain>.com.au,cn=dns,<removedrealdomain>,dc=com,dc=au
22.06.2018 08:57:09,934 LDAP        (PROCESS): sync from ucs: [           dns] [       add] DC=@,DC=90.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au
22.06.2018 08:57:11,53 LDAP        (PROCESS): sync to ucs:   [           dns] [    modify] zonename=90.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au

does come over into OpenLDAP ok

root@dcm1:~# univention-ldapsearch -b "zoneName=90.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au"
# extended LDIF
#
# LDAPv3
# base <zoneName=90.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# 90.10.in-addr.arpa, dns, <removedrealdomain>.com.au
dn: zoneName=90.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au
sOARecord: dcm1.<removedrealdomain>.com.au. hostmaster.<removedrealdomain>.com.au. 1
  900 600 86400 3600
nSRecord: dcm1.<removedrealdomain>.com.au.
objectClass: dNSZone
objectClass: top
objectClass: univentionObject
univentionObjectType: dns/reverse_zone
dNSTTL: 10800
relativeDomainName: @
zoneName: 90.10.in-addr.arpa

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

But then deleting the new zone from S4 sends sync messages,

22.06.2018 09:03:16,629 LDAP        (PROCESS): sync to ucs:   [           dns] [    delete] zoneName=90.10.in-addr.arpa
DEL:ab5276d2-c9e9-405f-9c9f-cfdb8c805010,cn=dns,<removedrealdomain>,dc=com,dc=au

but no change in OpenLDAP

root@dcm1:~# univention-ldapsearch -b "zoneName=90.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au"
# extended LDIF
#
# LDAPv3
# base <zoneName=90.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# 90.10.in-addr.arpa, dns, <removedrealdomain>.com.au
dn: zoneName=90.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au
sOARecord: dcm1.<removedrealdomain>.com.au. hostmaster.<removedrealdomain>.com.au. 1
  900 600 86400 3600
nSRecord: dcm1.<removedrealdomain>.com.au.
objectClass: dNSZone
objectClass: top
objectClass: univentionObject
univentionObjectType: dns/reverse_zone
dNSTTL: 10800
relativeDomainName: @
zoneName: 90.10.in-addr.arpa

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

So maybe only an issue with delete? Is this a bug?

[pp303]

Answering my own question, yes?

https://forge.univention.org/bugzilla/show_bug.cgi?id=39637

[pp303]

So, given the above bug leaving the reverse zone in UDM I was curious if the resync_from_ucs script would bring the correct reverse zone back over from UDM?

root@dcm1:~# /usr/share/univention-s4-connector/resync_object_from_ucs.py "zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au"
resync triggered for zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au
root@dcm1:~# univention-s4connector-list-rejected

UCS rejected


S4 rejected


There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.


        last synced USN: 776411

It brings over the toplevel domain object but none of the child PTR records. Is that intended usage of the script? You have to call each child record manually?

If I do this manually, what does the connector do with the dnsRecord?

root@dcm1:~# /usr/share/univention-s4-connector/resync_object_from_ucs.py "relativeDomainName=10.20,zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au"
resync triggered for relativeDomainName=10.20,zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au
root@dcm1:~# /usr/share/univention-s4-connector/resync_object_from_ucs.py "relativeDomainName=7.20,zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au"
resync triggered for relativeDomainName=7.20,zoneName=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au

22.06.2018 09:36:56,173 LDAP        (PROCESS): sync from ucs: [           dns] [       add] DC=10.20,dc=30.10.in-addr.arpa,cn=microsoftdns,dc=domaindnszones,<removedrealdomain>,DC=com,DC=au
22.06.2018 09:36:57,243 LDAP        (PROCESS): sync to ucs:   [           dns] [    modify] relativedomainname=10.20,zonename=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au
22.06.2018 09:39:02,289 LDAP        (PROCESS): sync from ucs: [           dns] [       add] DC=7.20,dc=30.10.in-addr.arpa,cn=microsoftdns,dc=domaindnszones,<removedrealdomain>,DC=com,DC=au
22.06.2018 09:39:03,359 LDAP        (PROCESS): sync to ucs:   [           dns] [    modify] relativedomainname=7.20,zonename=30.10.in-addr.arpa,cn=dns,<removedrealdomain>,dc=com,dc=au

And the dnsRecord attribute has correct rank flag:

# record 1
dn: DC=7.20,DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au
objectClass: top
objectClass: dnsNode
instanceType: 4
whenCreated: 20180621233902.0Z
whenChanged: 20180621233902.0Z
uSNCreated: 776434
uSNChanged: 776434
showInAdvancedViewOnly: TRUE
name: 7.20
objectGUID: b500c6fb-54f5-4fa3-bf91-0b00c687088d
dnsRecord:: LAA<snipped>A=
# decoded:
#     dnsp_DnssrvRpcRecord: struct dnsp_DnssrvRpcRecord
#         wDataLength              : 0x002c (44)
#         wType                    : DNS_TYPE_PTR (12)
#         version                  : 0x05 (5)
#         rank                     : DNS_RANK_ZONE (240)
#         flags                    : 0x0000 (0)
#         dwSerial                 : 0x00000001 (1)
#         dwTtlSeconds             : 0x00000384 (900)
#         dwReserved               : 0x00000000 (0)
#         dwTimeStamp              : 0x00000000 (0)
#         data                     : union dnsRecordData(case 12)
#         ptr                      : cnswarehouse-340.<removedrealdomain>.com.au
objectCategory: CN=Dns-Node,CN=Schema,CN=Configuration,<removedrealdomain>,DC=com,DC=au
dc: 7.20
distinguishedName: DC=7.20,DC=30.10.in-addr.arpa,CN=MicrosoftDNS,DC=DomainDnsZones,<removedrealdomain>,DC=com,DC=au

So after all of that I guess here’s what I’ve learned:

• Sometimes dnsRecord rank flag can get corrupted (unknown how, but seems there’s been some samba bugfixes with re. to input validation for that) and show up as DNS_RANK_NONE. But it causes the record to disappear from RSAT but remain resolvable via lookup for clients.
• Due to bug 39637 deleted reverse zones in S4 are not deleted in UDM. Manually removing from UDM works.
• But it looks like you can resync back over from UDM and get a corrected dnsRecord attribute come across.
• resync_from_ucs script seems to only work on a single object and does not bring over child records. So do them one at a time.

I’ll go and look for any other occurances of DNS_RANK_NONE attributes in the directory and fix them. Trickier if they’re in the forward zones as I imagine deletes will be synced to UDM in that case.

But learnt a lot!

[pp303]

So, I have 39 DNS records with RANK_NONE

• 36 x PTRs
• 2 x CNAMEs
• 1 x DNS_TYPE_TOMBSTONE
  I’ll go through and manually fix the PTRs up with the delete and re-sync method, investigate the tombstone record and work out something for the CNAMEs (delete in ADSI and recreate in UDM I’m guessing).

Thanks again Mosu, unless I’ve missed something I think I’ve worked it out (other than what caused it).

edit: re-sync from ucs script fixed PTRs and CNAMEs, I did have to delete the tombstone entry (but it was a decommisioned PC anyway).

I think totally clear now.

MarkR.

[Moritz_Bunkus]

Hey,

very interesting to read.

@pp303

It brings over the toplevel domain object but none of the child PTR records. Is that intended usage of the script? You have to call each child record manually?

Yes, that’s the intended behavior: sync only that one object. Otherwise you might end up syncing a lot more than you intended to. You can easily script around this with something like:

univention-ldapsearch -b <parent-DN> -o ldif-wrap=no | grep '^dn:' | sed -e 's/^dn: //' | while read DN; do
  /usr/…/resync… $DN
done

Great that you managed to repair your setup, and I wholeheartedly agree with this observation:

@pp303

But learnt a lot!

As frustrating as chasing such issues down can be, it gives you a whole other kind of insight into the system.

Kind regards,
mosu