I'd rather go with a single domain using your two servers for redundancy than to use two separate domains on single (point of failure) servers. What is driving your choice to go with a parent/child domain forest? You could just use the DNS space for the child domain since you said it's contiguous without requiring an AD domain unless you have security boundary concerns.
Against my better judgement, I'll answer the question assuming you have two servers for each domain (four total) -- just subtract two of the servers for your case.
Option 1.
With your desire to keep DNS local to the domain, the parent DCs point to one another and the child DCs point to one another as well. The easier configuration would be to use a scope that replicates the DNS zone forest-wide.
You have parent.local (or whatever) as your top-level and child.parent.local as the subdomain.
AD will replicate both domains throughout the forest making DNS resolution simple. You'll see overlap on a given DNS server with the zones, but Windows deals with that.
Option 2.
Another option is to not do forest-wide replication in which case I would simply configure a forwarder on the child DCs to send everything up to the parent DCs DNS, but on the parent you'll need to create a delegation for the child subdomain back down.
The problem right now is that your domain is still not delegated.
From what I see in the whois information of the domain, you registered it today. Your domain is registered but not yet delegated;
whois corporate.su | grep state
state: REGISTERED, NOT DELEGATED
The nic.ru FAQ actually states that it takes between 6 hours and several days for the delegation to actually take effect.
That being said, you seem to have a lot of NS entry in the zone file when I query one of your soon-to-be-delegated-and-authoritative name server.
You have a total of 9 NS entry.
dig +noall +answer @ns4.linode.com corporate.su ns
corporate.su. 86400 IN NS ns5.he.net.
corporate.su. 86400 IN NS d.ns.corporate.su.
corporate.su. 86400 IN NS d.ns.cns.su.
corporate.su. 86400 IN NS ns5.linode.com.
corporate.su. 86400 IN NS ns4.linode.com.
corporate.su. 86400 IN NS ns4.he.net.
corporate.su. 86400 IN NS ns2.linode.com.
corporate.su. 86400 IN NS ns2.he.net.
corporate.su. 86400 IN NS ns3.he.net.
You need to understand that all of these 9 Name Servers will be Authoritative Name Server. Meaning they will answer with the AA flag and will not do recursive query for corporate.su.
The five Name Server you included in your registrar form are the Delegated Name servers.
whois corporate.su | grep nserver
nserver: any.ns.cns.su.
nserver: d.ns.corporate.su.
nserver: lon.ns.cns.su.
nserver: ns2.he.net.
nserver: ns4.linode.com.
Of these, only d.ns.corporate.su will require glue records in the parent zone.
The reason being that in order to resolve any other Delegated Name Servers for your domain, the resolver doesn't need to know how to resolve your domain. (ie Circular dependencies).
The Delegated Name Servers should actually match the Authoritative Name Servers. So you should check your zone and remove NS entries that are not found in your registrars.
Or the other way around...but again...having 9 Delegate Name Servers and/or Authoritative Name Server is quite overkill.
Answer to comments;
what happens when there are name mismatches between the zones
If the mismatch is between two Authoritative Name Server, then you have quite a bit of an issue...normally, the SOA will prevail.
If my resolver detects conflict, it will send the query to the SOA (d.ns.cns.su in your case).
will not do recursive query for corporate.su" -- what do you mean by that? why would they have to? they're already authoritative, and have all the zone info
They should not, that's exactly my point. If two of them send conflicting zone information, they do so with the AA flag...I should take it for granted that what they send me is the correct information.
As for the Glue record, in your case, it's still not an issue...your domain is NOT delegated.
dig @a.dns.ripn.net d.ns.corporate.su
; <<>> DiG 9.8.1-P1 <<>> @a.dns.ripn.net d.ns.corporate.su
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35421
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;d.ns.corporate.su. IN A
;; AUTHORITY SECTION:
su. 3600 IN SOA a.dns.ripn.net. hostmaster.ripn.net. 650151100 86400 14400 2592000 3600
;; Query time: 150 msec
;; SERVER: 193.232.128.6#53(193.232.128.6)
;; WHEN: Wed Feb 13 21:30:42 2013
;; MSG SIZE rcvd: 96
You should notice 3 things here.
1- That answer was Authoritative (AA flag)
2- It did not offer NS records in the Authority Section
3- There is still no SOA for your zone
This means, that
1- Your domain does not have any Glue records of any kind for now.
2- None of the Authoritative Name Server for corporate.su are part of the delegation path.
Looking at your question, here are some corrections;
For example, if b.dns.ripn.net. of the parent zone su. says that my corporate.su. is controlled by server d.ns.corporate.su.
Well it's really not.
dig @b.dns.ripn.net corporate.su soa
No SOA, no delegation offered.
what if d.ns.corporate.su., from the parent zone, still resolves in the child zone, but to another IP address?
what if d.ns.corporate.su. does not even resolve on my authoritative servers, contrary to the glue at the parent zone?
I suggest you read the answer I provided for exactly that situation on meta.serverfault.com
But if the Glue is right, and your Zone is wrong...then you will have resolving issues.
If your Glue is wrong, but your zone is right, it's not as bad...not clean at all...but not as bad.
What if I have several such NS records in the parent zone of my domain servers that all authoritatively answer queries regarding my zone, but all or some of which have some kind of mismatch in the names of their records within the actual child zone that contradict the parent zone?
With DNS, your SOA is almighty. Glue records should match what the SOA is resolving your delegated name server to, not the other way around.
Best Answer
Every server that considers itself authoritative for a zone will have a SOA record for that zone. As such, the server for the child zone will serve its own SOA record.
If Server A considers itself authoritative for
example.com, it will have a SOA record forexample.com.If Server B has been configured with an authoritative zone named
custom-subdomain.example.com, that zone will contain a SOA record calledcustom-subdomain.example.com. It is not concerned with the SOA record forexample.comthat lives on Server A. It only considers itself authoritative forcustom-subdomain.example.com.Authoritative servers do not concern themselves with the records in the parent zone or communicate with its nameservers. That said, there is usually some administrative relevance to data in the parent zone that could have negative impacts on resolution for the child zone. (
NSor glue recordA/AAAAmismatches between the parent and child zone, broken chains of trust for DNSSEC signed zones, etc.)For further reading, you might want to take a look at RFC 2181 ยง 6 and its subsections. These cover the topic of zone cuts and the authority relationship between parent and child zones.