Thanks Rowland. Perhaps because I expected these basic issues to have been resolved long ago I never thought to check the SOA records. You are perfectly correct - the second DC is not listed. I will say however that other than this, All the DNS issues I encountered during my early testing phase, and there were a lot of them, occurred with both internal and BIND DNS. As a consequence, we use Samba DNS only for the AD domain and external BIND (on the same machine but on a separate IP address) for everything else. machines point to the Samba DNS servers, which forward to BIND for non-domain queries. Not an ideal solution perhaps but one which definitely works, solved every issue we encountered and is completely transparent to the users. regards, John On 29/02/16 07:40, Rowland penny wrote:> On 28/02/16 20:25, John Gardeniers wrote: >> Hi Rowland, >> >> Would you care to elaborate on that last sentence? I've not seen that >> mentioned before and I'm very curios about your reasons for saying >> it, especially as we're using internal DNS for our two DCs. >> >> regards, >> John >> >> > > OK, two main reasons, I have never used the internal dns server and I > have never had any real dns problems, read a lot of posts from people > who have, but they use the internal dns server. The second reason is > that the internal dns server seems to ignore the SOA record for the > second DC (note that you have to add this manually). Bind9 does see > both SOA records and the second DC is authoritative for the domain if > the first DC goes down for any reason, this doesn't happen with the > internal dns server. > > Rowland > >
Am 28.02.2016 um 22:22 schrieb John Gardeniers:> Thanks Rowland. Perhaps because I expected these basic issues to have > been resolved long ago I never thought to check the SOA records. You are > perfectly correct - the second DC is not listedsince when is more than one NS listed in the SOA? http://rscott.org/dns/soa.html MNAME ("Primary NS") - This entry is the domain name of the name server that was the original source of the data (this entry MUST be your primary nameserver). This is your primary nameserver, and MUST be the one and only server that you ever update. You must not update the secondary server(s) -- they will update automatically, based on this the SOA record. Problem? This should be a fully qualified domain name . -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20160228/d79a0797/signature.sig>
On 28/02/16 21:56, Reindl Harald wrote:> > > Am 28.02.2016 um 22:22 schrieb John Gardeniers: >> Thanks Rowland. Perhaps because I expected these basic issues to have >> been resolved long ago I never thought to check the SOA records. You are >> perfectly correct - the second DC is not listed > > since when is more than one NS listed in the SOA? > > http://rscott.org/dns/soa.html > > MNAME ("Primary NS") - This entry is the domain name of the name > server that was the original source of the data (this entry MUST be > your primary nameserver). This is your primary nameserver, and MUST be > the one and only server that you ever update. You must not update the > secondary server(s) -- they will update automatically, based on this > the SOA record. Problem? This should be a fully qualified domain name . > > >OK, I see where you are coming from, but, this is referring to a normal dns server that replicates to other secondary dns servers. AD dns works a little differently, all AD dns servers replicate dns records to each other and each AD DC is supposed to be authoritative for the dns domain, this does not happen if your first DC goes down when you are using the internal dns server. As an aside, my first DC shutdown for some reason, I didn't notice for a couple of hours, until I tried to 'ssh' into it, I didn't notice because *everything* else just kept working on my second DC. Rowland