samba - Nov 2015 - Authentication to Secondary Domain Controller initially fails when PDC is offline

On 11/20/2015 10:17 AM, mathias dufresne wrote:
>
>
> 2015-11-20 15:11 GMT+01:00 James <lingpanda101 at gmail.com 
> <mailto:lingpanda101 at gmail.com>>:
>
>     On 11/20/2015 7:40 AM, Ole Traupe wrote:
>
>
>
>         Am 20.11.2015 um 11:54 schrieb mathias dufresne:
>
>             Hi Ole,
>
>             I'm still not answering your issue but I come back to
>             speak about TTL. Perhaps someone would be able to bring us
>             some light on that.
>
>             This morning I'm trying to reproduce the way I do broke my
>             test AD domain. This leads me to deal with SOA record (I
>             broke my test AD seizing FSMO roles before removing old
>             FSMO owner, SOA was not changed during that process and I
>             suspect this was one of the point leading to all issues
>             this test domain has)
>
>             Anyway:
>             samba-tool dns query m700 samba.domain.tld
>             samba.domain.tld SOA -k yes
>               Name=, Records=1, Children=0
>                 SOA: serial=1, refresh=900, retry=600, expire=86400,
>             *minttl=3600*, ns=m700.samba.domain.tld.,
>             email=hostmaster.samba.domain.tld. (flags=600000f0,
>             serial=1, *ttl=3600*)
>               Name=_msdcs, Records=0, Children=0
>               Name=_sites, Records=0, Children=1
>               Name=_tcp, Records=0, Children=4
>               Name=_udp, Records=0, Children=2
>               Name=DomainDnsZones, Records=0, Children=2
>               Name=ForestDnsZones, Records=0, Children=2
>               Name=m700, Records=0, Children=0
>
>             This shows us TTL is in fact equal to minimumttl inside AD DB.
>
>
>         Not for me:
>
>         SOA: serial=29, refresh=180, retry=600, expire=86400,
>         minttl=180, ns=DC2.my.domain.tld.,
>         email=hostmaster.my.domain.tld. (flags=600000f0, serial=0,
>         ttl=3600)
>
>
>
>             According to
>            
http://stackoverflow.com/questions/20297531/meaning-of-the-five-fields-of-the-answer-section-in-dig-query
>             the second member of dig's answer section is TTL.
>
>             dig -t soa samba.domain.tld
>             ...
>             samba.domain.tld. *3593* IN      SOA
>             m700.samba.domain.tld. hostmaster.samba.domain.tld. 1 900
>             600 86400 3600
>             ...
>              When yesterday the same request gave the following answer:
>
>             ...
>             samba.domain.tld. *1715* IN      SOA DC1.samba.domain.tld.
>             62 900 600 86400 3600
>             ...
>
>             So I ran several that same command and each the value
>             displayed as second member (here 1715 or 3593) was
>             descreased by the same amount of second as the time
>             between my command launchs.
>
>             It seems this shown TTL is declared TTL (or minttl) minus
>             the amount of seconds since last renewal of this TTL. No
>             idae why this behaviour. If someone knows, I would be
>             pleased to learn :)
>
>
>         Yes, I thought so. This is "remaining TTL" for you.
>
>         Interestingly, for me this value is always constant and equals
>         1h, no matter what.
>
>
>         ANYWAYS, I would like to approach from a different direction:
>
>         If my first DC is offline, a ping on any of my domain machines
>         takes 5+ seconds to resolve. I figure that my logon problems
>         reflect multiple such timeouts during the logon process
>         accumulating to a total duration not accepted by the unix
>         logon mechanism.
>
>         If there would be ANY way to reduce the time (to 1 s or
>         something) a machines waits until it finally accepts that a
>         DNS server just won't respond and goes over to the next one...
>         - that actually might solve the issue.
>
>         Is there an option for this on unix machines?
>
>         Ole
>
>     You can add your DC's to your hosts file. Usually your hosts file
>     is queried first, prior to DNS for resolve.
>
>     One thing I notice a bit odd is this
>
>     SOA: serial=29, refresh=180, retry=600, expire=86400, minttl=180,
>     *ns=DC2.my.domain.tld.*, email=hostmaster.my.domain.tld.
>     (flags=600000f0, serial=0, ttl=3600)
>
>     Normally your name server would be the same as your DC who is SOA.
>     Did you manually change this from DC1 to DC2? What DC is your SOA?
>
>     -- 
>     -James
>
>
> I thought all name servers of a given zone should be declared as NS 
> for they can all reply to queries.
> But on my AD there is only one NS, the SOA.
> In fact I thought the SOA was here to distinguish which NS among all 
> NS is the master.
>
> With only one NS record when several DNS are present for the same 
> zone, I expect only one NS will reply to every request so, according 
> to what I had understood about DNS, only one DC will receive all 
> requests from clients.
>
> If I'm right, why Samba does not add NS when a DC is joined?
>
> Today I played with fsmo seize. I haven't checked NS records until 
> now. I have 2 DCs, DC1 & DC2, DC2 became new FSMO, I also modified SOA 
> record to set SOA on DC2.
> Looking for NS record of my AD I have only DC1 as NS when DC2 is SOA.
>
> Ole,
>
> I would declare DC2 as NS. Then once DC1 is off, when a client would 
> ask for NS list of your AD this client would receive DC1 + DC2 and 
> would have more chances to send its request to DC2.
>
> Then you re-run your test with only DC2 up and running.
> Note DNS have need time to be updated if you are using others DNS 
> servers between clients and AD DCs.
The SOA RR identifies a primary DNS name server for the zone as the best 
source of information for the data within that zone and as a entity 
processing the updates for the zone.

