Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-02.txt

[Brian Dickson]

On Tue, Jan 5, 2021 at 2:29 PM Eric Orth  wrote:

> Besides future-proofing for potential changes, I think the current rule
> keeps us more flexible for handling obscure cornercases.  If there's any
> reasonable chance that some obscure usecase in the future might make it
> difficult for an authoritative to ensure only one alias is in place, it
> seems to me better for the only-one-alias rule to stay a SHOULD-level rule
> and keep the prescribed behavior for clients to reasonably handle it if
> broken.
>
> I wouldn't want to change to completely enforcing only-one-alias unless
> the authoritative implementers are confident that they will always be able
> to absolutely ensure that they are compliant.
>

Speaking only for one authoritative implementer (GoDaddy), I am confident
that we will always be able to absolutely ensure we are compliant.
We have the exact same authority enforcement for CNAME, one per owner name.

Given that this is new, greenfield stuff, I'd actually prefer a MUST rather
than a SHOULD. Any updates to accommodate new use cases SHOULD be new RFCs
that Update this RFC, that's the general way of progressing DNS standards,
IMHO.

As far as corner cases go, the only situation where two different RDATA
values could arise that I can think of, would be where the loosely coherent
nature of DNS comes into play (different authority servers with different
versions of the zone while the zone is in flux, or possibly a zone served
by authority servers operated by different parties.)

However, a resolver would either have one of those values in its cache (and
thus not query for a potentially different record), or not, in which case
only one authority should be queried at a time.  Thus the ability to obtain
multiple (different) RDATA values, if enforced on the authority server, is
non-existent.

If it isn't possible for more than one RDATA to be returned (atomically, in
a single query/response), I'd almost prefer removing the handling of "pick
one", and replace it with treating a response with multiple RDATA values as
a FORMERR (and try another authority, etc.)

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-02.txt

[Eric Orth]

Besides future-proofing for potential changes, I think the current rule
keeps us more flexible for handling obscure cornercases.  If there's any
reasonable chance that some obscure usecase in the future might make it
difficult for an authoritative to ensure only one alias is in place, it
seems to me better for the only-one-alias rule to stay a SHOULD-level rule
and keep the prescribed behavior for clients to reasonably handle it if
broken.

I wouldn't want to change to completely enforcing only-one-alias unless the
authoritative implementers are confident that they will always be able to
absolutely ensure that they are compliant.

On Tue, Jan 5, 2021 at 5:26 PM Ben Schwartz  wrote:

> On Tue, Jan 5, 2021 at 5:12 PM Paul Vixie  wrote:
>
>> a small matter.
>>
>> Ben Schwartz wrote on 2021-01-05 09:42:
>> >
>> >
>> > On Wed, Dec 30, 2020 at 4:39 AM libor.peltan > > > wrote:
>> >
>> > Hi Ben, all,
>> > i'd like to ask for some clarification of expected Authoritative
>> > server behaviour around Alias SVCB records:
>> >
>> > 1) when there are multiple Alias SVCB records for an owner name,
>> >
>> > As Section 2.4.2 says "SVCB RRSets SHOULD only have a single resource
>> > record in AliasMode".  So this "should" not happen.
>>
>> can you specify that if it does happen, the client behaviour should be
>> the same as if there are no matching records? otherwise clients will
>> have degrees of freedom, which i think would not end well.
>>
>
> The current draft says "If multiple are present, clients or recursive
> resolvers SHOULD pick one at random.".   I like that this leaves us the
> possibility of relaxing the single-Alias-RR rule in the future, if we find
> a use case for it.  Do you think this is not a suitable recommendation?
> ___
> 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] I-D Action: draft-ietf-dnsop-svcb-https-02.txt

[Paul Vixie]

a small matter.

Ben Schwartz wrote on 2021-01-05 09:42:
> 
> 
> On Wed, Dec 30, 2020 at 4:39 AM libor.peltan  > wrote:
> 
> Hi Ben, all,
> i'd like to ask for some clarification of expected Authoritative
> server behaviour around Alias SVCB records:
> 
> 1) when there are multiple Alias SVCB records for an owner name,
> 
> As Section 2.4.2 says "SVCB RRSets SHOULD only have a single resource
> record in AliasMode".  So this "should" not happen. 

can you specify that if it does happen, the client behaviour should be
the same as if there are no matching records? otherwise clients will
have degrees of freedom, which i think would not end well.

