Home / server / Questions

Questions[freeipa](server)

Martin Hope
okapi
Asked: 2024-01-23 01:22:29 +0800 CST
  • 6

I've got a setup with a primary and replica FreeIPA server and a number of clients. When taking the primary server down briefly for an OS upgrades, everything became really slow. To simulate this, I tried blocking the primary server in a firewall rule on a test client with the same results.

Is it not supposed to just automatically switch over to talking to the replica instead? ipa hostgroup-show ipaservers lists both servers. /etc/ipa/default.conf on the clients does only list the primary server. Is there a quick way to switch dozens of clients to the replica in a single step? And if not, short of uninstalling and reinstalling IPA on a client how do I safely move it to a replica. In general, is it unwise to balance load by distributing clients across the two servers – I'd assume that would be sensible. I'm using ansible-freeipa to install and deploy FreeIPA.

freeipa
Martin Hope
YuvGM
Asked: 2022-02-06 04:51:16 +0800 CST
  • 3

I've installed an NFS server on Ubuntu 20.04 and a FreeIPA Ubuntu 20.04 client with the users home directories served by the NFS server. Performance is extremely slow when accessing files. When I strace the process with time spent in syscalls, I find that openat can take over 1 second at times for the NFS files! (see below). Needless to say file access on the server displays no such issue. openat is the only slow operation.

I've attached a histogram of the times spent in openat (I've trimmed the top bin so the tail can be seen). There are over 800 openat calls that complete in under 10mSec, but it's the tail that makes the difference in the total time, and there are a lot of calls that take over 100mSec which is unreasonable.

I suspect it may have to do with the Kerberos authorisation or something of the kind, but I don't know how to investigate the issue.

Options in /etc/exports:

/home   *(rw,sec=krb5:krb5i:krb5p,async,no_subtree_check)

Mount on client:

server:/home/... on /home/... type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5,clientaddr=xx.xx.xx.x1,local_lock=none,addr=xx.xx.xx.x2)

Any help or clue would be appreciated,

Yuval.

