If you do forwarding and plan to use DNSSEC signing and validation, things may break in this case.. I think there are some changes in newer NIOS versions that will work around this by adding the delegation anyway if it is authoritative for the parent, but I have not tested it.
As for RFCs go, in most cases (with the exception of the above note) it works but there are not usually the NS records that go along with sub-zone/delegation in the apex/parent so perhaps that's the RFC violation when forwarding? https://tools.ietf.org/html/rfc8499#section-7
By works, what I mean is that since it has a separate zone definition in the named.conf we get to skip that part of the recursion process and just ask that remote NS and expect it to handle any additional recursion that may be needed on behalf of the client NS -- well in the normal case.... In forward first, if the forwarding NS is not reachable then you fall back to recursion which depending on the configuration and layout of zones it may or may not work the way you expect.
I am curious as to the initial question’s comment around “(as your can’t delegate)”. Can you elaborate on this? There should be no issue delegating zones to non-infoblox DNS servers so I don’t understand the comment here… Is it that you must forward because you want the remote end to have sub-delegations of your delegation and expect the remote end to do the recursion instead (b/c firewall rules)?