> 
> should the Authoritative server put targeted records into
> Additionals for all of them, or just pick one?
> 
> I think the answer is "whatever you would do with CNAME".  Just like
> CNAME, there really should only be one record in the RRSet. If you put
> more than one AliasMode record in the RRSet ... you're doing it wrong
> (but the resolver will still do something reasonable).

to be clear, for CNAME the referenced records are added to the answer
section, not as in this case the additional section.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-02.txt

[Eric Orth]

On Wed, Dec 30, 2020 at 4:39 AM libor.peltan  wrote:

> Hi Ben, all,
> i'd like to ask for some clarification of expected Authoritative server
> behaviour around Alias SVCB records:
>
> 1) when there are multiple Alias SVCB records for an owner name, should
> the Authoritative server put targeted records into Additionals for all of
> them, or just pick one?
> (Section 4.1 says "authoritative DNS servers SHOULD return A, , and
> SVCB records in the Additional Section for any in-bailiwick TargetNames",
> but section 2.4.2 will render it useless with "If multiple are present,
> clients or recursive resolvers SHOULD pick one at random." Which means,
> half (or most) of the additionals will get thrown away.)
>
I believe Additional records would still be considered in the RRSet, and
thus including them would run afoul of a SHOULD in 2.4.2: "SVCB RRSets
SHOULD only have a single resource record in AliasMode."

Whether the authoritative server picks one or does something to reject a
multi-alias config as invalid seems to be up to the server and out of scope
for this spec.

