Can Google gcloud DNS work with seconday DNS servers

We do this. I'm not sure I would recommend it, but we do it:

Solaris server running BIND

• runs authoritative for every forward domain except example.ad
• runs authoritative for every in-addr.arpa zone except ones served by AD DHCP
• pulls slave for example.ad and DHCP ranges from AD DNS servers

linux server running BIND

• pulls slave for example.ad and DHCP ranges from AD DNS servers
• pulls slave for everything else from solaris primary.

AD DNS Servers

• runs master for example.ad
• runs master for any in-addr.arpa zone served by AD DHCP.
• forwards all recursive requests to the solaris/linux BIND installs

Windows Clients

• Assigned the AD DNS servers by AD DHCP. We experimented with this and found that "the microsoft family of products" we used did not like not having the AD DNS server. We may have given up to early, but it didn't go well from what I remember.

UNIX/Linux/operational clients:

• hard coded BIND DNS servers

In practice, here are some policies we've enacted:

• any record that refers to IT-class services (exchange, etc) gets an A record in example.ad and gets a CNAME to record.example.ad in example.com
• any record that refers to operational or network gear gets an A record in example.com and a CNAME in example.ad.

Our setup is actually even a little more complex than that because we purchased a company who uses Netware/AD for DNS/DHCP so we have a similar set of rules for them.

I'm not sure I would recommend doing this if your hand isn't forced. Our install is an attempt to make the best of a bad set of circumstances. However, I do have to admit that I like using BIND so much more than AD DNS, so, since we're clearly not going to get rid of AD, it's a nice way to have some use of BIND.

One problem we've had is caching in the AD DNS server. We've tried to educate our operational customers that their laptops use AD DNS, but changes are made in BIND, so if they make a change and they want to verify it they have to manually look it up against the correct servers. That's an annoyance, but it is an issue that comes up surprisingly often.

Hope that helps.

1. The way Active Directory's multiple-master replication works is quite different from the DNS protocol's primary/secondary replication model. So a secondary copy of the records is truly "secondary", in that it is always refreshed from the master.
2. Not quite sure what you mean... Can you clarify?
3. We need secondary zones because that's the way every other DNS server in the world works, including the industry standard one, BIND. Many companies have their BIND services running on large UNIX servers, and the Windows AD/DNS servers just have a secondary copy.
4. Yes, each domain controller keeps a full copy of all the AD & DNS data (with some minor exceptions--read up on Global Catalogs and FSMO roles).
5. Sort of... there's no built-in command to do this, but you can use BIND tools and a copy of the data from the secondary to fill out a new primary zone. It's not advisable, though.
6. No, you still have full control over zone transfer security. The quoted line is saying that the SOA, NS and A-records which point to the zone's primary & secondary name servers are always available for all clients to read, which means that they could use the info to create their own stub zone if they wanted to.