As I already wrote here, the fact NS is not automatically filled is not an
issue as long as you don't plan to make your AD a public thing.
AD is not meant to be public, not really, or at least: not often.
Let's say you want to make your DNS zones public anyway (not the whole AD).
Will you make all your DC a public name server or will you before think
about what you are about to do and perhaps limit the risks using two DC to
do that job?
I would say you want to make your AD DNS zone public you will chose
yourself some of your DC to do that job. So if all DC are automagically
declared as NS it is for the whole AD, including the two public AD DNS.
So here we have 12 DC, 2 of them are public DNS. All 12 DC are declared as
NS. Our public AD domain name is "strange.it"
My client wants to connect on some "strange.it" server, first it send
to
its resolver some DNS request about
"strange.it", the resolver does not know the answer, it launches
recursion
process.
The recursion process is to ask others DNS for NS of "strange.it".
Here my
client receive 12 IP addresses as ALL DC are declared as NS. But 2 of these
12 DC are available as NS from Internet, my client has 1 chance on 6 to
continue the process to connect without reaching timeout...
Perhaps this dumb scenario is just a dumb view of my crazy mind on Friday
afternoon.
Perhaps that's why Microsoft (and Samba) decided to not add NS
automatically.
My 2 cents.
2016-08-19 15:25 GMT+02:00 Zane Zakraisek via samba <samba at
lists.samba.org>:
> Yes I shut down the original DC, and noticed most of the AD relient
> services were hanging, and I think the culprit was DNS on the new DC.
> Would you guys recommend waiting for 4.5, or switching to the BIND backend?
> The only reason that I chose the internal DNS server in the first place was
> that I thought Kai said the BIND side wasn't getting as much love these
> days.
>
> On Thu, Aug 18, 2016 at 6:38 PM, Garming Sam <garming at
catalyst.net.nz>
> wrote:
>
> > On 19/08/16 04:17, Rowland Penny via samba wrote:
> > > I couldn't find anything that explicitly says that each DC
should have
> > > its own SOA in AD. What I could find was that each AD-integrated
zone
> on
> > > a DC is expected to have a SOA record containing the DCs
ipaddress.
> > > this indicates that the DC hosts a writable copy of the zone. The
SOA
> > > should also contain an NS record for the DC. Whilst I do not know
how
> > > windows does this, the only way I have found to do all this, is
to
> > > add the DCs A & NS records to the SOA record, only problem
is, it
> > > only seems (for me) to work with Bind9 as the DNS server.
> > >
> >
> > I think Windows just clobbers the SOA on the way out. I don't
think I've
> > seen any documentation describe the behaviour in detail either.
> >
> > As for the missing record, Samba 4.5 should fix the immediate problem
of
> > the actual missing NS record, but currently only using BIND9 DLZ
> > actually ensures it is used as a useful nameserver.
> >
> >
> > Cheers,
> >
> > Garming
> >
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
>