On 15:45 22/03, Ralf Weber wrote: > Moin! > > On 22 Mar 2022, at 14:43, Hugo Salgado wrote: > > On 14:02 22/03, Ralf Weber wrote: > >> However missing data might make it impossible for a name server to answer > >> with the correct (referral) glue data. > >> > >> And maybe add some encouragement or referral ;-) to work that has to be > >> done elsewhere. > >> > > > > The problem is with SIBLING glue records. The in-domain glues are of > > course required and included in the zone. > No, the problem with missing data is general. The (referral) glue records are > required, but it is possible to not supply them and break resolution. I think > in general a name server can only serve what it is given. So if you have a > zone example.com that has > > sub.example.com. IN NS ns.sub.example.com. > sub.example.com. IN NS ns.example.org. >
Yes, we agree that a zone must include the essential records for the resolution to work. What I am trying to say is that records that are not required, like some kind of siblings, should be optional even at the zone data level, and of course can't be included in the nameserver answer requirements. There are some registries that do not have siblings that are not in-domain of the referred domain. More information: https://mailarchive.ietf.org/arch/msg/dnsop/h0_6iEUIDWb4FyvrpDnDN1BRqBE/ > that is valid data even if you check in zone glues (and not all servers check > that on load and the ones that do usually just issue a warning). It is very > easy to create wrong zone data that will lead to resolution errors, and there > is nothing an authoritative name server can do once it has accepted that > data. I actually just loaded the above example in Akamai AuthServe, ISC bind > and NLNetLabs NSD and all of them loaded it, and I could also load them even > without ns.example.org line on all of them. > > So if we say that we don’t put requirements on data or data generators > (registries) than we have to spell out that even a server that follows this > draft/RFC might not be able to serve answers according to the draft/RFC when > the data is not correct. > Agree. Hugo > So long > -Ralf > ——- > Ralf Weber > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
