Hi Rick. It would be more useful if you provided full output of DIG. There should not be any private information. If there are private IPs, just replace them.
I would start with dig @corpdc12.na.ads.idt.com -t NS eng.idt.com. If it does not know your domain as I expect, you would get NXDOMAIN. You have to delegate eng.idt.com. from idt.com. domain. IN Bind zone file, it would look somehow like this: eng.idt.com. IN NS ns1-eng.idt.com. eng.idt.com. IN NS ns2-eng.idt.com. Parent domain has to know IPs of delegated name servers. That is why I used ns1-eng instead of ns1.eng. You would have to add also glue IP addresses if ns1.eng.idt.com were used. eng.idt.com. IN NS ns1.eng.idt.com. eng.idt.com. IN NS ns2.eng.idt.com. ns1.eng.idt.com. IN A 10.2.3.4 ns2.eng.idt.com. IN A 10.5.6.7 I do not know how delegation from parent domain is done in AD. You have to contact administrator of idt.com to add your domain. Change that would force all company clients would use your server, that already knows your domain without delegation, is not the best one. Do you want to keep that domain internal only? Dne 29.1.2018 v 22:18 Reineman, Rick napsal(a): > I recently migrated our internal DNS service to a newer OS and Bind. Bind > 9.9.4 on CentOS7. I am a third level zone off the corporate zone, > eng.idt.com (Engineering) > > In general things are working pretty well but I have one really odd problem > that I am struggling with. > > Our Windows desktops are all on a different Active Directory/DNS domain (from > the Engineering UNIX hosts) as you would expect. Out of all of my > Engineering DNS records one of them will not resolve from the Windows > desktops, bugzilla.eng.idt.com. Everything else appears to be working fine > from any Windows desktop. > > The only Enterprise level change made was to the corporate zone (idt.com) to > change the IP for zone resolution to my two new servers. > > I have some dig output to demonstrate the issue. Both are from my Windows > desktop, one uses the new Engineering DNS server and the other one uses one > of the AD servers. I have tested several AD servers, just posting the output > of one. > > Dig using the Engineering DNS (good response): > C:\Program Files\dig\bin>dig @ns1.eng.idt.com bugzilla.eng.idt.com > > ;; ANSWER SECTION: > bugzilla.eng.idt.com. 86400 IN A 157.165.1.120 > ;; AUTHORITY SECTION: > eng.idt.com. 86400 IN NS ns1.eng.idt.com. > eng.idt.com. 86400 IN NS ns2.eng.idt.com. > > Dig using one of the AD/DNS servers (bad response): > C:\Program Files\dig\bin>dig @corpdc12.na.ads.idt.com bugzilla.eng.idt.com > > ;; AUTHORITY SECTION: > eng.idt.com. 312 IN SOA ns1.eng.idt.com. > root.eng.idt.com. 2018012901 10800 900 604800 86400 > > > I sure could use a suggestion. > > Thanks, > Rick > > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
