Thanks for the feedback. I'll add the DNAME clarification in the next version, as well as better explain the FQDN separation motivation.
The alt-svc ALPN values come from rfc7838 (Alt-Svc) and rfc7301 (ALPN). https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids (The "h3" = HTTP/3 over QUIC is not yet in the registry as it is still-in-progress. It was actually "hq" initially for Google QUIC. See https://tools.ietf.org/html/draft-ietf-quic-http-20#section-2.1 for some details from the active QUIC draft.) Erik On Mon, Jul 8, 2019 at 6:40 PM Brian Dickson <brian.peter.dick...@gmail.com> wrote: > Hi, Erik, > > One minor issue is that wherever CNAME is referenced, you probably want to > also include a reference to DNAME, including any implied or explicit > chaining of CNAMEs (which could be sequences of CNAME and/or DNAME modulo > their respective behavior.) > > It might be a little clearer if the list of alt-svc values (h2, h3, etc) > that can occur were to be listed in the document. In particular, the > association between h3 and QUIC is inferred but not explicitly called out > (at least not that I noticed.) > > You might also want to explain the motivation for keeping the FQDN > separate from the alt-svc parameters (to make it trivial to parse, and thus > to do DNS substitutions like CNAME/DNAME). It is there, just not as > up-front as it could be. > > Otherwise, I think many of us would very much love to see this > implemented, as much of ANAME is fundamentally incapable of meeting the > intended goals, which this does very nicely. > > Brian > > On Mon, Jul 8, 2019 at 2:20 PM Erik Nygren <erik+i...@nygren.org> wrote: > >> Ray, thanks for introducing this to dnsop! >> I've published a -03 with some of the feedback received so far: >> https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-03 >> >> For DNSOP folks, and ANAME proponents in-particular, >> I/we are especially interested in understanding if this would address >> enough of the customer use-cases driving ANAME were major >> browsers to implement support for HTTPSSVC, or would any >> limitations here cause problems there? >> >> I think the ideal would be for this to simultaneously solve >> enough of the ANAME use-cases (to ideally obviate the need for ANAME) >> and to also solve the other problems that clients are interested in >> solving >> (ESNI via DNS, H/3 via DNS, etc) to get this broadly deployed at least >> for the "web browser" use-case. >> >> Most significant changes from -01 to -03 based on feedback: >> * Remove the redundant length fields from the wire format. >> * Define a SvcDomainName of "." for SvcRecordType=1 as being the >> HTTPSSVC RRNAME. >> * Switch from 302 to 307 redirect for HSTS equivalent. >> but there also some added examples and other clarifications based on >> feedback received. >> >> While this is still an individual draft, we have been tracking it here: >> https://github.com/MikeBishop/dns-alt-svc >> but as always, commentary on the IETF lists is generally preferable. >> >> Erik >> >> >> >> >> On Mon, Jul 8, 2019 at 5:01 AM Ray Bellis <r...@bellis.me.uk> wrote: >> >>> For those not paying attention to the HTTP-bis working group, this DNS >>> RR was proposed there last week. >>> >>> It appears to subsume the ALT-SVC proposal and also covers the use case >>> I had in mind with my HTTP Record draft (i.e. CNAME at the apex). >>> >>> Given that it has someone from at least major browser vendor supporting >>> it there's some hope that this will actually be implemented by them. It >>> therefore seems my draft is probably no longer required. Hopefully >>> ANAME will follow it the same way ;-) >>> >>> Ray >>> >>> -------- Forwarded Message -------- >>> Subject: HTTPSSVC record draft >>> Resent-Date: Wed, 03 Jul 2019 18:46:25 +0000 >>> Resent-From: ietf-http...@w3.org >>> Date: Wed, 3 Jul 2019 14:45:47 -0400 >>> From: Erik Nygren <erik+i...@nygren.org> >>> To: ietf-http...@w3.org Group <ietf-http...@w3.org>, Mike Bishop >>> <mbis...@evequefou.be>, Erik Nygren <erik+i...@nygren.org>, Benjamin >>> Schwartz <bem...@google.com>, Erik Nygren - Work <nyg...@akamai.com> >>> >>> >>> >>> >>> Ben, Mike, and I have submitted the first version of a proposal for an >>> "HTTPSSVC" DNS record. >>> >>> TL;DR: This attempts to address a number of problems (ESNI, QUIC >>> bootstrapping, HTTP-to-HTTPS redirection via DNS, SRV-equivalent for >>> HTTP, etc) in a holistic manner through a new extensible DNS record, >>> rather than in a piecemeal fashion. It is based on some previous >>> proposals such as "Alt-Svc in the DNS" and "Service Bindings" but takes >>> into account feedback received in DNSOP and elsewhere. >>> >>> Feedback is most welcome and we're looking forward to discussing with >>> people in Montreal. >>> >>> Draft link: >>> >>> https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-01 >>> >>> >>> >>> From the abstract: >>> >>> This document specifies an "HTTPSSVC" DNS resource record type to >>> facilitate the lookup of information needed to make connections for >>> HTTPS URIs. The HTTPSSVC DNS RR mechanism allows an HTTPS origin >>> hostname to be served from multiple network services, each with >>> associated parameters (such as transport protocol and keying material >>> for encrypting TLS SNI). It also provides a solution for the inability >>> of the DNS to allow a CNAME to be placed at the apex of a domain name. >>> Finally, it provides a way to indicate that the origin supports HTTPS >>> without having to resort to redirects, allowing clients to remove HTTP >>> from the bootstrapping process. >>> >>> By allowing this information to be bootstrapped in the DNS, it allows >>> for clients to learn of alternative services before their first contact >>> with the origin. This arrangement offers potential benefits to both >>> performance and privacy. >>> >>> This proposal is inspired by and based on recent DNS usage proposals >>> such as ALTSVC, ANAME, and ESNIKEYS (as well as long standing desires to >>> have SRV or a functional equivalent implemented for HTTP). These >>> proposals each provide an important function but are potentially >>> incompatible with each other, such as when an origin is load-balanced >>> across multiple hosting providers (multi-CDN). Furthermore, these each >>> add potential cases for adding additional record lookups in-addition to >>> AAAA/A lookups. This design attempts to provide a unified framework >>> that encompasses the key functionality of these proposals, as well as >>> providing some extensibility for addressing similar future challenges. >>> >>> -- >>> >>> Some likely FAQs (with some others listed in an appendix): >>> >>> Q: Why this is HTTP-specific? >>> A: This is because every protocol has different bootstrap requirements. >>> This draft is concerned with improving the efficiency and security of >>> bootstrapping HTTPS connections. This proposal does offer room for >>> non-HTTPS protocols, but the nature of DNS requires underscore prefixing >>> to support protocol-keyed answers within a single RRTYPE. It's also >>> unlikely that a single RR format would be the ideal bootstrap mechanism >>> for every protocol, and there's no reason that multiple protocols should >>> have to share an RRTYPE. >>> Q: Why is ESNI addressed directly? >>> A: This helps make a major motivation of this draft more clear. >>> Splitting out those sections to a separate-but-associated "alt-svc >>> attribute for ESNI keys" draft might make sense, but keeping it here >>> helps work through some of the issues together. >>> >>> Q: Why does this try to address the HSTS case? >>> A: This is a unique opportunity to fix HTTPS bootstrap and avoid >>> providing insecure defaults. We'd originally proposed a separate >>> Alt-Svc attribute to indicate hsts-style behavior, but then realized >>> that it would make sense to push on that as the default here. >>> >>> Best, Erik >>> >>> _______________________________________________ >>> 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