The NS resource record is used to notate which DNS servers are 
designated as authoritative for the zone. Listing a server in the NS RR, 
it becomes known to others as an authoritative server for the zone. This 
means that any server specified in the NS RR is to be considered an 
authoritative source by others, and is able to answer with certainty any 
queries made for names included in the zone.

Much of the above was taken almost verbatim from online Microsoft tech 
documents.  I don't believe that DC's create NS records by default.







-- 
-James

I can prove this within my environment:
at the main site: one DC server(samba 4.1.13), one dhcp server, two DNS 
servers(forward AD query to two AD servers),
at the branch site: one DC server(samba 4.1.13), one dhcp server, one 
DNS server(forward AD query to two AD server),
DNSs on client machines point to the DNS servers(not point to the DC).
The two DCs are synced and do their work properly without any 
issue(almost one year, connected via openVPN).
Two sites are configured(using windows sites and services tool):
    one site for branch with its subnet, and the Default-First-Site-Name 
for the main site with its subnets.
Clients at branch automatically log in to the branch DC, and clients at 
the main site automatically log in to the main site DC.
Everything is working as supposed.
but one thing doesn't work as the subject says:
I power off the DC at the main site, or just kill samba process, login 
hangs at main site.
I start samba service, I can log in immediately.
I don't know why it doesn't use the DC at branch site when the main site
DC is offline.

If anybody has similar settings, can you share your experience when one 
DC is offline?

Thanks,
Allen


