FYI in Knot DNS, the implementation is at exactly the same state: an
existing merge request. For us, it's technically no issue if the
presentation/wire format changes during next few weeks.
I'm saying nothing about ideological consequences of such approach.
/Libor
Dne 19. 03. 21 v 0:05 Mark Andrews napsal(a):
On 19 Mar 2021, at 04:42, Tommy Pauly <tpauly=40apple....@dmarc.ietf.org> wrote:
On Mar 17, 2021, at 6:04 PM, Ben Schwartz <bemasc=40google....@dmarc.ietf.org>
wrote:
Release notes for this revision:
* Simplify the IANA instructions (pure First Come First Served)
* Recommend against publishing chains of >8 aliases
* Clarify requirements for using SVCB with a transport proxy
* Adjust guidance for Port Prefix Naming
* Minor editorial updates
I'm only aware of one outstanding issue: a proposal to change the name of the "echconfig" key to
"ech". This key corresponds to a value that is an "ECHConfigList", which is a collection of
"ECHConfig" structs, and some implementers have reported that the singular/plural name-value mismatch created
confusion. This issue is discussed in detail here: https://github.com/MikeBishop/dns-alt-svc/pull/299.
This name has no effect on queries, responses, or zone transfers, but it does appear in
zone files. Zone files will not be portable between implementations that use different
names. This is true whether we "burn" the current codepoint and allocate a new
one, or simply rename the current codepoint. However, using a new codepoint would allow
updated implementations to support both names, facilitating zone file portability in one
direction. It would also be possible to support the old name with special-case name
aliasing logic.
In my view, the temporary portability benefit is too small to justify the
permanent registry pollution of a deprecated codepoint, especially because ECH
itself is not yet finalized, and there are no deployments except for standards
development purposes. However, others have disagreed. We'll need to reach
consensus before making any changes here.
Personally, I’d prefer to see the name change, and not burn a codepoint, as
long as we’re not breaking any zone files.
I think the question is: does anyone have a zone that has actually deployed the
echconfig parameter? I see many responses with SVCB/HTTPS records, but none
with the echconfig in practice. If someone is aware of a production deployment
that can’t move, please speak up!
Tommy
It’s not so much is it in use or not. As I said this is a process issue. When
the code point was assigned the way it was the wire and presentation formats are
supposed to be *frozen* as that allows DNS developer to deploy code without
having
to worry about the specification changing underneath them.
For BIND we haven’t shipped code with SVBC / HTTPS code points yet even to the
point of parsing the records. We have merge request that has been tracking the
draft. I never felt the specification was stable enough to do that and
unfortunately
I was correct. ALPN has had its parsing changed, the same presentation format
produces
different wire formats. echconfig vs ech is minor compared to that.
I have not looked to see what other DNS vendors have done so far.
If we go ahead there needs to be a section that specified the differences in
parsing between the draft when the code point was issued and when the RFC is
published.
Mark
--Ben
On Wed, Mar 17, 2021 at 1:11 PM <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-04.txt
Pages : 48
Date : 2021-03-17
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-04
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-04
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-04
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
DNSOP@ietf.org
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
