> Probably should've wrote that is the first case it was: > > $ORIGIN foo.example.com. > ... > ads NS ads.foo.example.com. > ... > ads A a.b.c.d > dc2 A a.b.c.e > dc3 A a.b.c.f > > And, the modified case was: > > $ORIGIN foo.example.com > ... > ads NS dc2.foo.example.com. > NS dc3.foo.example.com. > ... > ads A a.b.c.d > dc2 A a.b.c.e > dc3 A a.b.c.f >
Okay--that helps. > > I didn't add dc2 or dc3...they were that way. And, they said those are > their primary and secondary ADS servers. > > But, the nameserver for (sub)domain can be anywhere....including in > somebody else's domain.... > > Sure can. But AD domain controllers are generally located within their own domain. I don't know enough about AD to tell you what would happen if someone put their domain controllers in another domain, but my guess is that there would be problems.... > ksu.edu's NS's are ns-1.ksu.edu, ns-2.ksu.edu, ns-3.ksu.edu, > nic.kanren.net, and kic.kanren.net. The registrar has the IP address of > ns-1.ksu.edu, ns-2.ksu.edu and ns-3.ksu.edu, so that it can included in > the additional section when their resolvers are hit.... > > Makes sense -- the .edu folks need to have your glue records. > And, its certain possible that the hosts true FQDN is > dc2.ads.foo.example.com, but they had put them into central DNS as > dc2.foo.example.com, before they had started doing ADS. It could also be > something else entirely...like bob.ads.foo.example.com. > > At this point, I'd forget about whatever they originally put into central DNS and just approach this fresh. > In fact, when I do a "dig +trace ads.foo.example.com", I get: > > ads.foo.example.com. 600 IN A a.b.c.e > ads.foo.example.com. 600 IN A a.b.c.f > ads.foo.example.com. 600 IN A a.b.c.d > ads.foo.example.com. 3600 IN NS dc2.ads.foo.example.com. > ads.foo.example.com. 3600 IN NS dc1.ads.foo.example.com. > ads.foo.example.com. 3600 IN NS dc3.ads.foo.example.com. > ads.foo.example.com. 3600 IN SOA dc3.ads.foo.example.com. > hostmaster. 1334667 900 600 86400 3600 > Nice. This is beginning to make more sense. Can you post the full dig +trace output? Feel free to pm me if you don't feel comfortable posting it to the list. > if I ask dc3.ads.foo.example.com what dc3.ads.foo.example.com is, it > answers a.b.c.f > if I ask dc3.ads.foo.example.com what dc2.ads.foo.example.com is, it > answers a.b.c.d and a.b.c.e > if I ask dc3.ads.foo.example.com what dc1.ads.foo.example.com is, it > answers a.b.c.g > > Perfect. Confirm that dc1 and dc2 also return the same answers. It sounds very much like you need to delegate ads to dc1, dc2, and dc3, plus put in glue that points dc1 to a.b.c.g, dc2 to a.b.c.d and a.b.c.e, and dc3 to a.b.c.f: $ORIGIN ads.foo.example.com. @ NS dc1.ads.foo.example.com. @ NS dc2.ads.foo.example.com. @ NS dc3.ads.foo.example.com. dc1 A a.b.c.g dc2 A a.b.c.d dc2 A a.b.c.e dc3 A a.b.c.f And that's all you should list. No need to create an A record for ads.foo.example.com -- let their own nameservers handle that. Hopefully I understand you correctly that you manage DNS for foo.example.com, and that ads.foo.example.com is delegated. If not, please let me know which subdomains you manage and which the department manages. It's entirely possible I've still misunderstood you. > So, I then tried: > > $ORIGIN ads.foo.example.com > @ NS dc2 > NS dc3 > dc2 A a.b.c.e > dc3 A a.b.c.f > > Which didn't help anything.... > > This seems correct, apart from not delegating to dc1 as well, and not including glue for both of the dc2 IPs. Any reason not to delegate/glue dc1 as well? > Anyways...I guess at this point the problem lies with the ADS setup.... > > Definitely could be. But make sure your delegation is rock-solid first. Please post the full output (both A and NS queries) of your normal dig queries for ads.foo.example.com and your dig +trace ads.foo.example.com. Please also post your full zone config for foo.example.com and ads.foo.example.com. Ok to pm me if you'd rather not post those to the list. John
_______________________________________________ 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
