I think I see it now. The A record that your NS record points to should be a record within the cloud.chx domain, not the ad.cloud.chx subdomain.
So you could do something like this: ad-ns1.cloud.chx 86400 IN A 192.168.1.253 ad.cloud.chx. 86400 IN NS ad-ns1.cloud.chx. Then if you query an a record in the subdomain (e.g. test.ad.cloud.chx) you should see the NS record in the authority section. On Tue, Aug 4, 2020 at 4:25 PM Christian Hernandez <[email protected]> wrote: > > > > > On Sun, Aug 2, 2020 at 6:43 PM John Petrini <[email protected]> wrote: >> >> I believe what you're seeing is normal behavior. If you ran that query >> against a TLD you'd get the NS servers of the TLD in the answer >> section but I don't believe it works that way when delegating >> subdomains. >> >> I just tested in my environment and when I query an a-record in the >> delegated subdomain the proper NS records appear in the authority >> section but I do not get a response querying for NS records directly >> against a delegated subdomain. > > > Shouldn't my TLD tell the client where to get that record though? > > In my case I have cloud.chx and I delegated ad.cloud.chx to my Windows DNS > server. > > When a query comes to the NS of cloud.chx it should get that answer from the > NS of ad.cloud.chx right? There's something I must be missing on the IPA side > because when I try this setting from a BIND to BIND set up...it works as > expected. > > [root@ns1 ~]# dig test.ad.example.com > > ; <<>> DiG 9.11.21-RedHat-9.11.21-1.fc32 <<>> test.ad.example.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56885 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: bcf0f0a951a4c7fc9bac74fd5f29c35a5305f69d279f3827 (good) > ;; QUESTION SECTION: > ;test.ad.example.com. IN A > > ;; ANSWER SECTION: > test.ad.example.com. 604628 IN A 172.16.1.101 > > ;; AUTHORITY SECTION: > ad.example.com. 604800 IN NS dc1.ad.example.com. > > ;; ADDITIONAL SECTION: > dc1.ad.example.com. 604358 IN A 172.16.1.206 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Tue Aug 04 13:21:46 PDT 2020 > ;; MSG SIZE rcvd: 126 > > > On my IPA server, this setup (this is the live setup) isn't working... > > [root@ipa1 ~]# dig dc1.ad.cloud.chx > > ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> dc1.ad.cloud.chx > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64904 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;dc1.ad.cloud.chx. IN A > > ;; Query time: 13 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Tue Aug 04 13:24:16 PDT 2020 > ;; MSG SIZE rcvd: 45 > > [root@ipa1 ~]# dig cloud.chx AXFR | grep dc1 > ad.cloud.chx. 86400 IN NS dc1.ad.cloud.chx. > dc1.ad.cloud.chx. 86400 IN A 192.168.1.253 > > _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
