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
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: 220.127.116.11#53(18.104.22.168)
;; 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.