This is a continuation of a series of articles on operational engineering aspects of Azure public cloud computing that included the most recent discussion on Azure DNS which is a full-fledged general availability service that provides similar Service Level Agreements as expected from others in the category.

DNS servers used with Active Directory can be primary or secondary.
The primary stores all the records while the secondary gets the contents from primary
The contents of a zone file are stored hierarchically, and this structure can be replicated among all the DCs.
It is updated via LDAP operations or DDNS (Dynamic DNS must have AD integration). A common misconfiguration issue is the island issue when an IP address for a DNS, changes and it is updated only locally. To do a global update instead, they must point to a root server other than themselves. Delegation options are granted to DNS servers or DCs. Simple is when DNS namespaces are delegated to DCs, and DC hosts a DNS zone. The records in a DNS server as opposed to DC are autonomously managed. DNS servers need to allow DDNS by DC. DC does DDNS to prevent updates to the DNS records in the server. Support and maintenance are minimal with DDNS. Standalone AD is used to create test or lab networks. A forest is created, a DC is assigned, DNS Service is installed. DNS zone is added, unresolved requests are forwarded to an existing corporate server. The primary DNS for all clients points to the DC. Background loading of DNS Zones makes it even easier to load DNS zones while keeping the zone available for DNS updates / queries.
Active directory has a feature where by one or more IP address can be specified to forward name resolutions to that are not handled by the local DNS server.  The conditional forwarder definitions are also replicated via Active Directory. Together with the forward and reverse lookup zones in the active directory these can be set via the DNS mmc management console. The DNS servers are usually primary or secondary in nature. The primary stores all the records of the zone and the secondary gets the contents of its zone from the primary.  Each update can flow from the primary to the secondary or the secondary may pull the updates periodically or on demand. All updates must be made to the primary. Each type of server can resolve name queries that come from hosts for the zones.   The contents of the zone file can also be stored in the active directory in a hierarchical structure.  The DNS structure can be replicated among all DCs of the domain, each DC holds a writeable copy of the DNS data.  The DNS objects stored in the Active Directory could be updated on any DC via LDAP operations or through DDNS against DCs that act as DNS servers when the DNS is integrated with the Active Directory.
The DNS "island" issue sometimes occurs due to improper configuration. AD requires proper DNS resolution to replicate changes and when using integrated DNS, the DC replicates DNS changes through AD replication.  This is the classic chicken and egg problem. If the DC configured as name server points to itself and its IP address changes, the DNS records will successfully be updated locally but other DCs cannot resolve this DC's IP address unless they point to it. This causes replication fail and effectively renders the DC with the changed IP address an island to itself. This can be avoided when the forest root domain controllers that are the name servers are configured to point at root servers other than themselves.
Application partitions are user defined partitions that have a custom replication scope. Domain controllers can be configured to host any application partition irrespective of their domains so long as they are in the same forest. This decouples the DNS data and its replication from the domain context. You can now configure AD to replicate only the DNS data between the domain controllers running the DNS service within a domain or forest.
The other partitions are DomainDnsZones and ForestDnsZones. The system folder is the root level folder to store DNS data. The default partitions for Domain and Forest are created automatically.
Aging and scavenging When the DNS records build up, some of the entries become stale when the clients have changed their names or have moved. These are difficult to maintain as the number of hosts increases. Therefore, a process called scavenging is introduced in the Microsoft DNS server that scans all the records in a zone and removes the records that have not been refreshed in a certain period. when the clients register themselves with the dynamic DNS, their registrations are set to be renewed every 24 hours by default. Windows DNS will store this timestamp as an attribute of the DNS record and is used with scavenging.  Manual record entries have timestamps set to zero, so they are excluded from scavenging.
"A "no-refresh interval" for the scavenging configuration option is used to limit the amount of unnecessary replication because it defines how often the DNS sever will accept the DNS registration refresh and update the DNS record.
This is how often the DNS server will propagate a timestamp refresh from the client to the directory or filesystem. Another option called the refresh interval specifies how long the DNS server must wait to follow a refresh for a record to be eligible for scavenging and this is typically seven days.