DC at branch site,
On 11/20/2015 12:35 PM, James wrote:
> On 11/20/2015 10:17 AM, mathias dufresne wrote:
>>
>>
>> 2015-11-20 15:11 GMT+01:00 James <lingpanda101 at gmail.com 
>> <mailto:lingpanda101 at gmail.com>>:
>>
>>     On 11/20/2015 7:40 AM, Ole Traupe wrote:
>>
>>
>>
>>         Am 20.11.2015 um 11:54 schrieb mathias dufresne:
>>
>>             Hi Ole,
>>
>>             I'm still not answering your issue but I come back to
>>             speak about TTL. Perhaps someone would be able to bring us
>>             some light on that.
>>
>>             This morning I'm trying to reproduce the way I do broke
my
>>             test AD domain. This leads me to deal with SOA record (I
>>             broke my test AD seizing FSMO roles before removing old
>>             FSMO owner, SOA was not changed during that process and I
>>             suspect this was one of the point leading to all issues
>>             this test domain has)
>>
>>             Anyway:
>>             samba-tool dns query m700 samba.domain.tld
>>             samba.domain.tld SOA -k yes
>>               Name=, Records=1, Children=0
>>                 SOA: serial=1, refresh=900, retry=600, expire=86400,
>>             *minttl=3600*, ns=m700.samba.domain.tld.,
>>             email=hostmaster.samba.domain.tld. (flags=600000f0,
>>             serial=1, *ttl=3600*)
>>               Name=_msdcs, Records=0, Children=0
>>               Name=_sites, Records=0, Children=1
>>               Name=_tcp, Records=0, Children=4
>>               Name=_udp, Records=0, Children=2
>>               Name=DomainDnsZones, Records=0, Children=2
>>               Name=ForestDnsZones, Records=0, Children=2
>>               Name=m700, Records=0, Children=0
>>
>>             This shows us TTL is in fact equal to minimumttl inside 
>> AD DB.
>>
>>
>>         Not for me:
>>
>>         SOA: serial=29, refresh=180, retry=600, expire=86400,
>>         minttl=180, ns=DC2.my.domain.tld.,
>>         email=hostmaster.my.domain.tld. (flags=600000f0, serial=0,
>>         ttl=3600)
>>
>>
>>
>>             According to
>>
http://stackoverflow.com/questions/20297531/meaning-of-the-five-fields-of-the-answer-section-in-dig-query
>>             the second member of dig's answer section is TTL.
>>
>>             dig -t soa samba.domain.tld
>>             ...
>>             samba.domain.tld. *3593* IN      SOA
>>             m700.samba.domain.tld. hostmaster.samba.domain.tld. 1 900
>>             600 86400 3600
>>             ...
>>              When yesterday the same request gave the following answer:
>>
>>             ...
>>             samba.domain.tld. *1715* IN      SOA DC1.samba.domain.tld.
>>             62 900 600 86400 3600
>>             ...
>>
>>             So I ran several that same command and each the value
>>             displayed as second member (here 1715 or 3593) was
>>             descreased by the same amount of second as the time
>>             between my command launchs.
>>
>>             It seems this shown TTL is declared TTL (or minttl) minus
>>             the amount of seconds since last renewal of this TTL. No
>>             idae why this behaviour. If someone knows, I would be
>>             pleased to learn :)
>>
>>
>>         Yes, I thought so. This is "remaining TTL" for you.
>>
>>         Interestingly, for me this value is always constant and equals
>>         1h, no matter what.
>>
>>
>>         ANYWAYS, I would like to approach from a different direction:
>>
>>         If my first DC is offline, a ping on any of my domain machines
>>         takes 5+ seconds to resolve. I figure that my logon problems
>>         reflect multiple such timeouts during the logon process
>>         accumulating to a total duration not accepted by the unix
>>         logon mechanism.
>>
>>         If there would be ANY way to reduce the time (to 1 s or
>>         something) a machines waits until it finally accepts that a
>>         DNS server just won't respond and goes over to the next
one...
>>         - that actually might solve the issue.
>>
>>         Is there an option for this on unix machines?
>>
>>         Ole
>>
>>     You can add your DC's to your hosts file. Usually your hosts
file
>>     is queried first, prior to DNS for resolve.
>>
>>     One thing I notice a bit odd is this
>>
>>     SOA: serial=29, refresh=180, retry=600, expire=86400, minttl=180,
>>     *ns=DC2.my.domain.tld.*, email=hostmaster.my.domain.tld.
>>     (flags=600000f0, serial=0, ttl=3600)
>>
>>     Normally your name server would be the same as your DC who is SOA.
>>     Did you manually change this from DC1 to DC2? What DC is your SOA?
>>
>>     --     -James
>>
>>
>> I thought all name servers of a given zone should be declared as NS 
>> for they can all reply to queries.
>> But on my AD there is only one NS, the SOA.
>> In fact I thought the SOA was here to distinguish which NS among all 
>> NS is the master.
>>
>> With only one NS record when several DNS are present for the same 
>> zone, I expect only one NS will reply to every request so, according 
>> to what I had understood about DNS, only one DC will receive all 
>> requests from clients.
>>
>> If I'm right, why Samba does not add NS when a DC is joined?
>>
>> Today I played with fsmo seize. I haven't checked NS records until 
>> now. I have 2 DCs, DC1 & DC2, DC2 became new FSMO, I also modified 
>> SOA record to set SOA on DC2.
>> Looking for NS record of my AD I have only DC1 as NS when DC2 is SOA.
>>
>> Ole,
>>
>> I would declare DC2 as NS. Then once DC1 is off, when a client would 
>> ask for NS list of your AD this client would receive DC1 + DC2 and 
>> would have more chances to send its request to DC2.
>>
>> Then you re-run your test with only DC2 up and running.
>> Note DNS have need time to be updated if you are using others DNS 
>> servers between clients and AD DCs.
> The SOA RR identifies a primary DNS name server for the zone as the 
> best source of information for the data within that zone and as a 
> entity processing the updates for the zone.
>
> The NS resource record is used to notate which DNS servers are 
> designated as authoritative for the zone. Listing a server in the NS 
> RR, it becomes known to others as an authoritative server for the 
> zone. This means that any server specified in the NS RR is to be 
> considered an authoritative source by others, and is able to answer 
> with certainty any queries made for names included in the zone.
>
> Much of the above was taken almost verbatim from online Microsoft tech 
> documents.  I don't believe that DC's create NS records by default.
>
>
>
>
>
>
>

