The DNS NOTIFY transaction allows master servers to inform secondary servers when the zone has changed (notify is set on the master server on a per zone basis)—an interrupt as opposed to poll model. This should reduce propagation delay while not unduly increasing the master server's load.
The use of this feature depends on how often the master server's data will change and how slow the link is between the secondary and the primary. If the master server's data changes a great deal, and it is important that the data on the secondaries is very accurate, and the link between the site that houses the primary and the secondary is not negatively impacted by the zone transfer, then it may be a good idea to use this feature.
It's also a good idea to use this feature if the master server's data does not change very often. If this is the case then you can make the refresh time on the master very long and a notification will be sent to the secondaries when they need to update their zone database.
Round Robin is a technique used as a form of load balancing between servers. You can read more about load balancing in RFC 1794. Here's an example that shows how this works:
On the DNS server you could have 2 address entries for the same host, such as the following:
copperhead.glennwo.scottsu.com A 157.55.106.193
copperhead.glennwo.scottsu.com A 157.55.107.88
If you make a query via some mechanism such as "PING copperhead.glennwo.scottsu.com," the DNS server will send both IP addresses back, but typically the client will always use the first one. The next time the DNS server receives a query for this host the order of the list is changed in a round robin fashion (the address that was first in the previous list will be last in the new list), hence when the client resolver chooses the first IP address in the list, it chooses a different server. This is typically used for load balancing.
Here is a trace of a query that shows how the feature works. In frame 1 a query is sent to get the IP address for host "copperhead.glennwo.scottsu.com". Since there were 2 entries in the database, both were returned. The client resolver, in most implementations (including the Microsoft resolver) uses the first entry and discards the other.
1 SCOTTSU-7 Xircom40417A DNS 0x1:Std Qry for copperhead.glennwo.scottsu.com
DNS: 0x1:Std Qry for copperhead.glennwo.scottsu.com of type Host Addr on class INET addr.
2 Xircom40417A SCOTTSU-7 DNS 0x1:Std Qry Resp. for copperhead.glennwo.scottsu.com
DNS: 0x1:Std Qry Resp. for copperhead.glennwo.scottsu.com of type Host Addr on class INET addr.
....
DNS: Answer section: copperhead.glennwo.scottsu.com of type Host Addr on class INET addr.(2 records present)
DNS: Resource Record: copperhead.glennwo.scottsu.com of type Host Addr on class INET addr.
DNS: Resource Name: copperhead.glennwo.scottsu.com
DNS: Resource Type = Host Address
DNS: Resource Class = Internet address class
DNS: Time To Live = 0 (0x0)
DNS: Resource Data Length = 4 (0x4)
DNS: IP address = 157.55.107.88
DNS: Resource Record: copperhead.glennwo.scottsu.com of type Host Addr on class INET addr.
DNS: Resource Name: copperhead.glennwo.scottsu.com
DNS: Resource Type = Host Address
DNS: Resource Class = Internet address class
DNS: Time To Live = 3600 (0xE10)
DNS: Resource Data Length = 4 (0x4)
DNS: IP address = 157.55.106.193
The next time someone makes a query for the host copperhead.glennwo.scottsu.com the first IP address in the list will be different.
DNS: Answer section: copperhead.glennwo.scottsu.com of type Host Addr on class INET addr.(2 records present)
DNS: Resource Record: copperhead.glennwo.scottsu.com of type Host Addr on class INET addr.
DNS: Resource Name: copperhead.glennwo.scottsu.com
DNS: Resource Type = Host Address
DNS: Resource Class = Internet address class
DNS: Time To Live = 3600 (0xE10)
DNS: Resource Data Length = 4 (0x4)
DNS: IP address = 157.55.106.193
DNS: Resource Record: copperhead.glennwo.scottsu.com of type Host Addr on class INET addr.
DNS: Resource Name: copperhead.glennwo.scottsu.com
DNS: Resource Type = Host Address
DNS: Resource Class = Internet address class
DNS: Time To Live = 0 (0x0)
DNS: Resource Data Length = 4 (0x4)
DNS: IP address = 157.55.107.88
The main thing to remember about DNS support for NetBIOS scope is DON'T USE IT unless your network already uses NetBIOS scope. In a scope configuration, all hosts are assigned a scope ID, and they register this scope ID—along with their NetBIOS name with WINS. If DNS is configured to use scope, when it queries WINS, in addition to passing the DNS host name as the single-part NetBIOS name, it also passes the DNS domain as the NetBIOS scope ID.
A very important point to remember about scope is that when scope is used, NetBIOS applications can not see hosts that are in another scope! One such NetBIOS application happens to be the Windows NT Netlogon service which is responsible for trust relationships between Windows NT domains. This means, for example, that if scope is used a user cannot logon in a domain whose domain controllers have a different scope than that of the users station. It also means that a user cannot access resources on a network server in a domain whose scope is different than that of the users station.
On startup of the DNS service, the zone files are read from disk. As changes are made through the DNS Manager, the service periodically flushes these changes to disk. In general, you should always use the DNS Manager utility to add, delete, or modify resource records in the database, however if you feel a need to modify the files with an editor, you should only make changes to these files if the DNS server service is stopped. By default, the files are located in \%SystemRoot%\system32\Dns.
If you use the DNS administrative utility, and choose the DNS | "Update Server Data Files" menu item, the files will also be flushed from memory to disk.
The DNS server will report events into the Eventlog. This allows an administrator to determine when a zone transfer has been completed, or when the DNS service has started, stopped or an error has occurred.