bailiwick rules clarification on the AUTHORITY and ADDITIONAL section
Solution 1:
I am not sure to really see your question.
ADDITIONAL is defined as optional (so the client is free to ignore that data and for security reasons it should indeed ignore it most of the time)... except when there is no other way to achieve something, which are glues.
But the problem is that ADDITIONAL aka glues are not covered by DNSSEC, hence not authenticated, so have to be handled with care.
Note that your case of adobe.net using nameservers under omtrdc.net is not the definition of "in-bailiwick". It would have been in-bailiwick if nameservers name were also under adobe.net. So your case is just what is called "internal nameservers" as the nameservers names are internal to the same registry as the domain name they are authoritative on.
[ side personal note to be honest: I feel this setup of domain A using nameservers under domain B whose nameservers are back under domain A to be really dangerous. Any error in A or B possibly disables resolution of both A and B; this is some kind of loops, and loops in the DNS should be avoided (or treated with care and appropriate mitigations and safeguards) ].
You can find a lot of great definitions in RFC 8499 about DNS terminology.
It has this for example:
Bailiwick: "In-bailiwick" is a modifier to describe a name server whose name is either a subdomain of or (rarely) the same as the origin of the zone that contains the delegation to the name server.
As for
Does it make sense or did I forget some important parts? You do great by showing DNS outputs of dig or similar but what is missing/vague is which nameserver you query for data, you should show that and study that to have a clear picture. In most cases of misunderstanding in the DNS I see it comes from a confusion between authoritative and recursive nameservers.
ADDITIONAL section is defined like that in RFC 1034:
Additional
Carries RRs which may be helpful in using the RRs in the other sections.
It then comes fully in §4.3.2 that describes the resolution algorithm:
Copy the NS RRs for the subzone into the authority section of the reply. Put whatever addresses are available into the additional section, using glue RRs if the addresses are not available from authoritative data or the cache. Go to step 4.
Back to RFC 8499 you do get further explanations:
A response that has only a referral contains an empty answer section. It contains the NS RRset for the referred-to zone in the Authority section. It may contain RRs that provide addresses in the additional section. The AA bit is clear.
and
In the case where the query matches an alias, and the server is not authoritative for the target of the alias but is authoritative for some name above the target of the alias, the resolution algorithm will produce a response that contains both the authoritative answer for the alias and a referral. Such a partial answer and referral response has data in the Answer section. It has the NS RRset for the referred-to zone in the Authority section. It may contain RRs that provide addresses in the additional section.
As for:
However, I have seen some implementation
Yes, the content of ADDITIONAL might change depending on which nameserver you query and how it is configured. See for example the minimal-responses option of Bind, documented at https://bind9.readthedocs.io/en/latest/reference.html stating: "This option controls the addition of records to the authority and additional sections of responses. Such records may be included in responses to be helpful to clients; for example, NS or MX records may have associated address records included in the additional section, obviating the need for a separate address lookup. However, adding these records to responses is not mandatory and requires additional database lookups, causing extra latency when marshalling responses." It has 4 possible values so many different behaviors online.
And finally for:
since the TLD server manages the net. zone, we can believe anything under net.
Yes, and no :-). Take for example the Verisign SiteFinder "experiment" in the past: you query any com authoritative nameservers for any non existing name and you got back an A record. Do you believe it or not?