Re: [DNSOP] Bailiwick discussion for draft-ietf-dnsop-rfc8499bis

On Wed, Oct 6, 2021 at 12:05 PM Paul Wouters <paul@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
>