On Wed, Oct 6, 2021 at 12:05 PM Paul Wouters <p...@nohats.ca> wrote: > On Wed, 6 Oct 2021, Paul Hoffman wrote: > > > Greetings again. I think that all of the issues from the WG on > draft-ietf-dnsop-rfc8499bis have been dealt with, except one significant > one. Almost a year ago, Tony Finch started a thread about 8499's > definitions of bailiwick and sibling glue. The thread is > > < > https://mailarchive.ietf.org/arch/msg/dnsop/5bKXkqzCyGE1NuUko9M6wXLD5bI/> > > < > https://mailarchive.ietf.org/arch/msg/dnsop/fAopdUTnVS2mDF71eiGsRdu9zco/> > > < > https://mailarchive.ietf.org/arch/msg/dnsop/PqH_WMhsP5zxRfjKD4gtmf6nw54/> > > > > The WG should come to agreement on this so that we can close out the > document. Please read these messages and comment here about changes you do > or don't want to be made to the current draft. > > The suggestion by Tony Finch: > > > * Sibling zones: two zones whose delegations are in the same > parent zone. > > * Sibling glue: addresses of nameservers that are in a sibling zone. > > I agree with the above part. But the next part I do not agree with: > > Sibling glue is usually the glue that the DNS would require for that > sibling zone, but in some cases the requirement lies elsewhere, for > example > > one.example. NS nsa.two.example > one.example. NS nsb.two.example > two.example. NS ns0.two.example > two.example. NS ns1.two.example > > The DNS protocol does not require sibling glue for the one.example > nameservers, though glue addresses might be required by .example > registry policy. >
It is perhaps worth referencing (informally?) the expired draft (version 05 from 2015): https://datatracker.ietf.org/doc/html/draft-koch-dns-glue-clarifications-05 I think it may be more appropriate to extract the important behavior expectations needed for interoperability. My understanding is as follows: - Whatever glue there is in the delegating zone is required (by RFCs?) to be served. - What glue is accepted or provided (or is required) may differ by parent policies or operator practices - The glue for sibling zones may or may not be needed for resolution. - Resolution may not be possible if glue that should have been present is not present - In-bailiwick for queries received by a server where the QNAME falls below a zone cut is any name at or beneath the parent zone, not the child zone. If the example TLD gets a query for foo.example, and the NS for foo.example falls under bar.example, both foo and bar are in-bailiwick names (at least that is my understanding, which was recently enlarged based on previous misunderstandings) Brian > > I find the talk about "in the DNS protocol" and pulling in "registry > policy" confusing and unneeded. > > As a seperate problem in the 2nd references email, I agree that the > term "in-bailiwick" probably changed meaning from "within this > delegation or below" to "the data related to this delegation". Eg > when processing additional records, "in-bailiwick" is interpreted > as "needed for completing DNS resolution for all NS entries in this > delegation" and could be RRs from other TLDs and their dependencies. > > For example, in this updated meaning, the A record for ns0.nohats.ca > is "in-bailiwick" to libreswan.org and a resolver could add the A > record for ns0.nohats.ca (and/or DNSKEY etc) to an answer for NS > of libreswan.org. This new use of "in-bailiwick" seems more common > too when thinking of resolver to stub and DNSSEC validation, eg > with chain-query and tls-dnssec-chain. Possible this dual use let > to the new term "in-domain" ? > > As for the third message quoted, I do not agree that "in-bailiwick is > a property of a nameserver". I believe it is a term related to the > NS/A records of the QNAME, not of a nameserver. > > 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
