TL;DR: Where you will go is non-deterministic (depends on which resolver you will use) and no RFC clearly states that, but there are various hints described below.
First, do not obfuscate badly. The 3 IP addresses you use exists, and at least two of them today are heavily used. You gain nothing and create a lot of harm by using them. There is one RFC (5737) given advices on this, but in short use 192.0.2.0/24 for such needs.
Also your terminology is slightly wrong: glues are at parent of a given delegation cut, and that parent is often just called the registry at least when you are dealing close to the top of the tree. Note that the registrar here may play no role at all, except that if it is also the DNS hosting company but that is a separate job technically.
Then, there is no RFC that clearly state this policy and it is still today a subject of hot discussions. It is referenced as "child centric" vs "parent centric" to decide, when the "same" content is on both side of a zone cut, which one should be taken into account.
Of course, what the RFCs say, is that both content should be the same and hence the point be moot. However, and it is the same for NS records, it does indeed happen that there are discrepancies, which are often a sign of misconfiguration that yields to problem from a least extensive delay in resolution to more deep breakage.
See §4.2.2 of RFC 1034 on this:
As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone. The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.
The RFCs may lightly hint at the fact that the child should be authoritative because normally everything that is in the parent is just there to help find the child and communicate with it, so in case of differences, parent data should be discarded. This however has one consequence: one resolver doing that has to still periodically ask the parent again just to make sure the delegation didn't change, otherwise the child would stick forever.
Why we can interpret that from the RFCs: because DNS packets have section, there is one section could "ANSWER" and one could "ADDITIONAL". When a parent gives back a NS record set with details on glues, the glues are in "ADDITIONAL" because they are not considered part of the answer, they are just there to help resolution. Moreover, with DNSSEC, glues (and NS records in fact at parent side) are not signed, hinting that they are "less" authoritative.
For example, this document at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-securing_dns_traffic_with_dnssec clearly states:
In a DNSSEC signed zone, each resource record set (RRset) has a corresponding RRSIG resource record. Note that records used for delegation to a child zone (NS and glue records) are not signed; these records appear in the child zone and are signed there.
There is also another hint at that in §5.4.1 of RFC 2181, which I quote partially here:
When considering whether to accept an RRSet in a reply, or retain an
RRSet already in its cache instead, a server should consider the
relative likely trustworthiness of the various data.
[..]
Trustworthiness shall be, in order from most to least:
[..]
- The authoritative data included in the answer section of an
authoritative reply.
[..]
- Glue from a primary zone, or glue from a zone transfer,
[..]
- Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.
Note that on this abridged list, only first point can come from the child, the next 2 are coming from the parent. Hence by reading this list you normally would infer that resolvers should be child centric (and the rest of the section discuss glues further and the fact that DNSSEC signed data should be considered more trustworthy which again puts the child over the parent). But exactly because it adds other complexities, not all recursive nameservers are child centric.
So some resolvers are parent centric instead in cases like that.
There are various studies on the subject, such as:
- https://www.dns-oarc.net/files/workshop-201103/ICANN-SF-Looking-at-DNS-traces.pdf which further discuss the difference between child centric and child sticky (never asking the parent again) showing that most resolvers are child centric or child sticky... except at least Google Public DNS that is parent-centric
- https://conferences.sigcomm.org/imc/2019/presentations/p10.pdf discusses how the TTL is chosen if different between parent and child; showing that in their case most resolvers are child-centric (as expected)
- https://annasperotto.org/publication/papers/2020/sommese-pam-2020.pdf a recent full research paper; among the conclusions: "This is the first study that shows, across the .com, .net and org zones (50% of the DNS namespace), that roughly 8% (13M) domains do not conform to that. " and "Finally, we also recommend that resolver vendors conform to the authoritative information ranking in RFC2181 (taking into account the recommendations to mitigate the Kaminsky attack as specified in RFC5452), and when possible, to explicitl yask for the child’s NS records, similarly to what is done in DNSSEC, where signed records are only available at the child"
Also, the current canonical document on DNS terminology, RFC 8499, sadely avoids the subject, but you can find the subject touched in a previous email discussion starting at https://mailarchive.ietf.org/arch/msg/dnsop/fXmzHFzh153OO01hA5Oq8-T-fO8/ ; this archived proposal at https://www.ietf.org/archive/id/draft-huque-dnsop-ns-revalidation-01.txt discusses the problem of having to revalidate the NS records at parent when you are operating as child-centric.
To show how much debate there still is, or more precisely the problem of zone cuts and data being on both sides, right now at least these documents in the IETF touch on the subject, each proposing new records or new ways to handle that cut:
But exactly because the point is not clear, and everyone chooses one case or the other you fell into a dark spot of the DNS where the outcome is not deterministic depending on who you ask. Said differently: you should avoid at all costs situations like that.
