samba - Mar 2016 - which DNS backend ?

On 28/02/16 22:42, Reindl Harald wrote:
>
>
> Am 28.02.2016 um 23:10 schrieb Rowland penny:
>> 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
>
> well, that's not the business of the SOA record
> it's a matter of NS-records
>
>
>
If you only have one Authoritative nameserver (which is what you have 
with the internal dns) and it disappears, then you don't have *anything* 
that will respond to a request for info about AD dns domain.

Rowland

Am 28.02.2016 um 23:54 schrieb Rowland penny:
> On 28/02/16 22:42, Reindl Harald wrote:
>>
>>
>> Am 28.02.2016 um 23:10 schrieb Rowland penny:
>>> 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
>>
>> well, that's not the business of the SOA record
>> it's a matter of NS-records
>>
>
> If you only have one Authoritative nameserver (which is what you have
> with the internal dns) and it disappears, then you don't have
*anything*
> that will respond to a request for info about AD dns domain
sorry, but that's not a matter of SOA

all your NS-records are authoritative, no matter if the yare master or

slave, the format of the SOA record is pretty clear

https://support.dnsimple.com/articles/soa-record/
ns1.dnsimple.com admin.dnsimple.com 2013022001 86400 7200 604800 300

nothing will change the SOA format because it's defined far away from 
samba and the implementation https://www.ietf.org/rfc/rfc1912.txt

otherwise show me how you imageine a SOA record listing more than one 
nameserver would look like when the second filed is by defintion the 
admin contact

-------------- 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/20160229/bc7eb104/signature.sig>

On 28/02/16 23:05, Reindl Harald wrote:
>
>
> Am 28.02.2016 um 23:54 schrieb Rowland penny:
>> On 28/02/16 22:42, Reindl Harald wrote:
>>>
>>>
>>> Am 28.02.2016 um 23:10 schrieb Rowland penny:
>>>> 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
>>>
>>> well, that's not the business of the SOA record
>>> it's a matter of NS-records
>>>
>>
>> If you only have one Authoritative nameserver (which is what you have
>> with the internal dns) and it disappears, then you don't have
*anything*
>> that will respond to a request for info about AD dns domain
>
> sorry, but that's not a matter of SOA
>
> all your NS-records are authoritative, no matter if the yare master or
>
> slave, the format of the SOA record is pretty clear
>
> https://support.dnsimple.com/articles/soa-record/
> ns1.dnsimple.com admin.dnsimple.com 2013022001 86400 7200 604800 300
>
> nothing will change the SOA format because it's defined far away from 
> samba and the implementation https://www.ietf.org/rfc/rfc1912.txt
>
> otherwise show me how you imageine a SOA record listing more than one 
> nameserver would look like when the second filed is by defintion the 
> admin contact
>
>
>
Everything you say is valid except for when it comes to AD dns.
When you want data from a zone, you start with the SOA record, you ask 
'who holds the records for this zone?', it replies with the nameserver 
that holds the zone records. OK so far ?

Only problem is that with AD, *every* DC that runs a dns server holds 
the zone records. Now if you have only one NS record in the SOA (or if 
only one NS record is returned, like the internal dns server does), then 
only one DC will be asked for the zone records, if this DC is down, you 
don't have a nameserver to ask!

Every windows DC that runs a dns server is authoritative for the dns 
domain and has a SOA record. The only way I have found of doing this 
with a Samba DC, is to use Bind9 and add the second DCs NS record to the 
SOA, this SOA is stored in AD.

Rowland

2016-02-28 23:54 GMT+01:00 Rowland penny <rpenny at samba.org>:
> On 28/02/16 22:42, Reindl Harald wrote:
>
>>
>>
>> Am 28.02.2016 um 23:10 schrieb Rowland penny:
>>
>>> 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
>>>
>>
>> well, that's not the business of the SOA record
>> it's a matter of NS-records
>>
>>
>>
>>
> If you only have one Authoritative nameserver (which is what you have with
> the internal dns) and it disappears, then you don't have *anything*
that
> will respond to a request for info about AD dns domain.
>
>
You can have several DC running Samba with Internal DNS backend. They are
all authoritative. They are authoritative for answering as they are name
servers. They could be authoritative for modifying zone as there is no
master/slave notion with AD DNS server which are not using one flat file as
source but they are using a shared database (LDAP).

I did have several Samba DC in my AD domain using all internal DNS backend
with failover working. What wasn't working was samba_dnsupdate and so
auto-modification of AD DNS when needed (this because of nsupdate -g by
default in smb.conf and because nsupdate -g implies users dns-<DCname> are
created with needed keytab. This user is deleted by Samba when switching to
internal DNS backend and so nsupdate -g can't work).

2016-02-29 0:05 GMT+01:00 Reindl Harald <h.reindl at thelounge.net>:
>
>
> Am 28.02.2016 um 23:54 schrieb Rowland penny:
>
>> On 28/02/16 22:42, Reindl Harald wrote:
>>
>>>
>>>
>>> Am 28.02.2016 um 23:10 schrieb Rowland penny:
>>>
>>>> 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
>>>>
>>>
>>> well, that's not the business of the SOA record
>>> it's a matter of NS-records
>>>
>>>
>> If you only have one Authoritative nameserver (which is what you have
>> with the internal dns) and it disappears, then you don't have
*anything*
>> that will respond to a request for info about AD dns domain
>>
>
> sorry, but that's not a matter of SOA
>
> all your NS-records are authoritative, no matter if the yare master or
>
> slave, the format of the SOA record is pretty clear
>
> https://support.dnsimple.com/articles/soa-record/
> ns1.dnsimple.com admin.dnsimple.com 2013022001 86400 7200 604800 300
>
> nothing will change the SOA format because it's defined far away from
> samba and the implementation https://www.ietf.org/rfc/rfc1912.txt
>
> otherwise show me how you imageine a SOA record listing more than one
> nameserver would look like when the second filed is by defintion the admin
> contact
>
>
Several SOA is easy to design without breaking RFC: as every DNS server in
AD is able to modify the zone, every DNS server in AD is SOA. As any DNS
server is SOA and only one SOA can be returned, these DNS server must reply
"I am SOA".
10 DC running a DNS server.
One client asking to DC07 for SOA.
DC07 replies "SOA is DC07".
One client asking to DC02 for SOA.
DC02 replies "SOA is DC02".

This client ask for NS, all DNS server will reply 10 entries, one per DC
which is name server.

A DC don't need to be name server.