This didn't work....

Mon Apr 29 22:29:32 UTC 2013

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