Enterprise DNS Architecture - AD and BIND

[Barry S. Finkel]

On 12/15/2016 8:16 AM, Bob Harold wrote:
>
> On Wed, Dec 14, 2016 at 1:41 PM, Veaceslav Revutchi
> <slavarevutchi at gmail.com <mailto:slavarevutchi at gmail.com>> wrote:
>
>     On Wed, Dec 14, 2016 at 10:35 AM, Barry S. Finkel <bsfinkel at att.net
>     <mailto:bsfinkel at att.net>> wrote:
>     > On 12/14/2016 Veaceslav Revutchi <slavarevutchi at gmail.com
>     <mailto:slavarevutchi at gmail.com>> 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 look at the zones or for nefarious purposes.  That was not the
    case.  When a zone transfer failed, I had no idea why.

3) And at the time (five years ago), the MS dns.log file was not a log
    file (in Unix syslog terms).  It was a file for which one set a max
    size, so when the log reached that max size, it was cleared and
    a new log file as started.  My max size was 50 Mb, and I logged
    everything (such as one would see in a Wireshark trace), so if an
    event happened overnight, there was a good possibility that the
    dns.log file had reached its max size and had been cleared by the
    time I wanted to research a problem.

--Barry Finkel