This didn't work....

Lawrence K. Chen, P.Eng. lkchen at ksu.edu
Fri Apr 26 21:25:25 UTC 2013


Had a strange problem where our servers couldn't resolve hosts in an AD subdomain.

This was in the zone file:

 $ORIGIN foo.example.com.
 ...
 ads     NS     ads.foo.example.com
 ...
 ...
 ...
 ads     A      a.b.c.d
 ...
 ...
 ...

They said if you used their ADS for lookups, things worked...except they can't resolve anything else using it. (there appears to be a problem with DNS interference from their firewall.)  Plus, if it worked...they wouldn't be able to resolve hosts in our internal view....  But, they can't resolve hosts in their ADS domain using our DNS.

It's not clear where the users are w.r.t. this firewall.  But, since we can reproduce the issue...guessing outside....its probably a datacenter firewall rather than the department.

So, got the NS changed...though they said the way it was done is how Microsoft says their supposed to do it.

Evidently... on their side it resolves ads.foo.example.com resolves to 

  a.b.c.d
  a.b.c.e - dc2
  a.b.c.f - dc3

So changing to:

 $ORIGIN foo.example.com
 ...
 ads      NS     dc2.foo.example.com.
          NS     dc3.foo.example.com.
 dc2      A      a.b.c.e
 dc3      A      a.b.c.f
 ...

Still doesn't work....'dig +trace ads.foo.example.com' worked, but 'dig ads.foo.example.com' doesn't....and 'dig +trace host.ads.foo.example.com' appears to work, but 'dig host.ads.foo.example.com' doesn't.  Meanwhile somebody else happened to be doing a network capture, and they see dc2.foo.example.com replying to our caching dns servers, but the dns servers aren't answering.

I then notice that the dig responses aren't authoritative.

How do you have an AD domain where your AD servers aren't authoritative for itself?

I assume that's the problem now...or is there something else on my end that I should be looking at?

Meanwhile....if things do start working....the 'host.foo.example.com' that started this problem will resolve to a 10.b.c.d address.  Which is another problem I've been trying to quash...

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkchen at ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library


More information about the bind-users mailing list