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.)
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
<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
<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
<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
<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 <internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>> 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
<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/
<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://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02>
https://datatracker.ietf.org/doc/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
<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 <http://tools.ietf.org>.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
<ftp://ftp.ietf.org/internet-drafts/>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org <mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop
<https://www.ietf.org/mailman/listinfo/dnsop>
_______________________________________________
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