0.000064 : stat("/home/.../lib/python3.8/site-packages/pandas/core", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
0.000040 : stat("/home/.../lib/python3.8/site-packages/pandas/core/nanops.py", {st_mode=S_IFREG|0664, st_size=50002, ...}) = 0
0.000095 : stat("/home/.../lib/python3.8/site-packages/pandas/core/nanops.py", {st_mode=S_IFREG|0664, st_size=50002, ...}) = 0
0.664737 : openat(AT_FDCWD, "/home/.../lib/python3.8/site-packages/pandas/core/__pycache__/nanops.cpython-38.pyc", O_RDONLY|O_CLOEXEC) = 6
0.000122 : fstat(6, {st_mode=S_IFREG|0664, st_size=36431, ...}) = 0
0.000116 : ioctl(6, TCGETS, 0x7ffed1278d60)        = -1 ENOTTY (Inappropriate ioctl for device)
0.000049 : lseek(6, 0, SEEK_CUR)                   = 0
0.000024 : lseek(6, 0, SEEK_CUR)                   = 0
0.000028 : fstat(6, {st_mode=S_IFREG|0664, st_size=36431, ...}) = 0
0.000052 : read(6, "U\r\r\n\0\0\0\0\216t\362aR\303\0\0\343\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 36432) = 36431
0.000024 : read(6, "", 1)                          = 0
0.000438 : close(6)                                = 0
0.000083 : mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f23fcbaf000
0.000100 : stat("/home/.../bin", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
0.000120 : stat("/usr/lib/python3.8", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
0.000122 : stat("/usr/lib/python3.8/lib-dynload", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
0.000037 : getcwd("/home/yuval/src/themis", 1024)  = 23
0.000046 : stat("/home/yuval/src/themis", {st_mode=S_IFDIR|0775, st_size=130, ...}) = 0
0.000037 : stat("/home/.../lib/python3.8/site-packages", {st_mode=S_IFDIR|0775, st_size=12288, ...}) = 0
0.000051 : stat("/home/.../lib/python3.8/site-packages/pandas/core/array_algos", {st_mode=S_IFDIR|0775, st_size=163, ...}) = 0
0.000041 : stat("/home/.../lib/python3.8/site-packages/pandas/core/array_algos/masked_reductions.py", {st_mode=S_IFREG|0664, st_size=3721, ...}) = 0
0.000085 : stat("/home/.../lib/python3.8/site-packages/pandas/core/array_algos/masked_reductions.py", {st_mode=S_IFREG|0664, st_size=3721, ...}) = 0
0.411113 : openat(AT_FDCWD, "/home/.../lib/python3.8/site-packages/pandas/core/array_algos/__pycache__/masked_reductions.cpython-38.pyc", O_RDONLY|O_CLOEXEC) = 6
0.000053 : fstat(6, {st_mode=S_IFREG|0664, st_size=3329, ...}) = 0
0.000027 : ioctl(6, TCGETS, 0x7ffed1278d60)        = -1 ENOTTY (Inappropriate ioctl for device)
0.000043 : lseek(6, 0, SEEK_CUR)                   = 0
0.000037 : lseek(6, 0, SEEK_CUR)                   = 0
0.000025 : fstat(6, {st_mode=S_IFREG|0664, st_size=3329, ...}) = 0
0.000032 : read(6, "U\r\r\n\0\0\0\0\216t\362a\211\16\0\0\343\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 3330) = 3329
0.000025 : read(6, "", 1)                          = 0
0.000438 : close(6)                                = 0
0.000105 : stat("/home/.../lib/python3.8/site-packages/pandas/core/arrays", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
0.000102 : stat("/home/.../lib/python3.8/site-packages/pandas/core/arrays/categorical.py", {st_mode=S_IFREG|0664, st_size=94502, ...}) = 0
0.000101 : stat("/home/.../lib/python3.8/site-packages/pandas/core/arrays/categorical.py", {st_mode=S_IFREG|0664, st_size=94502, ...}) = 0
0.413090 : openat(AT_FDCWD, "/home/.../lib/python3.8/site-packages/pandas/core/arrays/__pycache__/categorical.cpython-38.pyc", O_RDONLY|O_CLOEXEC) = 6
0.000063 : fstat(6, {st_mode=S_IFREG|0664, st_size=77947, ...}) = 0
0.000041 : ioctl(6, TCGETS, 0x7ffed127b180)        = -1 ENOTTY (Inappropriate ioctl for device)
0.000037 : lseek(6, 0, SEEK_CUR)                   = 0
0.000023 : lseek(6, 0, SEEK_CUR)                   = 0
0.000031 : fstat(6, {st_mode=S_IFREG|0664, st_size=77947, ...}) = 0
0.000085 : read(6, "U\r\r\n\0\0\0\0\216t\362a&q\1\0\343\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 77948) = 77947

Histogram of time spent in openat for opening Python and importing pytorch

nfs kerberos freeipa
Martin Hope
Mutantoe
Asked: 2021-02-17 13:22:38 +0800 CST
  • 3

I am trying to add an entryUUID field to groups in the FreeIPA compat schema, but I am struggling to create the required attributeType. My LDIF for creating it is:

dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( entryUUID-oid
    NAME 'entryUUID'
    DESC 'UUID of the entry'
    EQUALITY uuidMatch
    ORDERING uuidOrderingMatch
    SYNTAX 1.3.6.1.1.16.1
    SINGLE-VALUE )

This is based on the specification from RFC4530, except with the USAGE directoryOperation and NO-USER-MODIFICATION lines removed. These need to be removed because the compat schema doesn't support operational attributes (I think). The error I get is as follows:

modifying entry "cn=schema"
ldap_modify: Invalid syntax (21)
        additional info: attribute type entryUUID: Unknown attribute syntax OID "1.3.6.1.1.16.1"

I don't think this makes much sense at all, since OID 1.3.6.1.1.16.1 should be built in, right? Obviously my next course of action was to try and redefine the syntax with a different OID, but there is no documentation of how to do that anywhere, so I suspect it's not possible. I then tried removing the SYNTAX line (not allowed), and setting the syntax to "domain string" (can't use the uuidMatch equality).

In case this is an XY problem, I'm doing this in order to get vSphere to link up with FreeIPA, since vSphere requires a entryUUID field.

To summarise:

  • How do I correctly add a custom UUID attribute to the compat schema?
  • Do I even need to?
ldap freeipa ldif
Martin Hope
ifndef
Asked: 2020-10-27 05:32:50 +0800 CST
  • 3

When mounting an NFSv4 with Kerberos, authentication fails and krb5kdc.log shows the wrong principal name for the NFS server.

LOOKING_UP_SERVER: ... host/[email protected] for nfs/[email protected]
... Server not found in Kerberos database

Principal nfs/containershost.internal.domain.tld should be nfs/nfs.internal.domain.tld.

Am I correct in assuming that a reverse DNS query is being performed which is returning containershost.internal.domain.tld? If so, at what step in the process (and from which machine) does this lookup happen?

$ dig -x 192.111.111.111
111.111.111.192.in-addr.arpa. 6009 IN PTR containershost.internal.domain.tld.

Is there a way to prevent this reverse DNS query from happening? The host at IP 192.111.111.111 (containershost.internal.domain.tld) is running multiple containers and so adding PTR records isn't possible.

Docker Container Host

Hostname: containershost.internal.domain.tld
IP: 192.111.111.111

FreeIPA Server (docker)

Image: freeipa/freeipa-server:centos-8-4.8.4
Container Name: freeipa
Container Host: containershost.internal.domain.tld
Hostname: freeipa.internal.domain.tld
IP: 172.222.222.222
Domain: ipa.domain.tld
Realm: IPA.DOMAIN.TLD
Keytab:

$ klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 host/[email protected]

/etc/krb5.conf:

[libdefaults]
    default_realm = IPA.DOMAIN.TLD
    dns_lookup_realm = false
    dns_lookup_kdc = true
    rdns = false
    ticket_lifetime = 24h
    forwardable = true
    udp_preference_limit = 0

[realms]
    IPA.DOMAIN.TLD = {
        kdc = freeipa.internal.domain.tld:88
        master_kdc = freeipa.internal.domain.tld:88
        admin_server = freeipa.internal.domain.tld:749
        default_domain = ipa.domain.tld
        pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
        pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
    }

[domain_realm]
    .ipa.domain.tld = IPA.DOMAIN.TLD
    ipa.domain.tld = IPA.DOMAIN.TLD
    freeipa.internal.domain.tld = IPA.DOMAIN.TLD
    .internal.domain.tld = IPA.DOMAIN.TLD
    internal.domain.tld = IPA.DOMAIN.TLD

NFS Server (docker)

Image: ubuntu:latest
Container Name: nfs
Container Host: containershost.internal.domain.tld
Hostname: nfs.internal.domain.tld
IP: 172.333.333.333
Running Services:

- /usr/sbin/rpc.mountd --port 32767 --no-nfs-version 2 --no-nfs-version 3 -F --debug all
- /usr/sbin/rpc.idmapd -S -vvv -f
- /usr/sbin/rpc.nfsd --debug --port 2049 --no-nfs-version 2 --no-nfs-version 3 -L 10 -G 10
- /usr/sbin/rpc.svcgssd -f -vvv -rrr -iii -p nfs/nfs.internal.domain.tld

Keytab:

$ klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
  74 host/[email protected]
  66 nfs/[email protected]

/etc/krb5.conf:

[libdefaults]
    default_realm = IPA.DOMAIN.TLD
    dns_lookup_realm = false
    dns_lookup_kdc = false
    rdns = false

[realms]
    IPA.DOMAIN.TLD = {
        kdc = freeipa
        admin_server = freeipa
        default_domain = domain.tld
    }

[domain_realm]
    .domain.tld = IPA.DOMAIN.TLD
    domain.tld = IPA.DOMAIN.TLD

NFS Client

OS: Ubuntu 20.04
Hostname: nfsclient.internal.domain.tld
IP: 192.444.444.444
Keytab:

$ klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
  5 host/[email protected]

Mount Command:

$ sudo mount -vvv -t nfs4 -o sec=krb5p 192.111.111.111:/ /mountpoint
mount.nfs4: trying text-based options 'sec=krb5,vers=4.2,addr=192.111.111.111,clientaddr=192.444.444.444'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting 192.111.111.111:/

Result

/var/log/krb5kdc.log:

freeipa krb5kdc[288](info): TGS_REQ (4 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23)}) 192.444.444.444: LOOKING_UP_SERVER: authtime 0, 
etypes {rep=(0)} host/[email protected] for nfs/[email protected], 
Server not found in Kerberos database
kerberos docker freeipa nfs4
Martin Hope
Vinícius Ferrão
Asked: 2020-07-03 15:59:46 +0800 CST
  • 3

Consider the following scenario:

example.com is hosted on CloudFlare and it's signed by CloudFlare DNSSEC. Everything works as expected for example.com.

Inside the company we have some internal privates zones, for Active Directory and a Unix Domain: ad.example.com and unix.example.com.

Since I cannot enable opt-out for those zones on example.com I just enabled DNSSEC for the internal zones. On unix.example.com everything appears to be working as expected. But on ad.example.com nothing works.

Basically the chain of trust is broken on the internal nameservers:

Jul  2 20:36:14 idm1 named-pkcs11[4345]: broken trust chain resolving 'wpad.ad.example.com/A/IN': 172.21.1.2#53
Jul  2 20:36:17 idm1 named-pkcs11[4345]: validating dc1.ad.example.com/A: bad cache hit (dc1.ad.example.com/DS)
Jul  2 20:36:17 idm1 named-pkcs11[4345]: broken trust chain resolving 'dc1.ad.example.com/A/IN': 172.21.1.2#53
Jul  2 20:37:18 idm1 named-pkcs11[4345]:  validating ad.example.com/SOA: got insecure response; parent indicates it should be secure
Jul  2 20:37:18 idm1 named-pkcs11[4345]: no valid RRSIG resolving 'dc1.ad.example.com/DS/IN': 172.21.1.2#53
Jul  2 20:37:18 idm1 named-pkcs11[4345]:  validating ad.example.com/SOA: got insecure response; parent indicates it should be secure
Jul  2 20:37:18 idm1 named-pkcs11[4345]: no valid RRSIG resolving 'dc1.ad.example.com/DS/IN': 172.21.1.3#53
Jul  2 20:37:18 idm1 named-pkcs11[4345]: no valid DS resolving 'dc1.ad.example.com/A/IN': 172.21.1.2#53
Jul  2 20:37:18 idm1 named-pkcs11[4345]: validating dc1.ad.example.com/A: bad cache hit (dc1.ad.example.com/DS)
Jul  2 20:37:18 idm1 named-pkcs11[4345]: broken trust chain resolving 'dc1.ad.example.com/A/IN': 172.21.1.3#53

I'm aware that I need to add DS records on the parent zone, so I added two entries on CloudFlare for ad.example.com and one for unix.example.com.

The DS entries where generated from a Linux machine with the following commands:

For unix.example.com:

dig unix.example.com. DNSKEY @172.21.1.5 > dnskey-unix.txt
dnssec-dsfromkey -f dnskey-unix.txt -2 unix.example.com

Then I added the following DS register on CloudFlare:

unix.example.com. IN DS 54355 8 2 3658D593EF31ED0E9D2369DF09D63F9B48FB5CD25A1AA336A2E4EE0AF55150AE

For ad.example.com:

dig ad.example.com. DNSKEY @172.21.1.2 > dnskey-ad.txt
dnssec-dsfromkey -f dnskey-ad.txt -2 ad.example.com

The same for unix.example.com, I've added the following on CloudFlare

ad.example.com. IN DS 63807 13 2 32D219185C727AE506B5565D522728D1B3A8677F737B07EC3BFEC2092B96F737
ad.example.com. IN DS 39922 13 2 000525D1A95F86820CA668D91E952BCCFA7000A5364A3E30AC43D3ACCDB62DAD

Since AD uses two separate zones I generated the DS entries for _msdcs.ad.example.com too:

dig _msdcs.ad.example.com. DNSKEY @172.21.1.2 > dnskey-ad-msdcs.txt
dnssec-dsfromkey -f dnskey-ad-msdcs.txt -2 _msdcs.ad.example.com

And added the results to it's parent zone: ad.example.com:

_msdcs.ad.example.com. IN DS 19659 13 2 9F1D143D601B976F05EAB6C1C14C998537B80511349B7BDEB0CFFE2A0882DAF3
_msdcs.ad.example.com. IN DS 14682 13 2 4B72A44979E24321724D870E17E85D7099260132A1645F236511F4FC545B98E8

And that's it. I tough this implementation would be correct, but this is not what's happening. For machines on the unix.example.com domain it's OK:

[root@idm1 ~]# dig +dnssec A idm1.unix.example.com

; <<>> DiG 9.11.13-RedHat-9.11.13-3.el8 <<>> +dnssec A idm1.unix.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21833
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 203752b5a85d2bb2c796f55b5efe71f71401f1abaf39c190 (good)
;; QUESTION SECTION:
;idm1.unix.example.com. IN  A

;; ANSWER SECTION:
idm1.unix.example.com. 1200 IN  A   172.21.1.5
idm1.unix.example.com. 1200 IN  RRSIG   A 8 5 1200 20200724170015 20200702220913 24543 unix.example.com. kVOJD49rzVaQLtLBdxyUTU2E+1CQscSClWjs7RgGj0nMAg/6Va1GEw0j jlDl2s1FOKxbJCN7g50UT+MjgTPkgQozwUPOBYeaKB6npTrROwZH3vBG yT346elPNP7x5fRO41ATUrf22PauCvo73+1+iTmTsizxVwda8u88H5Ld CD4+laE9GphuHdc2usITGaKze4UBwA81ExN2UpwOJYPhyHFzOAF3oBg8 XCPoJxQhgHNmkCAmTZCmWeD+kPkyaMSv9clF/23lZ9YJ+cICHtCzWWTM yEC7988sAk2MVIzptF0OYQ+TzsVDxcM8TPlhZNZAz+SE3hVPalY31TUc bm+DiQ==

;; AUTHORITY SECTION:
unix.example.com.   86400   IN  NS  idm2.unix.example.com.
unix.example.com.   86400   IN  NS  idm1.unix.example.com.
unix.example.com.   86400   IN  RRSIG   NS 8 4 86400 20200728184956 20200702220913 24543 unix.example.com. iVLmN9NkjI08NPMObfhDFh2csUnMkEmFTi0UhphhedbL2wFc1MsP37gS lwSXK8gjPiopC1gbfRj9d0BwG6fJCrc9+1DUnUMKDqqpsr2/U3prOJWs 70l+4m1S6OI5vemhGMZuSzfPW7hGnPCY3xzYnzMJ3atvPwBJzG5tx2Rd V59sYgJBc7LDZxhGJxxtc5V2cNbCo6q51zoDV8OeDMaBK5n6shhnbpOq 3mlTC757vYxzwl8akvWDvQtgTJhZKuye+PSBn3dyqIcoSr6ZG/Ymm23n l89DzpvNVwRw0xtw7lmvQWsj0w1RefPwKG9sytGjCNw9CZ30IIeqvE+o hPP3Gw==

;; ADDITIONAL SECTION:
idm2.unix.example.com. 1200 IN  A   172.21.1.6
idm2.unix.example.com. 1200 IN  RRSIG   A 8 5 1200 20200718050002 20200702220913 24543 unix.example.com. RSKi/wms8XQevqzqY/EnvApSKY4cMvTwZtPImyngb8EJ/ONBfljkZDrj YTIh36fg8UnDE4WeaDjhrLAEV0/7T5f1udC/Eje0i7ezH7F301/8qaQ9 1BHWOoK+viwisa5w4ywZMq6mTcZCGs+RpgudIcczkW4RlmW/zpRnqYjq f/U4a5GEXV64s7Nc7ZfMxvssM9r1QknX3XC8yWKPlgjCRn/be03bhA+z UNfNpBU1684q1/hTJ0f+d0BFtb1ZNkZ2TIceXCDIum8UQCEsH6XLjtYI x4TnKUtG7WVL65xKc7SecZY1v/Ew9hMtnmF42+9rV95Rj2vGdA+QJF98 8H1xJw==

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 02 20:47:03 -03 2020
;; MSG SIZE  rcvd: 1079

But not for machines on ad.example.com:

[root@idm1 ~]# dig +dnssec A dc1.ad.example.com

; <<>> DiG 9.11.13-RedHat-9.11.13-3.el8 <<>> +dnssec A dc1.ad.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9918
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 2c9efcfef9cb965cfc1898755efe7260ec5a94eb75e18a03 (good)
;; QUESTION SECTION:
;dc1.ad.example.com.    IN  A

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jul 02 20:48:48 -03 2020
;; MSG SIZE  rcvd: 83

Another relevant information; the name servers on the Unix domain are configured as forward only to the zones on AD, and vice-versa.

Questions:

  1. I'm not sure if I can set DNSSEC this way.
  2. On CloudFlare there's obviously no NS entries for the internal zones, they should not be visible from outside, although there's the DS entires for ad.example.com and unix.example.com; is this supported?

Thanks!

EDIT: I figured additional information with the help of @PatrickMevzek in the comments.

  1. Windows DNS Server wasn't validating DNSSEC. I had to manually enable it with command: DnsCmd.exe /Config /enablednssec 1

  2. Fetched the Root Trust Anchors after a Restart-Service DNS, with the command: DnsCmd.exe /RetrieveRootTrustAnchors

After this two commands on both dc1 and dc2; Linux's BIND9 was able to resolve the addresses without complaining about broken trust. It wasn't necessary to add the NS entries on CloudFlare.

But I have another issue when trying to validate on Windows DNS Servers; when using delv with +vtrace on BIND9 it works as expected:

[root@idm1 ~]# delv +vtrace dc1.ad.example.com.br @172.21.1.5
;; fetch: dc1.ad.example.com.br/A
;; validating dc1.ad.example.com.br/A: starting
;; validating dc1.ad.example.com.br/A: attempting positive response validation
;; fetch: ad.example.com.br/DNSKEY
;; validating ad.example.com.br/DNSKEY: starting
;; validating ad.example.com.br/DNSKEY: attempting positive response validation
;; fetch: ad.example.com.br/DS
;; validating ad.example.com.br/DS: starting
;; validating ad.example.com.br/DS: attempting positive response validation
;; fetch: example.com.br/DNSKEY
;; validating example.com.br/DNSKEY: starting
;; validating example.com.br/DNSKEY: attempting positive response validation
;; fetch: example.com.br/DS
;; validating example.com.br/DS: starting
;; validating example.com.br/DS: attempting positive response validation
;; fetch: com.br/DNSKEY
;; validating com.br/DNSKEY: starting
;; validating com.br/DNSKEY: attempting positive response validation
;; fetch: com.br/DS
;; validating com.br/DS: starting
;; validating com.br/DS: attempting positive response validation
;; fetch: br/DNSKEY
;; validating br/DNSKEY: starting
;; validating br/DNSKEY: attempting positive response validation
;; fetch: br/DS
;; validating br/DS: starting
;; validating br/DS: attempting positive response validation
;; fetch: ./DNSKEY
;; validating ./DNSKEY: starting
;; validating ./DNSKEY: attempting positive response validation
;; validating ./DNSKEY: verify rdataset (keyid=20326): success
;; validating ./DNSKEY: signed by trusted key; marking as secure
;; validating br/DS: in fetch_callback_validator
;; validating br/DS: keyset with trust secure
;; validating br/DS: resuming validate
;; validating br/DS: verify rdataset (keyid=46594): success
;; validating br/DS: marking as secure, noqname proof not needed
;; validating br/DNSKEY: in dsfetched
;; validating br/DNSKEY: dsset with trust secure
;; validating br/DNSKEY: verify rdataset (keyid=2471): success
;; validating br/DNSKEY: marking as secure (DS)
;; validating com.br/DS: in fetch_callback_validator
;; validating com.br/DS: keyset with trust secure
;; validating com.br/DS: resuming validate
;; validating com.br/DS: verify rdataset (keyid=33739): success
;; validating com.br/DS: marking as secure, noqname proof not needed
;; validating com.br/DNSKEY: in dsfetched
;; validating com.br/DNSKEY: dsset with trust secure
;; validating com.br/DNSKEY: verify rdataset (keyid=33095): success
;; validating com.br/DNSKEY: marking as secure (DS)
;; validating example.com.br/DS: in fetch_callback_validator
;; validating example.com.br/DS: keyset with trust secure
;; validating example.com.br/DS: resuming validate
;; validating example.com.br/DS: verify rdataset (keyid=33095): success
;; validating example.com.br/DS: marking as secure, noqname proof not needed
;; validating example.com.br/DNSKEY: in dsfetched
;; validating example.com.br/DNSKEY: dsset with trust secure
;; validating example.com.br/DNSKEY: verify rdataset (keyid=2371): success
;; validating example.com.br/DNSKEY: marking as secure (DS)
;; validating ad.example.com.br/DS: in fetch_callback_validator
;; validating ad.example.com.br/DS: keyset with trust secure
;; validating ad.example.com.br/DS: resuming validate
;; validating ad.example.com.br/DS: verify rdataset (keyid=34505): success
;; validating ad.example.com.br/DS: marking as secure, noqname proof not needed
;; validating ad.example.com.br/DNSKEY: in dsfetched
;; validating ad.example.com.br/DNSKEY: dsset with trust secure
;; validating ad.example.com.br/DNSKEY: no RRSIG matching DS key
;; validating ad.example.com.br/DNSKEY: verify rdataset (keyid=63807): success
;; validating ad.example.com.br/DNSKEY: marking as secure (DS)
;; validating dc1.ad.example.com.br/A: in fetch_callback_validator
;; validating dc1.ad.example.com.br/A: keyset with trust secure
;; validating dc1.ad.example.com.br/A: resuming validate
;; validating dc1.ad.example.com.br/A: verify rdataset (keyid=3675): success
;; validating dc1.ad.example.com.br/A: marking as secure, noqname proof not needed
; fully validated
dc1.ad.example.com.br. 3556 IN  A   172.21.1.2
dc1.ad.example.com.br. 3556 IN  RRSIG   A 8 5 3600 20200713013625 20200703003625 3675 ad.example.com.br. Ov1CyF1c7p7NoYWGx041NG76lXEI3gCMYECklGYSd5pqQDpgHP1P7Tuc 9/6WulDJBaHW0FAvAiclpH1M7xmzsSEHmTamnuMeHDP6zsgXTu7dmRr4 YLwH5lidELNt1wFffNfDFu6/xHuQcxWppgqf8so1zBhz/+TYQKFbvs+/ zOs=

But when I do the same query on Windows DNS Server it fails completely with a broken trust error:

[root@idm1 ~]# delv +vtrace dc1.ad.example.com.br @172.21.1.2
;; fetch: dc1.ad.example.com.br/A
;; validating dc1.ad.example.com.br/A: starting
;; validating dc1.ad.example.com.br/A: attempting positive response validation
;; fetch: ad.example.com.br/DNSKEY
;; validating ad.example.com.br/DNSKEY: starting
;; validating ad.example.com.br/DNSKEY: attempting positive response validation
;; fetch: ad.example.com.br/DS
;; chase DS servers resolving 'ad.example.com.br/DS/IN': 172.21.1.2#53
;; fetch: example.com.br/NS
;; validating example.com.br/NS: starting
;; validating example.com.br/NS: attempting positive response validation
;; fetch: example.com.br/DNSKEY
;; validating example.com.br/DNSKEY: starting
;; validating example.com.br/DNSKEY: attempting positive response validation
;; fetch: example.com.br/DS
;; validating example.com.br/DS: starting
;; validating example.com.br/DS: attempting positive response validation
;; fetch: com.br/DNSKEY
;; validating com.br/DNSKEY: starting
;; validating com.br/DNSKEY: attempting positive response validation
;; fetch: com.br/DS
;; validating com.br/DS: starting
;; validating com.br/DS: attempting positive response validation
;; fetch: br/DNSKEY
;; validating br/DNSKEY: starting
;; validating br/DNSKEY: attempting positive response validation
;; fetch: br/DS
;; validating br/DS: starting
;; validating br/DS: attempting positive response validation
;; fetch: ./DNSKEY
;; validating ./DNSKEY: starting
;; validating ./DNSKEY: attempting positive response validation
;; validating ./DNSKEY: verify rdataset (keyid=20326): success
;; validating ./DNSKEY: signed by trusted key; marking as secure
;; validating br/DS: in fetch_callback_validator
;; validating br/DS: keyset with trust secure
;; validating br/DS: resuming validate
;; validating br/DS: verify rdataset (keyid=46594): success
;; validating br/DS: marking as secure, noqname proof not needed
;; validating br/DNSKEY: in dsfetched
;; validating br/DNSKEY: dsset with trust secure
;; validating br/DNSKEY: verify rdataset (keyid=2471): success
;; validating br/DNSKEY: marking as secure (DS)
;; validating com.br/DS: in fetch_callback_validator
;; validating com.br/DS: keyset with trust secure
;; validating com.br/DS: resuming validate
;; validating com.br/DS: verify rdataset (keyid=33739): success
;; validating com.br/DS: marking as secure, noqname proof not needed
;; validating com.br/DNSKEY: in dsfetched
;; validating com.br/DNSKEY: dsset with trust secure
;; validating com.br/DNSKEY: verify rdataset (keyid=33095): success
;; validating com.br/DNSKEY: marking as secure (DS)
;; validating example.com.br/DS: in fetch_callback_validator
;; validating example.com.br/DS: keyset with trust secure
;; validating example.com.br/DS: resuming validate
;; validating example.com.br/DS: verify rdataset (keyid=33095): success
;; validating example.com.br/DS: marking as secure, noqname proof not needed
;; validating example.com.br/DNSKEY: in dsfetched
;; validating example.com.br/DNSKEY: dsset with trust secure
;; validating example.com.br/DNSKEY: verify rdataset (keyid=2371): success
;; validating example.com.br/DNSKEY: marking as secure (DS)
;; validating example.com.br/NS: in fetch_callback_validator
;; validating example.com.br/NS: keyset with trust secure
;; validating example.com.br/NS: resuming validate
;; validating example.com.br/NS: verify rdataset (keyid=34505): success
;; validating example.com.br/NS: marking as secure, noqname proof not needed
;; validating ad.example.com.br/DNSKEY: in dsfetched
;; validating ad.example.com.br/DNSKEY: falling back to insecurity proof (SERVFAIL)
;; validating ad.example.com.br/DNSKEY: checking existence of DS at 'br'
;; validating ad.example.com.br/DNSKEY: checking existence of DS at 'com.br'
;; validating ad.example.com.br/DNSKEY: checking existence of DS at 'example.com.br'
;; validating ad.example.com.br/DNSKEY: checking existence of DS at 'ad.example.com.br'
;; fetch: ad.example.com.br/DS
;; chase DS servers resolving 'ad.example.com.br/DS/IN': 172.21.1.2#53
;; fetch: example.com.br/NS
;; validating example.com.br/NS: starting
;; validating example.com.br/NS: attempting positive response validation
;; validating example.com.br/NS: keyset with trust secure
;; validating example.com.br/NS: verify rdataset (keyid=34505): success
;; validating example.com.br/NS: marking as secure, noqname proof not needed
;; validating ad.example.com.br/DNSKEY: in dsfetched2: SERVFAIL
;; no valid DS resolving 'ad.example.com.br/DNSKEY/IN': 172.21.1.2#53
;; validating dc1.ad.example.com.br/A: in fetch_callback_validator
;; validating dc1.ad.example.com.br/A: fetch_callback_validator: got SERVFAIL
;; broken trust chain resolving 'dc1.ad.example.com.br/A/IN': 172.21.1.2#53
;; resolution failed: broken trust chain
domain-name-system active-directory bind dnssec freeipa