<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>                                                                                               - Kevin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 23, 2018 at 6:50 PM, Grant Taylor via bind-users <span dir="ltr"><<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/23/2018 02:15 PM, Grant Taylor via bind-users wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></span>
He confirmed that LDAP does support writes to different data on different servers without a problem.<br>
<br>
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.<br>
<br>
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.<br>
<br>
This is where I wash my hands and decide that I want to NOT get any deeper into AD.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
-- <br>
Grant. . . .<br>
unix || die<br>
<br>
</div></div><br>______________________________<wbr>_________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/bind-users</a><br>
<br></blockquote></div><br></div>