Re: rfc1034 & bind 8.3.4 providing referrals as final answer to recursive clients

LV> Can you see the conflict?

There is no conflict. But I do see the well-known BIND 8
duplicate-resource-record-generation bug:

LV> ;; ANSWER SECTION:
LV> fake3.ladislav.name.ae. 3H IN A 10.3.3.3
LV> ;; ADDITIONAL SECTION:
LV> fake3.ladislav.name.ae. 3H IN A 10.3.3.3

I also see your misunderstanding of the fact that delegation is not
exclusive in the DNS. Answers about "fake3.ladislav.name.ae." can be
legitimately supplied by any one of no less than five sets of content
DNS servers:

1. the "." content DNS servers
2. the "ae." content DNS servers
3. the "name.ae." content DNS servers
4. the "ladislav.name.ae." content DNS servers
5. the "fake3.ladislav.name.ae." content DNS servers

You asked a "name.ae." content DNS server about
"fake3.ladislav.name.ae.". Since it knew the answer, because it has
data for that name in its database, it told that answer to you. It
also, helpfully, even though it was not actually required to, supplied
you with the delegation information for "ladislav.name.ae.", so that you
would know a "better" set of content DNS servers to query when it came
to your next lookup.

LV> the final authoritative servers don't have to exist at all,
LV> since they will never be queried to verify with.

They will be queried the next time that one wants to look up another,
different, datum for "fake3.ladislav.name.ae.".