NLnetLabs
Don't emit glue records while walking a zone.
Glue records are not actually part of the zone, they are just internal metadata used to help answer queries.
This causes unexpected additional records to be emitted by XFR out. See https://github.com/NLnetLabs/cascade/issues/222 for some context.
Note: Curretntly this PR targets the patches-for-nameshed-prototype branch but it should probably be merged into main, and then included in the patches branch afterwards (although we need to take whatever is good from the patches branch and get rid of it ASAP).
Hmm. I'm wondering about this. There can be explicitly defined glue records in the loaded zone, and there can be inferred glue records added to the zone tree to assist where explicit glue records were not defined. Perhaps explicit glue records are part of the zone and should also be emitted? Am I right? Does such a distinction exist in the code? Need to check.
Speaking in the context of Cascade: I think glue is part of the zone in the sense that it needs to end up at the public name servers (fetched via XFR from the publication server). Does this change affect that capability or is the change only relevant for signing?
Out-of-zone glue definitely needs to be included in an AXFR. This needs to be de-duplicated, however, since the same nameservers can appear multiple times in the zone.
(Which makes me wonder how registries deal with different clients adding different glue for the same name server.)
In the ideal case, a zone has glue only for nameservers that are in the child zone. In that case duplicates are not possible because the nameservers are at the registry level associated with zone. Registries that allow sibling glue do have all kind of interesting issues.
Speaking in the context of Cascade: I think glue is part of the zone in the sense that it needs to end up at the public name servers (fetched via XFR from the publication server). Does this change affect that capability or is the change only relevant for signing?
This doesn't affect glue being served correctly, it only prevents incorrect serving of the same A/AAAA records N times when it should be served once. See https://github.com/NLnetLabs/cascade/issues/222 for an example of what it prevents.