Stub zones contain only three kinds of resource records:
A copy of the SOA record for the zone.
Copies of NS records for all name servers authoritative for the zone.
Copies of A records for all name servers authoritative for the zone.
a. That’s it–no CNAME records, MX records, SRV records, or A records for other hosts in the zone. This means replicating zone information from master to stub zone adds almost NIL DNS traffic to your network as the records for name servers rarely change unless you decommission an old name server or deploy a new one.
b. And to make replication even more efficient, stub zones don’t use UDP as traditional DNS zone transfers do. Instead, stub zones use TCP, which supports much larger packet sizes than UDP. So while a typical zone transfer might involve many UDP packets flooding the network, stub zone transfer only involves a few packets at most.
c. While most DNS servers can be configured to prevent zone transfers to secondary zones from occurring, stub zones request only SOA, NS, and A records for name servers, all of which are provided without restriction by any name server since these records are essential for name resolution to function properly.
d. Since stub zones can be integrated within AD (secondary zones can’t), they can make use of Active Directory replication to propagate their information to all domain controllers on your network.
A DNS server that is hosting a stub zone is configured with the IP address of the authoritative server from which it loads. DNS servers can use stub zones for both iterative and recursive queries. When a DNS server hosting a stub zone receives a recursive query for a computer name in the zone to which the stub zone refers, the DNS server uses the IP address to query the authoritative server, or, if the query is iterative, returns a referral to the DNS servers listed in the stub zone. A stub zone reduces the amount of DNS traffic on the network and makes DNS more efficient especially over slow WAN links
. Client expects best answer from server
. DNS server does not query other DNS servers
. May refer client to another DNS server
Typically sent by DNS servers, not Microsoft® Windows® clients
. Client expects the answer or an error
. DNS server may query other DNS servers
. Should not refer client to another DNS server
. Can be sent by both DNS servers and Windows clients
Interative queries is a request from a client tells the DNS server that the client expects the best answer the DNS server can provide immediately, without (the DNS Server) contacting other DNS servers. The process then relies on the client to continue the process possibly by using a referral where the DNS server supplying the client NS or A records of a DNS server that is closer to the namespace which may possibly provide the answer. However we don’t see that with the normal sense of the word, ‘query,’ when a client sends a request to a DNS server, which we are more familiar with. For the most part, the DNS resolver service on Windows clients are basically ‘stub resolvers’ that rely on a recursive-enabled DNS server to resolve queries it is not aware of. Of course you can create resolver scripts to preform an interative query.
However, with a recursion request from a client to a DNS server, which as I said is what we normally think of using the term ‘query,’ the DNS server will do its best to resolve it, either by using the Root Hints, which is essentially an interative query to the Roots to devolve the namespace from the TLD backwards, or a query to a Forwarder, if configured with a Forwarder, which is essentially a recursion request because technically it’s not an iterative request, even though the server repeats (iterates) when trying to find the answer.
You can make nslookup perform an iterative query by using the "norecurse" option (set norecurse). In this situation the DNS server will give its best response, without looking elsewhere other than its cache or zones its authoritative for.
DNS Queries Overview http://www.topbits.com/understanding-dns-queries-and-lookups.html
Pros of stub zone:
If Firewalls are involved: with a Stub-Zone you cannot specify which DNS-Server of the nameservers responsible for the zone in question is really used to resolve the name. If you have specific ports opened just between some servers in question then a Delegation is better.
Same thing if you would prefer the use of specific servers. For example if you have a Hub Office and some branch offices, and the forest root servers are in the hub office, a sub-domain is spread out in the remote offices. Usually all Cliens and Servers are querying the sub-domains DNS-Servers, however some central systems in the Hub-Office are using the Root-Servers for DNS-Requests. Do you really want those central systems which ask the Root-Domains-Servers for queries in the Sub-Domain to get delegated to a remote server? This "might" happen when you’d be using Stub-Zones. So you want to keep those at your central office.
So there are pro’s and con’s when it comes to using Stub-Zones instead of (static) delegations.
Is it possible to integrate forwarder with AD? yes, dnscmd can make it.