Re: Enterprise DNS Architecture - AD and BIND

2016-12-15 Thread Barry S. Finkel

On 12/15/2016 8:16 AM, Bob Harold wrote:


On Wed, Dec 14, 2016 at 1:41 PM, Veaceslav Revutchi
> wrote:

On Wed, Dec 14, 2016 at 10:35 AM, Barry S. Finkel > wrote:
> On 12/14/2016 Veaceslav Revutchi > wrote:
>
>> Since this thread is still fresh, what is the current best practice
>> when slaving from AD? Do you pick one DC and list it as master or is
>> it safe to list multiple? We are looking to do the same and just
>> started the conversation with our AD team. The serial numbers among
>> DCs authoritative for the same zone are quite spread out and it takes
>> a few minutes for the DC with the lowest number to catch up. I'm not
>> sure if I can assume that two DCs with the same serial number
have the
>> same zone contents. Haven't done a zone transfer comparizon yet.
>>
>> Curious to know what your experience is when slaving from AD.
>>
>> Thank you,
>> Slava
>
>
> I have not included the previous text in this reply.
>
> When I was managing a BIND/AD DNS infrastructure, I chose
> ONLY ONE of the AD DNS Servers as a master.  There is a problem
> with serial numbers (KB282826 - I have that number memorized).
> If a MS DNS Server is not a master for a slave, then the zone
> serial number does not matter, as the zone is internal only to
> the Windows infrastructure.  If the DNS Server is a master for
> the zone, then the zone serial number does matter.
>
> Assume, for example, that you have two MS DNS Servers for a zone,
> one on each of two Domain Controllers - DCA, and DCB.  Assume
> that for a given zone both DCs have the same zone contents and
> zone serial number, say 100.  Now, a machine sends a dynamic
update for
> the zone to DCA at the same time that another machine sends another
> update to that zone to DCB.  Each DC DNS now has a copy of the zone
> with an increased serial number (101) BUT with different contents.
> Sometime, under the covers of AD, the MS code will synchronize the
> zone contents between DCA and DCB, but what serial number should be
> assigned to the combined zone?  It can't be 101, as that has already
> been used.  Can it be 102?  What happens if another dynamic update
> is sent to DCA or DCB while the synchronization is occurring?
> This is the problem, and why I chose only one DC to be the master
> for all of the DC zones.
>
> Also note that with the MS "_" zones, there are dynamic updates that
> do not change the contents of a zone but do increase the zone serial
> number.  Thus there are lots of unnecessary zone transfers from the
> AD DNS Server to the BIND slave server(s).  (This was true when I was
> the DNS manager, and I never got permission to ask MS why the serial
> number was incremented when the zone had not changed.  Things might
> have changed in the past five years.)

Barry,

Appreciate you sharing this. This is good info.

Thank you!


My experience slaving AD zones with BIND servers:
Ignore "failed while receiving responses: not exact " errors.  I think
that just means that the serial number changed during the transfer.
I had them turn off 'notify' and we use the 'refresh' timer (15 minutes)
to pull updates.
I also ignore these errors for those servers:
failed to connect: timed out
failed while receiving responses: REFUSED

I list more than one, for redundancy, and ignore serial number
mismatches.  Since it is constantly increasing, updates missed on one
transfer should be in the next transfer.

That 'works'.  Whether that means "works fine" or "users have gotten
used to it" is hard to say.

--
Bob Harold




Other things I did not mention.

1) There were problems when the AD DC I chose as the master was
undergoing patching.  Sometimes the zone serial number for
one or more of the AD zones DECREASED.  Sometimes the
decrease was juswt during the patching and intermediate
reboots of the DC, but sometimes the decrease was
permanent.  I was not allowed to
open a trouble ticket with Microsoft, as my management did
not think that this was a real problem.  No one complained
about having received and used old AD data from DNS.

2) There were times when the zone transfer from the the AD DC to
   a BIND slave failed, and I had no idea why.  I did talk to one
   of the MS DNS Developers (because at the time we were having some
   major problems - since fixed), and I requested that all failed
   zone transfers be logged, with a reason for the failure.  His
   response was that MS did not want to log failed zone transfers
   so as not to fill the dns.log file.  He was under the assumption
   that many persons would be requesting zone transfers, either just
   to 

Re: Enterprise DNS Architecture - AD and BIND

2016-12-15 Thread Bob Harold
On Wed, Dec 14, 2016 at 1:41 PM, Veaceslav Revutchi  wrote:

> On Wed, Dec 14, 2016 at 10:35 AM, Barry S. Finkel 
> wrote:
> > On 12/14/2016 Veaceslav Revutchi  wrote:
> >
> >> Since this thread is still fresh, what is the current best practice
> >> when slaving from AD? Do you pick one DC and list it as master or is
> >> it safe to list multiple? We are looking to do the same and just
> >> started the conversation with our AD team. The serial numbers among
> >> DCs authoritative for the same zone are quite spread out and it takes
> >> a few minutes for the DC with the lowest number to catch up. I'm not
> >> sure if I can assume that two DCs with the same serial number have the
> >> same zone contents. Haven't done a zone transfer comparizon yet.
> >>
> >> Curious to know what your experience is when slaving from AD.
> >>
> >> Thank you,
> >> Slava
> >
> >
> > I have not included the previous text in this reply.
> >
> > When I was managing a BIND/AD DNS infrastructure, I chose
> > ONLY ONE of the AD DNS Servers as a master.  There is a problem
> > with serial numbers (KB282826 - I have that number memorized).
> > If a MS DNS Server is not a master for a slave, then the zone
> > serial number does not matter, as the zone is internal only to
> > the Windows infrastructure.  If the DNS Server is a master for
> > the zone, then the zone serial number does matter.
> >
> > Assume, for example, that you have two MS DNS Servers for a zone,
> > one on each of two Domain Controllers - DCA, and DCB.  Assume
> > that for a given zone both DCs have the same zone contents and
> > zone serial number, say 100.  Now, a machine sends a dynamic update for
> > the zone to DCA at the same time that another machine sends another
> > update to that zone to DCB.  Each DC DNS now has a copy of the zone
> > with an increased serial number (101) BUT with different contents.
> > Sometime, under the covers of AD, the MS code will synchronize the
> > zone contents between DCA and DCB, but what serial number should be
> > assigned to the combined zone?  It can't be 101, as that has already
> > been used.  Can it be 102?  What happens if another dynamic update
> > is sent to DCA or DCB while the synchronization is occurring?
> > This is the problem, and why I chose only one DC to be the master
> > for all of the DC zones.
> >
> > Also note that with the MS "_" zones, there are dynamic updates that
> > do not change the contents of a zone but do increase the zone serial
> > number.  Thus there are lots of unnecessary zone transfers from the
> > AD DNS Server to the BIND slave server(s).  (This was true when I was
> > the DNS manager, and I never got permission to ask MS why the serial
> > number was incremented when the zone had not changed.  Things might
> > have changed in the past five years.)
>
> Barry,
>
> Appreciate you sharing this. This is good info.
>
> Thank you!
>
>
My experience slaving AD zones with BIND servers:
Ignore "failed while receiving responses: not exact " errors.  I think that
just means that the serial number changed during the transfer.
I had them turn off 'notify' and we use the 'refresh' timer (15 minutes) to
pull updates.
I also ignore these errors for those servers:
failed to connect: timed out
failed while receiving responses: REFUSED

I list more than one, for redundancy, and ignore serial number mismatches.
Since it is constantly increasing, updates missed on one transfer should be
in the next transfer.

That 'works'.  Whether that means "works fine" or "users have gotten used
to it" is hard to say.

-- 
Bob Harold
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users