All The call for adoption ended on monday and this has enough consensus to be adopted by the working group.
tim On Thu, May 21, 2020 at 9:36 PM Paul Vixie <p...@redbarn.org> wrote: > On Friday, 22 May 2020 00:31:34 UTC Masataka Ohta wrote: > > ... > > > > While I'm not against the clarification, the draft should mention > > that rfc1034 already states: > > > > To fix this problem, a zone contains "glue" RRs which are not > > part of the authoritative data, and are address RRs for the servers. > > These RRs are only necessary if the name server's name is "below" the > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > cut, and are only used as part of a referral response. > > ^^^^^^^^^ > > > > which means the glue RRs are necessary for a referral response. > > Though not very obvious, it logically means that they MUST be > > included as part of a referral response, because it is the only > > reason to make them necessary. > > i agree. this is why later versions of BIND would return referrals rather > than > answers when queried for these names, which were in-bailiwick but > below-zone. > by implication, they can only be retrieved from the delegating server as > part > of a referral, and they will be in the additional section not the answer > section even though they do match the qname. this distinction is also > necessary in the assignment of credibility levels in the downstream cache. > > -- > Paul > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
