As someone who has had to deal with the interaction between BIND and
AD-integrated DNS for most of my DNS career, I think it's important, from a
BIND perspective, to understand how a given AD-integrated DNS zone is used.
If clients are registering themselves in the AD zone, then there is going
to be a lot of "churn" in the zone, and all of these problems that worry
BIND people -- like "floating" serial numbers, SOA.MNAMEs that flip from
one DC to another, potential record-level inconsistencies between
"multi-masters", and (apparently) no good "resolution protocol" to
arbitrate between them, most likely come to the forefront.
For us, we made the decision early on that we were *not* going to register
clients in our AD zones. So, what's in those zones mostly consists of SRV
records for the service-location function (sometimes called "DC Locator" in
Microsoft-ese). About the only A records are for the domain controllers
themselves. None of this data changes very frequently, so the SOA-related
issues and the potential multi-master consistency issues really haven't
bitten us. We replicate the AD zone data to our BIND-based infrastructure,
and this allows us to reap the benefits of things like Anycast-based
resolution, decent query logging and so forth. We've even managed to tweak
the NOTIFYs to some degree, in order for the replication to occur in a
timely fashion.
YMMV if you register your clients in AD, but for us, it's been mostly a
peaceful co-existence. About the biggest problem we have is a lack of
coordination when domain controllers are moved around, firewall rules are
botched, etc. But that's more of a big-company, chaos/silo-ing issue than a
technical challenge _per_se_. We compensate by monitoring the logs for
zone-transfer failure messages.
- Kevin
On Thu, Aug 23, 2018 at 6:50 PM, Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:
> On 08/23/2018 02:15 PM, Grant Taylor via bind-users wrote:
>
>> It's my understanding that MS-DNS servers hosting AD Integrated zones are
>> actually functioning as application layer gateways between DNS and data
>> that's stored in LDAP.
>>
>
> My AD Guy confirms that the DNS data for Active Directory Integrated Zones
> is indeed stored in LDAP and that MS-DNS is acting as an application layer
> gateway between DNS and LDAP. As such, the multi-master aspect issue is
> pushed to AD's LDAP implementation.
>
> So the case of synchronizing records with different FQDNs is actually
>> trivial in that different records are being updated in the back end LDAP
>> and the ALG is simply reading the data and replying to clients.
>>
>
> He confirmed that LDAP does support writes to different data on different
> servers without a problem.
>
> He even indicated that updates for the same FQDN may not be a problem,
> depending on the operation being done. I.e. multiple inserts for A records
> will simply merge in LDAP data. The thing he wasn't quite sure of was what
> would happen if one server deletes an A record and another server enters an
> A record. He thinks that LDAP will delete the first record which is
> different and insert the other record.
>
> He also mentioned that it is unlikely that the same FQDN would be modified
> on two different servers at the same time. As such, LDAP would likely see
> different FQDNs and simply merge them as part of the raw data.
>
> This is where I wash my hands and decide that I want to NOT get any deeper
> into AD.
>
>
>
>
> --
> Grant. . . .
> unix || die
>
>
> _______________________________________________
> 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
>
>
_______________________________________________
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