-- 
Allen Chen
Network Administrator
IT

Harbourfront Centre

235 Queens Quay West, Toronto, ON
M5J 2G8, Canada | harbourfrontcentre.com
<http://www.harbourfrontcentre.com>
Office: +1 416 973 7973
Cell: +1 416 556 2493

I would try with one more site associated to main site network(s) and put
both DCs in Default-First-Site-Name with that Default-First-Site-Name
associated with no network.

Without DC available in client's site the client should try to find a DC in
Default-First-Site-Name I believe.

2015-11-22 4:43 GMT+01:00 Allen Chen <achen at harbourfrontcentre.com>:
> I can prove this within my environment:
> at the main site: one DC server(samba 4.1.13), one dhcp server, two DNS
> servers(forward AD query to two AD servers),
> at the branch site: one DC server(samba 4.1.13), one dhcp server, one DNS
> server(forward AD query to two AD server),
> DNSs on client machines point to the DNS servers(not point to the DC).
> The two DCs are synced and do their work properly without any issue(almost
> one year, connected via openVPN).
> Two sites are configured(using windows sites and services tool):
>    one site for branch with its subnet, and the Default-First-Site-Name
> for the main site with its subnets.
> Clients at branch automatically log in to the branch DC, and clients at
> the main site automatically log in to the main site DC.
> Everything is working as supposed.
> but one thing doesn't work as the subject says:
> I power off the DC at the main site, or just kill samba process, login
> hangs at main site.
> I start samba service, I can log in immediately.
> I don't know why it doesn't use the DC at branch site when the main
site
> DC is offline.
>
> If anybody has similar settings, can you share your experience when one DC
> is offline?
>
> Thanks,
> Allen
>
>
> DC at branch site,
> On 11/20/2015 12:35 PM, James wrote:
>
>> On 11/20/2015 10:17 AM, mathias dufresne wrote:
>>
>>>
>>>
>>> 2015-11-20 15:11 GMT+01:00 James <lingpanda101 at gmail.com
<mailto:
>>> lingpanda101 at gmail.com>>:
>>>
>>>
>>>     On 11/20/2015 7:40 AM, Ole Traupe wrote:
>>>
>>>
>>>
>>>         Am 20.11.2015 um 11:54 schrieb mathias dufresne:
>>>
>>>             Hi Ole,
>>>
>>>             I'm still not answering your issue but I come back
to
>>>             speak about TTL. Perhaps someone would be able to bring
us
>>>             some light on that.
>>>
>>>             This morning I'm trying to reproduce the way I do
broke my
>>>             test AD domain. This leads me to deal with SOA record
(I
>>>             broke my test AD seizing FSMO roles before removing old
>>>             FSMO owner, SOA was not changed during that process and
I
>>>             suspect this was one of the point leading to all issues
>>>             this test domain has)
>>>
>>>             Anyway:
>>>             samba-tool dns query m700 samba.domain.tld
>>>             samba.domain.tld SOA -k yes
>>>               Name=, Records=1, Children=0
>>>                 SOA: serial=1, refresh=900, retry=600,
expire=86400,
>>>             *minttl=3600*, ns=m700.samba.domain.tld.,
>>>             email=hostmaster.samba.domain.tld. (flags=600000f0,
>>>             serial=1, *ttl=3600*)
>>>               Name=_msdcs, Records=0, Children=0
>>>               Name=_sites, Records=0, Children=1
>>>               Name=_tcp, Records=0, Children=4
>>>               Name=_udp, Records=0, Children=2
>>>               Name=DomainDnsZones, Records=0, Children=2
>>>               Name=ForestDnsZones, Records=0, Children=2
>>>               Name=m700, Records=0, Children=0
>>>
>>>             This shows us TTL is in fact equal to minimumttl inside
AD
>>> DB.
>>>
>>>
>>>         Not for me:
>>>
>>>         SOA: serial=29, refresh=180, retry=600, expire=86400,
>>>         minttl=180, ns=DC2.my.domain.tld.,
>>>         email=hostmaster.my.domain.tld. (flags=600000f0, serial=0,
>>>         ttl=3600)
>>>
>>>
>>>
>>>             According to
>>>
>>>
http://stackoverflow.com/questions/20297531/meaning-of-the-five-fields-of-the-answer-section-in-dig-query
>>>             the second member of dig's answer section is TTL.
>>>
>>>             dig -t soa samba.domain.tld
>>>             ...
>>>             samba.domain.tld. *3593* IN      SOA
>>>             m700.samba.domain.tld. hostmaster.samba.domain.tld. 1
900
>>>             600 86400 3600
>>>             ...
>>>              When yesterday the same request gave the following
answer:
>>>
>>>             ...
>>>             samba.domain.tld. *1715* IN      SOA
DC1.samba.domain.tld.
>>>             62 900 600 86400 3600
>>>             ...
>>>
>>>             So I ran several that same command and each the value
>>>             displayed as second member (here 1715 or 3593) was
>>>             descreased by the same amount of second as the time
>>>             between my command launchs.
>>>
>>>             It seems this shown TTL is declared TTL (or minttl)
minus
>>>             the amount of seconds since last renewal of this TTL.
No
>>>             idae why this behaviour. If someone knows, I would be
>>>             pleased to learn :)
>>>
>>>
>>>         Yes, I thought so. This is "remaining TTL" for
you.
>>>
>>>         Interestingly, for me this value is always constant and
equals
>>>         1h, no matter what.
>>>
>>>
>>>         ANYWAYS, I would like to approach from a different
direction:
>>>
>>>         If my first DC is offline, a ping on any of my domain
machines
>>>         takes 5+ seconds to resolve. I figure that my logon
problems
>>>         reflect multiple such timeouts during the logon process
>>>         accumulating to a total duration not accepted by the unix
>>>         logon mechanism.
>>>
>>>         If there would be ANY way to reduce the time (to 1 s or
>>>         something) a machines waits until it finally accepts that a
>>>         DNS server just won't respond and goes over to the next
one...
>>>         - that actually might solve the issue.
>>>
>>>         Is there an option for this on unix machines?
>>>
>>>         Ole
>>>
>>>     You can add your DC's to your hosts file. Usually your
hosts file
>>>     is queried first, prior to DNS for resolve.
>>>
>>>     One thing I notice a bit odd is this
>>>
>>>     SOA: serial=29, refresh=180, retry=600, expire=86400,
minttl=180,
>>>     *ns=DC2.my.domain.tld.*, email=hostmaster.my.domain.tld.
>>>     (flags=600000f0, serial=0, ttl=3600)
>>>
>>>     Normally your name server would be the same as your DC who is
SOA.
>>>     Did you manually change this from DC1 to DC2? What DC is your
SOA?
>>>
>>>     --     -James
>>>
>>>
>>> I thought all name servers of a given zone should be declared as NS
for
>>> they can all reply to queries.
>>> But on my AD there is only one NS, the SOA.
>>> In fact I thought the SOA was here to distinguish which NS among
all NS
>>> is the master.
>>>
>>> With only one NS record when several DNS are present for the same
zone,
>>> I expect only one NS will reply to every request so, according to
what I
>>> had understood about DNS, only one DC will receive all requests
from
>>> clients.
>>>
>>> If I'm right, why Samba does not add NS when a DC is joined?
>>>
>>> Today I played with fsmo seize. I haven't checked NS records
until now.
>>> I have 2 DCs, DC1 & DC2, DC2 became new FSMO, I also modified
SOA record to
>>> set SOA on DC2.
>>> Looking for NS record of my AD I have only DC1 as NS when DC2 is
SOA.
>>>
>>> Ole,
>>>
>>> I would declare DC2 as NS. Then once DC1 is off, when a client
would ask
>>> for NS list of your AD this client would receive DC1 + DC2 and
would have
>>> more chances to send its request to DC2.
>>>
>>> Then you re-run your test with only DC2 up and running.
>>> Note DNS have need time to be updated if you are using others DNS
>>> servers between clients and AD DCs.
>>>
>> The SOA RR identifies a primary DNS name server for the zone as the
best
>> source of information for the data within that zone and as a entity
>> processing the updates for the zone.
>>
>> The NS resource record is used to notate which DNS servers are
designated
>> as authoritative for the zone. Listing a server in the NS RR, it
becomes
>> known to others as an authoritative server for the zone. This means
that
>> any server specified in the NS RR is to be considered an authoritative
>> source by others, and is able to answer with certainty any queries made
for
>> names included in the zone.
>>
>> Much of the above was taken almost verbatim from online Microsoft tech
>> documents.  I don't believe that DC's create NS records by
default.
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Allen Chen
> Network Administrator
> IT
>
> Harbourfront Centre
>
> 235 Queens Quay West, Toronto, ON
> M5J 2G8, Canada | harbourfrontcentre.com <
> http://www.harbourfrontcentre.com>
> Office: +1 416 973 7973
> Cell: +1 416 556 2493
>
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>