>
> 2) When the TargetName points to an in-bailiwick CNAME, should the
> autoritative server populate the CNAME chain inside the Additional section?
> It seems to me (fortunately :) ), that following such CNAME is only
> required for Recursive resolvers, however e.g. this zone will thus need
> three upstream queries to fetch it all:
> foo 3600 IN SVCB 0 bar
> bar 3600 IN CNAME baz
> baz 3600 IN SVCB 0 . alpn=...
> baz 3600 IN  1::2
>
> Thanks for your answers,
> Libor
>
> PS: is this e-mail thread the right place to ask for details clarification
> around SVCB features?
> Dne 16. 11. 20 v 7:43 Ben Schwartz napsal(a):
>
> For those who haven't looked at the diff, here are the changes since -01
>   *  Added a Privacy Considerations section
>   *  Adjusted resolution fallback description
>   *  Clarified status of SvcParams in AliasMode
>   *  Improved advice on zone structuring and use with Alt-Svc
>   *  Improved examples, including a new Multi-CDN example
>   *  Reorganized text on value-list parsing and SvcPriority
>   *  Improved phrasing and other editorial improvements throughout
>
> Notably, the normative changes are extremely limited compared to the
> previous draft.  This reflects the authors' view that this draft is
> stabilizing and should be ready for WGLC soon.
>
> Perhaps more important than the changes that were made are the changes
> that were discussed but have not been made:
> * We had an extensive discussion regarding the meaning of TargetName =
> ".", which is currently shorthand for the owner name.  Some suggested
> augmenting this to mean "owner name minus underscore prefix labels", and
> others suggested removing this special-case entirely.  (
> https://github.com/MikeBishop/dns-alt-svc/issues/252)
> * We received a suggestion to ban fallback to non-SVCB connection
> establishment (https://github.com/MikeBishop/dns-alt-svc/issues/256).
> (We clarified the fallback text but did not change the recommendation.)
> * The escaping of ALPNs that contain commas continues to be contentious.
> We received a suggestion to remove support for such ALPNs (
> https://github.com/MikeBishop/dns-alt-svc/issues/268).
>
> In each case, we think that the draft's current text still reflects the
> group's consensus and strikes the right balance.  If you disagree, please
> open a thread on the dnsop list and we will discuss it.
>
> We have one open issue that seems likely to result in a text change (
> https://github.com/MikeBishop/dns-alt-svc/issues/87).  This is a fine
> point regarding the HTTPS user experience if TLS fails, and we are
> soliciting input from experts on those topics.
>
> On Mon, Nov 2, 2020 at 4:44 PM  wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Domain Name System Operations WG of the
>> IETF.
>>
>> Title   : Service binding and parameter specification via
>> the DNS (DNS SVCB and HTTPS RRs)
>> Authors : Ben Schwartz
>>   Mike Bishop
>>   Erik Nygren
>> Filename: draft-ietf-dnsop-svcb-https-02.txt
>> Pages   : 45
>> Date: 2020-11-02
>>
>> Abstract:
>>This document specifies the "SVCB" and "HTTPS" DNS resource record
>>(RR) types to facilitate the lookup of information needed to make
>>connections to network services, such as for HTTPS origins.  SVCB
>>records allow a service to be provided from multiple alternative
>>endpoints, each with associated parameters (such as transport
>>protocol configuration and keys for encrypting the TLS ClientHello).
>>They also enable aliasing of apex domains, which is not possible with
>>CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
>>origins.  By providing more information to the client 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-02.txt

[libor.peltan]

Hi Ben, all,
i'd like to ask for some clarification of expected Authoritative server 
behaviour around Alias SVCB records:


1) when there are multiple Alias SVCB records for an owner name, should 
the Authoritative server put targeted records into Additionals for all 
of them, or just pick one?
(Section 4.1 says "authoritative DNS servers SHOULD return A, , and 
SVCB records in the Additional Section for any in-bailiwick 
TargetNames", but section 2.4.2 will render it useless with "If multiple 
are present, clients or recursive resolvers SHOULD pick one at random." 
Which means, half (or most) of the additionals will get thrown away.)


2) When the TargetName points to an in-bailiwick CNAME, should the 
autoritative server populate the CNAME chain inside the Additional 
section? It seems to me (fortunately :) ), that following such CNAME is 
only required for Recursive resolvers, however e.g. this zone will thus 
need three upstream queries to fetch it all:

foo 3600 IN SVCB 0 bar
bar 3600 IN CNAME baz
baz 3600 IN SVCB 0 . alpn=...
baz 3600 IN  1::2

Thanks for your answers,
Libor

PS: is this e-mail thread the right place to ask for details 
clarification around SVCB features?


Dne 16. 11. 20 v 7:43 Ben Schwartz napsal(a):

For those who haven't looked at the diff, here are the changes since -01
      *  Added a Privacy Considerations section
      *  Adjusted resolution fallback description
      *  Clarified status of SvcParams in AliasMode
      *  Improved advice on zone structuring and use with Alt-Svc
      *  Improved examples, including a new Multi-CDN example
      *  Reorganized text on value-list parsing and SvcPriority
      *  Improved phrasing and other editorial improvements throughout

Notably, the normative changes are extremely limited compared to the 
previous draft.  This reflects the authors' view that this draft is 
stabilizing and should be ready for WGLC soon.


Perhaps more important than the changes that were made are the changes 
that were discussed but have not been made:
* We had an extensive discussion regarding the meaning of TargetName = 
".", which is currently shorthand for the owner name.  Some suggested 
augmenting this to mean "owner name minus underscore prefix labels", 
and others suggested removing this special-case entirely.  
(https://github.com/MikeBishop/dns-alt-svc/issues/252 
)
* We received a suggestion to ban fallback to non-SVCB connection 
establishment (https://github.com/MikeBishop/dns-alt-svc/issues/256 
). (We clarified 
the fallback text but did not change the recommendation.)
* The escaping of ALPNs that contain commas continues to be 
contentious.  We received a suggestion to remove support for such 
ALPNs (https://github.com/MikeBishop/dns-alt-svc/issues/268 
).


In each case, we think that the draft's current text still reflects 
the group's consensus and strikes the right balance. If you disagree, 
please open a thread on the dnsop list and we will discuss it.


We have one open issue that seems likely to result in a text change 
(https://github.com/MikeBishop/dns-alt-svc/issues/87 
). This is a fine 
point regarding the HTTPS user experience if TLS fails, and we are 
soliciting input from experts on those topics.


On Mon, Nov 2, 2020 at 4:44 PM > wrote:



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain Name System Operations WG
of the IETF.

        Title           : Service binding and parameter
specification via the DNS (DNS SVCB and HTTPS RRs)
        Authors         : Ben Schwartz
                          Mike Bishop
                          Erik Nygren
        Filename        : draft-ietf-dnsop-svcb-https-02.txt
        Pages           : 45
        Date            : 2020-11-02

Abstract:
   This document specifies the "SVCB" and "HTTPS" DNS resource record
   (RR) types to facilitate the lookup of information needed to make
   connections to network services, such as for HTTPS origins.  SVCB
   records allow a service to be provided from multiple alternative
   endpoints, each with associated parameters (such as transport
   protocol configuration and keys for encrypting the TLS
ClientHello).
   They also enable aliasing of apex domains, which is not
possible with
   CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
   origins.  By providing more information to the client before it
   attempts to establish a connection, these records offer potential
   benefits to both performance and privacy.

   TO BE REMOVED: This document is being collaborated on in Github at: