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

2021-10-20 Thread Vladimír Čunát

On 12/10/2021, Tony Finch wrote:

I view the term "in-bailiwick" as no longer suitable for use in careful
writing because its meaning has become thorougly confused and muddled.


I agree that without further qualification the meaning of "in-bailiwick" 
isn't clear.  And I'm personally not convinced that usage of the word is 
restricted just to NS records returned in referrals.


--Vladimir

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2021-10-12 Thread Tony Finch
Paul Wouters  wrote:
>
> 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".

I view the term "in-bailiwick" as no longer suitable for use in careful
writing because its meaning has become thorougly confused and muddled.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Dover, Wight: Northwest 3 or 4 veering north or northeast 4 to 6,
becoming variable 3 or less later. Smooth or slight, occasionally
moderate at first in north Dover. Showers. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2021-10-06 Thread John Levine
It appears that Paul Wouters   said:
>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.

So far we agree (which when it's Paul and me, is really saying something.)

> Sibling glue is usually the glue that the DNS would require for that
> sibling zone, but in some cases the requirement lies elsewhere, ...

This is where we always go off the rails.  There seem to be two mutually
exclusive interpretations of sibling glue:

1 - it's a small and entirely optional twiddle to speed up or skip
recursing into the sibling zone

b - it's an essential part of the response because it's the only way to
resolve a reference loop.

I've already said my piece about which of these makes sense and which is a cruel
joke, but if we're going to talk about sibling glue at all, we need to decide
which one we mean.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


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

2021-10-06 Thread Brian Dickson
On Wed, Oct 6, 2021 at 12:05 PM Paul Wouters  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


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

2021-10-06 Thread Paul Wouters

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
  
  
  

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.

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


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

2021-10-06 Thread Tim Wicinski
Paul,

Thanks for bringing this up.  I feel this topic is also relevant to
the draft-ietf-dnsop-glue-is-not-optional draft currently being worked on.
While I am sure folks are aware of this,
this is more of a note that having the definitions clarified will help us
move this other draft forward.

thanks
tim

(and Tony - always thanks!)

On Wed, Oct 6, 2021 at 2:23 PM 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.
>
> --Paul Hoffman___
> 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