----- Original Message ----- 

> Hi Lawrence,

> I'm going to answer your questions a bit out of order, but hopefully
> things'll still be clear.

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

> This is how our AD domain is set up -- the root of the AD domain is
> brandeis.edu , but the domain controllers do not run the MS DNS
> Server service. Client computers get the main campus DNS resolvers
> via DHCP, and are set not to use the MS DNS Client service. We've
> set up dynamic zones in BIND for the zones needed by AD: _
> msdcs.brandeis.edu , _ tcp.brandeis.edu , _ udp.brandeis.edu , etc.

> Microsoft TechNet has some really thorough docs on this:

> http://technet.microsoft.com/en-us/library/dd316373.aspx

> It's a bit dated, but the principles still apply. The more general
> Microsoft docs:

> http://technet.microsoft.com/en-us/library/cc759550%28v=ws.10%29.aspx
> http://technet.microsoft.com/en-us/library/cc772774%28v=ws.10%29.aspx

> are also quite good.


That might work if only windows machines were needing to find hosts in AD.  
But, none of the people trying to access the host were using Windows.  In 
central AD there are a lot of public facing systems....and, they resolve fine 
for everybody.

But, trying:

host -a _msdcs.ads.foo.example.com results in SERVFAIL

And, trying central ADS:

host -a _msdcs.ads.example.com results in lots of NS records, with authority 
section and additional section (some A records)

Still doesn't explain why its not giving authoritative responses back for 
campus DNS resolvers to return to users.



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

> Can you clarify the problem a bit here? Is it that the authoritative
> nameservers for foo.example.com are unable to resolve
> ads.foo.example.com ? Do the foo.example.com servers look to
> themselves for recursion? Am I correct that a department on campus
> is running their own AD environment with a root of
> ads.foo.example.com , and you simply delegate the subdomain to them?

No, there's an excessive number of authoritative nameservers for example.com (5 
secondaries, a stealth master, a ton of stealth secondaries - 16?)

The 

$ORIGIN foo.example.com
...
ads NS ads.foo.example.com
...
...

is a portion in the example.com zone file.

And, its users that are unable to resolve (host.)ads.foo.example.com using the 
campus resolvers.

> > This was in the zone file:
> 

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

> This looks pretty normal if you're delegating the ads.foo.example.com
> zone to a server called ads.foo.example.com . A little confusing to
> use the same name for the nameserver as the subdomain itself, but it
> seems like it should work.

When I did a dig for ads.foo.example.com, I got NXDOMAIN, and going in for more 
depth, I got NSEC3 records proving the address didn't exist.


> > 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
> 
> > ...
> 

> This looks very odd indeed. If the root of the AD domain is
> ads.foo.example.com , why do the DCs live in the parent zone? Is
> that something you allow? The first zone config looked more
> appropriate.

> Without going any further into this, it looks as though the
> department may have set their AD domain up as " foo.example.com "
> when in reality it should be " ads.foo.example.com ." Can you
> clarify this?

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

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....

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....

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.

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

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

Another department on campus had ns-1.bar.example.com listed as their NS (with 
us as secondaries for them), but then they said they that their primary NS was 
failing on bond, so they wanted to switch to bund.  But, neither names were 
known to my predecessor.  And, their MX was apparently the same as their NS. 
... so poof they disappeared in a puff of magic smoke, well at least their 
website still worked....or rather their old one.  I couldn't email them to ask 
what they were talking about.  And, nobody seemed to know anything about this 
department.  Would see the occasional admin asking how they were supposed to 
deliver mail to the domain.... Apparently some kind of tech transfer group that 
has changed names a bunch of times, but still keep all their old domains 
around.  It was only recently they finally asked why their subdomain had 
vanished completely...before it just seemed stale.

Well, I upgraded from 9.7 to 9.9, and it nuked all the old secondary zone 
files. :)

Though it does appear that if they say ns-1.bar.example.com is their NS, it 
should exist on their NS...while I can resolve bar.example.com, I can't resolve 
ns-1.bar.example.com, even though it worked because the subdomain resolved.  
ns-2.bar.example.com is not listed as NS and I have no glue record for it, but 
it resolves to the IP that was given to me as ns-1.bar.example.com.  Only came 
across this fact when I was named-compilezone to view secondary files, and it 
complained that ns-1.bar.example.com has no A or AAAA record.

And, it is certainly permissible for them to have provided IPs for 
dc2.ads.foo.example.com & dc2.ads.foo.example.com to have a the glue records.

There are a number of subdomains that already exist and apparently work....

$ORIGIN net.example.com.
@     NS  net1
@     NS  net2
net1  A   a.b.c.g
net2  A   a.b.c.h

Though named-compilezone complained :

zone example.com/IN: net.example.com/NS 'net1.net.example.com' (out of zone) 
has no addresses records (A or AAAA)
zone example.com/IN: net.example.com/NS 'net2.net.example.com' (out of zone) 
has no addresses records (A or AAAA)

But, turns out this seems to be the only non-central AD in our main zone file 
that seems to work fine from my window-less and Window-less cubicle (in the 
basement of the library.)  I know college of engineering has a bunch of AD 
server, possibly in each of their departments....but the college has their own 
pair of authoritative nameservers for most of their departments, and various 
other domains.  Mechanical and Nuclear engineering was an exception, they used 
to do it themselves but then they had us take their subdomain back a couple 
years ago...and recently they stopped doing their own email.

And, it appears that its a similar case here again....the names net1/net2 don't 
exist in net.example.com, but net1v/net2v exist and those are what point to the 
IPs provided.

Interesting about the messages named-compilezone emitted.... wonder why they 
hadn't come up before.  Suppose its something that 9.9.2-P2 does now....that 
9.9.2-P1 didn't?  Though checkzone is something we have turned off and don't do 
regularly, because there's a lot of stuff in our zone file it doesn't 
like...like underscores in host names.  Or no AAAA clue records for nameservers 
claim to have them.  We don't allow IPv6 across the border....IT security 
blocks the tunneling protocols.

> John

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....

Anyways...I guess at this point the problem lies with the ADS setup....

-- 

-- 
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: lkc...@ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library
_______________________________________________
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

Reply via email to