On Wed, Dec 30, 2020 at 4:39 AM libor.peltan <[email protected]> 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, AAAA, 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 AAAA 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 <[email protected]> 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: >> https://github.com/MikeBishop/dns-alt-svc [1]. The most recent >> working version of the document, open issues, etc. should all be >> available there. The authors (gratefully) accept pull requests. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02 >> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-02 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> DNSOP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ > DNSOP mailing [email protected]https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