2015-11-20 18:35 GMT+01:00 James <lingpanda101 at gmail.com>:
> On 11/20/2015 10:17 AM, mathias dufresne wrote:
>
>
>
> 2015-11-20 15:11 GMT+01:00 James <lingpanda101 at gmail.com>:
>
>> On 11/20/2015 7:40 AM, Ole Traupe wrote:
>>
>>>
>>>
>>> Am 20.11.2015 um 11:54 schrieb mathias dufresne:
>>>
>>>> Hi Ole,
>>>>
>>>> I'm still not answering your issue but I come back to speak
about TTL.
>>>> Perhaps someone would be able to bring us some light on that.
>>>>
>>>> This morning I'm trying to reproduce the way I do broke my
test AD
>>>> domain. This leads me to deal with SOA record (I broke my test
AD seizing
>>>> FSMO roles before removing old FSMO owner, SOA was not changed
during that
>>>> process and I suspect this was one of the point leading to all
issues this
>>>> test domain has)
>>>>
>>>> Anyway:
>>>> samba-tool dns query m700 samba.domain.tld samba.domain.tld SOA
-k yes
>>>>   Name=, Records=1, Children=0
>>>>     SOA: serial=1, refresh=900, retry=600, expire=86400,
*minttl=3600*,
>>>> ns=m700.samba.domain.tld., email=hostmaster.samba.domain.tld.
>>>> (flags=600000f0, serial=1, *ttl=3600*)
>>>>   Name=_msdcs, Records=0, Children=0
>>>>   Name=_sites, Records=0, Children=1
>>>>   Name=_tcp, Records=0, Children=4
>>>>   Name=_udp, Records=0, Children=2
>>>>   Name=DomainDnsZones, Records=0, Children=2
>>>>   Name=ForestDnsZones, Records=0, Children=2
>>>>   Name=m700, Records=0, Children=0
>>>>
>>>> This shows us TTL is in fact equal to minimumttl inside AD DB.
>>>>
>>>
>>> Not for me:
>>>
>>> SOA: serial=29, refresh=180, retry=600, expire=86400, minttl=180,
>>> ns=DC2.my.domain.tld., email=hostmaster.my.domain.tld.
(flags=600000f0,
>>> serial=0, ttl=3600)
>>>
>>>
>>>
>>>> According to
>>>>
http://stackoverflow.com/questions/20297531/meaning-of-the-five-fields-of-the-answer-section-in-dig-query
>>>> the second member of dig's answer section is TTL.
>>>>
>>>> dig -t soa samba.domain.tld
>>>> ...
>>>> samba.domain.tld. *3593* IN      SOA m700.samba.domain.tld.
>>>> hostmaster.samba.domain.tld. 1 900 600 86400 3600
>>>> ...
>>>>  When yesterday the same request gave the following answer:
>>>>
>>>> ...
>>>> samba.domain.tld. *1715* IN      SOA DC1.samba.domain.tld. 62
900 600
>>>> 86400 3600
>>>> ...
>>>>
>>>> So I ran several that same command and each the value displayed
as
>>>> second member (here 1715 or 3593) was descreased by the same
amount of
>>>> second as the time between my command launchs.
>>>>
>>>> It seems this shown TTL is declared TTL (or minttl) minus the
amount of
>>>> seconds since last renewal of this TTL. No idae why this
behaviour. If
>>>> someone knows, I would be pleased to learn :)
>>>>
>>>
>>> Yes, I thought so. This is "remaining TTL" for you.
>>>
>>> Interestingly, for me this value is always constant and equals 1h,
no
>>> matter what.
>>>
>>>
>>> ANYWAYS, I would like to approach from a different direction:
>>>
>>> If my first DC is offline, a ping on any of my domain machines
takes 5+
>>> seconds to resolve. I figure that my logon problems reflect
multiple such
>>> timeouts during the logon process accumulating to a total duration
not
>>> accepted by the unix logon mechanism.
>>>
>>> If there would be ANY way to reduce the time (to 1 s or something)
a
>>> machines waits until it finally accepts that a DNS server just
won't
>>> respond and goes over to the next one... - that actually might
solve the
>>> issue.
>>>
>>> Is there an option for this on unix machines?
>>>
>>> Ole
>>>
>> You can add your DC's to your hosts file. Usually your hosts file
is
>> queried first, prior to DNS for resolve.
>>
>> One thing I notice a bit odd is this
>>
>> SOA: serial=29, refresh=180, retry=600, expire=86400, minttl=180,
>> *ns=DC2.my.domain.tld.*, email=hostmaster.my.domain.tld.
(flags=600000f0,
>> serial=0, ttl=3600)
>>
>> Normally your name server would be the same as your DC who is SOA. Did
>> you manually change this from DC1 to DC2? What DC is your SOA?
>>
>> --
>> -James
>>
>>
>> I thought all name servers of a given zone should be declared as NS for
> they can all reply to queries.
> But on my AD there is only one NS, the SOA.
> In fact I thought the SOA was here to distinguish which NS among all NS is
> the master.
>
> With only one NS record when several DNS are present for the same zone, I
> expect only one NS will reply to every request so, according to what I had
> understood about DNS, only one DC will receive all requests from clients.
>
> If I'm right, why Samba does not add NS when a DC is joined?
>
> Today I played with fsmo seize. I haven't checked NS records until now.
I
> have 2 DCs, DC1 & DC2, DC2 became new FSMO, I also modified SOA record
to
> set SOA on DC2.
> Looking for NS record of my AD I have only DC1 as NS when DC2 is SOA.
>
> Ole,
>
> I would declare DC2 as NS. Then once DC1 is off, when a client would ask
> for NS list of your AD this client would receive DC1 + DC2 and would have
> more chances to send its request to DC2.
>
> Then you re-run your test with only DC2 up and running.
> Note DNS have need time to be updated if you are using others DNS servers
> between clients and AD DCs.
>
> The SOA RR identifies a primary DNS name server for the zone as the best
> source of information for the data within that zone and as a entity
> processing the updates for the zone.
>
> The NS resource record is used to notate which DNS servers are designated
> as authoritative for the zone. Listing a server in the NS RR, it becomes
> known to others as an authoritative server for the zone. This means that
> any server specified in the NS RR is to be considered an authoritative
> source by others, and is able to answer with certainty any queries made for
> names included in the zone.
>
> Much of the above was taken almost verbatim from online Microsoft tech
> documents.  I don't believe that DC's create NS records by default.
>
> --
> -James
>
> As I was not confident at all neither regarding NS declaration in MS AD I
did installed 2 DCs running MS Windows 2008 R2 and then configured on them
one AD domain msad.domain.tld to check.

Both MS DCs are hosting the DNS 2 zones msad.domain.tld and
_msdcs.msad.domain.tld.
When joining the second DC dcpromo.exe complains it was not able to find
SOA for related zones.

Domain name:
msad.domain.tld

DC names / IP:
win2k8r2-01.msad.domain.tld / 10.1.1.211
win2k8r2-02.msad.domain.tld / 10.1.1.212

------------------------------------------------------------
A msad.domain.tld
------------------------------------------------------------
dig @10.1.1.212 -t A msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld.        600     IN      A       10.1.1.211
msad.domain.tld.        600     IN      A       10.1.1.212

dig @10.1.1.211 -t A msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld.        600     IN      A       10.1.1.212
msad.domain.tld.        600     IN      A       10.1.1.211
------------------------------------------------------------


------------------------------------------------------------
NS msad.domain.tld
------------------------------------------------------------
dig @10.1.1.211 -t NS msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld.        3600    IN      NS      win2k8r2-01.msad.domain.tld.
msad.domain.tld.        3600    IN      NS      win2k8r2-02.msad.domain.tld.

;; ADDITIONAL SECTION:
win2k8r2-01.msad.domain.tld. 3600 IN    A       10.1.1.211
win2k8r2-02.msad.domain.tld. 3600 IN    A       10.1.1.212

dig @10.1.1.212 -t NS msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld.        3600    IN      NS      win2k8r2-02.msad.domain.tld.
msad.domain.tld.        3600    IN      NS      win2k8r2-01.msad.domain.tld.

;; ADDITIONAL SECTION:
win2k8r2-02.msad.domain.tld. 3600 IN    A       10.1.1.212
win2k8r2-01.msad.domain.tld. 3600 IN    A       10.1.1.211
------------------------------------------------------------


------------------------------------------------------------
SAO msad.domain.tld
------------------------------------------------------------
dig @10.1.1.211 -t SOA msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld.        3600    IN      SOA
win2k8r2-01.msad.domain.tld. hostmaster.msad.domain.tld. 38 900 600 86400
3600

;; ADDITIONAL SECTION:
win2k8r2-01.msad.domain.tld. 3600 IN    A       10.1.1.211

dig @10.1.1.212 -t SOA msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld.        3600    IN      SOA
win2k8r2-02.msad.domain.tld. hostmaster.msad.domain.tld. 38 900 600 86400
3600

;; ADDITIONAL SECTION:
win2k8r2-02.msad.domain.tld. 3600 IN    A       10.1.1.212
------------------------------------------------------------

So SOA is the DC which replies. This suits the given definition as we can
modify DNS zones on each DC with DNS service running and each DC can
propagate modifications.

NS are all declared as they are authoritative name servers, this also suits
given definition: each DC can reply DNS request with certainty because of
replication.

This domain as no client, it was built only for testing that.

It seems there is some round-robin stuff on SN and A RR: running several
times same request on same DC change the answer for records A and NS:
dig @10.1.1.211 -t A msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld.        600     IN      A       10.1.1.211
msad.domain.tld.        600     IN      A       10.1.1.212

dig @10.1.1.211 -t A msad.domain.tld | egrep 'ANSWER |ADDITIONAL ' -A3
;; ANSWER SECTION:
msad.domain.tld.        600     IN      A       10.1.1.212
msad.domain.tld.        600     IN      A       10.1.1.211


Once more: I'm not an expert. I'm just sending here my thoughts, trying
to
understand.

Best regards all and have a nice weekend,

mathias

>> Then you re-run your test with only DC2 up and running.
>> Note DNS have need time to be updated if you are using others DNS 
>> servers between clients and AD DCs.
> The SOA RR identifies a primary DNS name server for the zone as the 
> best source of information for the data within that zone and as a 
> entity processing the updates for the zone.
>
> The NS resource record is used to notate which DNS servers are 
> designated as authoritative for the zone. Listing a server in the NS 
> RR, it becomes known to others as an authoritative server for the 
> zone. This means that any server specified in the NS RR is to be 
> considered an authoritative source by others, and is able to answer 
> with certainty any queries made for names included in the zone.
>
> Much of the above was taken almost verbatim from online Microsoft tech 
> documents.  I don't believe that DC's create NS records by default.

You mean Samba DCs or DCs in general?

I am not sure I understand the above. Do you suggest to create another 
NS record for the Second_DC, or not to?

In the resolv.conf on my member servers both DCs are listed as DNS 
servers. I like to think that the member servers eventually ask the 
second DNS server, if the first won't respond. This seems to be 
reflected by ping taking more than 5 s for the first packet to arrive.

BUT what does the second DNS server (Second_DC) reply? Which logon 
server does it announce?