[Samba] which DNS backend ?

mathias dufresne infractory at gmail.com
Tue Mar 1 10:43:24 UTC 2016


2016-03-01 11:16 GMT+01:00 Rowland penny <rpenny at samba.org>:

> On 01/03/16 10:07, mathias dufresne wrote:
>
>> 2016-02-28 23:42 GMT+01:00 Reindl Harald <h.reindl at thelounge.net>:
>>
>>
>>> 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
>>>
>>>
>>> NS: name servers. Servers which can be used to ask for IP address for a
>> specified zone. They are authoritative (meaning their replies are the
>> right
>> replies, they are the authority.)
>>
>> Note about NS: this knid of record is not used by clients but only by DNS
>> servers. When a client need to find an IP it sends DNS name to configured
>> DNS server. This configured DNS server look into its own zones, tries to
>> resolve the name and, sometimes, forward the query to upper DNS servers.
>> For me the only moment where NS record are used is that very specific kind
>> of request.
>> Ex: client wants to resolve intranet.ibm.li, client send request to
>> configured-DNS-server for intranet.ibm.li.
>> Configured-DNS-server is not able to resolve that name, the
>> configured-DNS-server must find NS for ibm.li.
>> Configured-DNS-server send request to ROOT server for .li, asking for NS
>> for ibm.li zone.
>> Configured-DNS-server receives list of NS for ibm.li, use one of them to
>> send request for intranet.ibm.li to one of these DNS which are
>> authoritative for ibm.li.
>>
>> SOA: start of authority. All name servers for a zone are authoritative,
>> for
>> answers. With standard Bind and standard DNS config, only DNS server is
>> declared as master. This master can modify the zone _file_. This zone
>> _file_ is pushed from master to slaves. SOA is DNS server which can modify
>> the zone content.
>>
>> As explained Rowland, in AD all DNS servers can modify the zone content.
>> All DNS server which can modify the zone is SOA. So in AD all DNS servers
>> are SOA.
>>
>>
> Not from my experience :-)
> If you use the internal dns server on Samba AD and have multiple DCs, only
> the first DC will be authoritative, so not all Samba4 DCs are SOA.
>
>
> Rowland
>
>
We know DNS management is quiet complex and also that it needs improvement
into Samba4, especially when Samba is running AD domain.

The fact only one DNS server is authoritative with Samba4 as AD with
internal DNS is the fact DNS updates are done by samba_dnsupdate which is
using nsupdate which, in turn, is relying on DNS protocol.

Explanations:
nsupdate has an update to push to some zone (in our case, AD zone).
nsupdate ask to DNS for SOA of the zone it has to modify. This behaviour is
respecting DNS protocol as modifications must be done on SOA server.
nsupdate receives IP adress of SOA for the zone to modify and send the
modification to that zone.

Why this does not work everytime with internal DNS backend?
Because Samba internal DNS server knows only one SOA. This SOA is done, no
more update launched.

Please note I don't speak about standard resolution. For clients resolving
DNS from AD zones internal DNS is working, even if you shutdown the DC
tagged as SOA. This because SOA records as nothing to do with DNS
resolution but only with DNS modification.
Same for NS. No matter for standard work there only one NS created by Samba
(when Samba should create one NS by DNS server, and MUST remove NS record
when switching to NO-DNS backend). As I described in previous mail, NS are
used for name resolution when one name server must ask to another name
server.


More information about the samba mailing list