[DNSOP] I-D Action: draft-ietf-dnsop-svcb-httpssvc-03.txt
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 HTTPSSVC) Authors : Ben Schwartz Mike Bishop Erik Nygren Filename: draft-ietf-dnsop-svcb-httpssvc-03.txt Pages : 39 Date: 2020-06-11 Abstract: This document specifies the "SVCB" and "HTTPSSVC" DNS resource record types to facilitate the lookup of information needed to make connections for origin resources, such as for HTTPS URLs. SVCB records allow an origin to be served from multiple network locations, 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 HTTPSSVC DNS 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 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 /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. TO BE REMOVED: The specific name for this RR type is an open topic for discussion. "SVCB" and "HTTPSSVC" are meant as placeholders as they are easy to replace. Other names might include "B", "SRV2", "SVCHTTPS", "HTTPS", and "ALTSVC". 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-httpssvc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-03 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-httpssvc-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-httpssvc-03 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
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-00.txt
Hi. I've reviewed this draft and have one comment. In 4.3 there's no mention on the type of the RRs for the member zones. I was expecting to find an explicit declaration, just like there're for CLASS, TTL and label format; and not just only as part of the example. Regards, Hugo On 00:33 03/06, 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 : DNS Catalog Zones > Authors : Peter van Dijk > Libor Peltan > Ondrej Sury > Willem Toorop > Leo Vandewoestijne > Filename: draft-ietf-dnsop-dns-catalog-zones-00.txt > Pages : 11 > Date: 2020-06-03 > > Abstract: >This document describes a method for automatic DNS zone provisioning >among DNS primary and secondary nameservers by storing and >transferring the catalog of zones to be provisioned as one or more >regular DNS zones. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-dns-catalog-zones-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-catalog-zones-00 > > > 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 > signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02
On Thu, Jun 11, 2020 at 09:44:07AM +1000, Mark Andrews wrote: > > > > On 11 Jun 2020, at 08:44, Alessandro Ghedini wrote: > > > > On Mon, Apr 20, 2020 at 11:02:00PM -0400, Ben Schwartz wrote: > >> On Mon, Apr 20, 2020 at 9:25 PM Eric Orth >> 40google@dmarc.ietf.org> wrote: > >> > >> 8. Maybe I'm missing something, but the following sentence in Section > >> 64 seems > >> wrong: > >> > >> When SvcDomainName is ".", server operators SHOULD NOT include these > >> hints, > >> because they are unlikely to convey any performance benefit. > >> > >> My understanding is that ipv4hint and ipv6hint are the way to solve the > >> ESNI > >> multi-CDN problem, so let's say I have "www.example.net" that CNAMEs > >> to both > >> "cname.cdn-a.example" and "cname.cdn-b.example". A client queries both > >> A and > >> HTTPSVC concurrently for "www.example.net", and receives two answers > >> (the answer > >> to the A query points to CDN A, while the answer to HTTPSSVC points to > >> CDN B): > >> > >>www.xample.net 3600 IN CNAME cname.cdn-a.example > >>cname.cdn-a.example 3600 IN A 192.0.2.1 > >> > >> and > >> > >>www.xample.net 3600 IN CNAME cname.cdn-b.example > >>cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=h3 esniconfig="..." > >> > >> My understanding is that in this case the client could end up > >> connecting to > >> 192.0.2.1 (CDN A) with CDN B's ESNI config (or e.g. with the wrong > >> ALPN). So if > >> the server doesn't provide IP hints there would indeed be impact on > >> performance > >> because the client would just straight up fail to connect initially > >> (e.g. maybe > >> CDN A doesn't support HTTP/3, but CDN B's HTTPSSVC says the client can > >> use it, > >> or just because of the wrong ESNI config). > >> > >> Long story short, I don't think the text should discourage setting > >> ipv4hint and > >> ipv6hint here. I get that it's SHOULD NOT and not MUST NOT, but it's > >> pretty > >> confusing nevertheless. > >> > > > > I don't think the hints are intended for this problem. I think the > > general design idea is that A/ are the definitive address results > > for a > > given name, and clients can just optionally shortcut querying A/ if > > given hints. > > > > In your example, I believe the "." HTTPSSVC entry indicates that the > > A/ addresses for "cname.cdn-b.example" should be used, so it doesn't > > seem like there is a multi-CDN problem. The correct addresses for the > > correct CDN are used. > > > > But I think this might point out a potential problem with skipping hints > > for "." results. If the HTTPSSVC result passes through a CNAME, a > > non-HTTPSSVC-supporting recurssive will handle the CNAME, but not lookup > > A/ for the HTTPSSVC. > > > > I don't think this can happen. Any CNAME that affects HTTPSSVC will also > affect the corresponding A/ queries, which are always issued > simultaneously and to the same QNAME. > > >>> > >>> alessandro@'s case was for multiple CNAME's and a recursive with behavior > >>> that could follow those in different directions for the different > >>> requests. Not technically legal, but the more important question here is > >>> whether or not significant instances behave in this non-standard way. If > >>> they do, this will lead to a situation where hints would be beneficial > >>> even > >>> for "." records. > >>> > >> > >> Thanks for the explanation. I would prefer to warn against this, rather > >> than encourage more use of hints. When SvcDomainName is ".", I think not > >> including hints is going to perform better on average, even in the case of > >> multiple CNAMEs, because the split-CNAME cases should be very rare (due to > >> caching), but the hints add overhead to every response. They can also > >> impair load balancing if managed poorly. > > > > I had to step away from HTTPSSVC for a bit due to other priorities (hence > > the > > delay in responding), but I've been thinking about this some more and I see > > another potential case where the A/ and HTTPSSVC records might diverge. > > > > Given the following records: > > > >www.example.net 3600 IN A 192.0.2.1 > >www.example.net 3600 IN HTTPSSVC 1 . alpn=h3 echconfig="..." > > > > * At time T, user A queries a resolver for the www.example.net A record, so > > the > > resolver fetches it from the auth server and caches it. > > > > * At time T+5m, user B queries the same resolver for both A and HTTPSSVC > > records. The resolver serves the A record from cache, and fetches HTTPSSVC > > from the auth server (and caches it). > > > > * The administrator of www.example.net now decides to move the zone to a > > different provider (eith
[DNSOP] Fwd: Nomcom 2020-2021 Second Call For Volunteers
Dear DNSOP WG, The NomCom Chair has just send a second call for volunteers for the NomCom 2020-2021. Consider stepping forward and indicating that you are available for the 2020-2021 NomCom. Best regards, -- Benno Forwarded Message Subject: Nomcom 2020-2021 Second Call For Volunteers Date: Wed, 10 Jun 2020 11:54:56 -0700 From: NomCom Chair 2020 To: IETF Announcement List CC: i...@ietf.org This is the second sending of the call for volunteers for the 2020-2021 NomCom. I wanted to mention a few updates from the previous email (sent 2 weeks ago): - I've fixed the URL at the bottom of the email to point to https://datatracker.ietf.org/nomcom/2020/ instead of /2019/. This was a test to see if anyone was paying attention. Apparently, some people were. ;) - The IETF 108 registration form includes a checkbox that will let you volunteer. You can use this instead of emailing me, when you register for IETF 108. - I currently have 39 volunteers. Last year had 149. I need more volunteers! - The IETF NomCom appoints people to fill the open slots on the LLC, IETF Trust, the IAB, and the IESG. Ten voting members for the NomCom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the NomCom can be found in BCP 10 (RFC 8713). RFC 3797 details the selection algorithm. Special for this year (and only this year), we also have RFC 8788 (one-off update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer: Members of the IETF community must have attended at least three of the last five in-person IETF meetings in order to volunteer. The five meetings are the five most recent in-person meetings that ended prior to the date on which the solicitation for NomCom volunteers was submitted for distribution to the IETF community. Because no IETF 107 in-person meeting was held, for the 2020-2021 Nominating Committee those five meetings are IETFs 102 [Montreal, Canada; July 2018], 103 [Bangkok, Thailand; November 2018], 104 [Prague, Czech Republic; March 2019], 105 [Montreal, Canada; July 2019], and 106 [Singapore; November 2019]. Keep in mind that eligibility is based on in-person attendance at the five listed meetings. You can check your eligibility at: https://www.ietf.org/registration/nomcom.py. If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this NomCom will not be considered as a candidate for any of the positions that the 2020 - 2021 NomCom is responsible for filling. People commonly volunteer by ticking the box on IETF registration forms. The IETF 106 form did not ask whether people were willing to volunteer. IETF 107 did ask, but all those registrations were canceled. I have asked the Secretariat if it is possible to get the list if volunteers from canceled IETF 107 registrations. If that list is available, I will contact all who are verified as eligible. But given the uncertainty of this process, I would encourage people to volunteer directly (see the bottom of this email for instructions). Thank you for volunteering! The list of people and posts whose terms end with the March 2021 IETF meeting, and thus the positions for which this NomCom is responsible, are IETF Trust: Joel Halpern LLC: Maja Andjelkovic IAB: Jari Arkko Jeff Tantsura Mark Nottingham Stephen Farrell Wes Hardaker Zhenbin Li IESG: Alissa Cooper, IETF Chair/GEN AD Alvaro Retana, RTG AD Barry Leiba, ART AD Deborah Brungard, RTG AD Éric Vyncke, INT AD Magnus Westerlund, TSV AD Roman Danyliw, SEC AD Warren Kumari, OPS AD All appointments are for 2 years. The Routing area has 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas (that have more than one AD) have at least one continuing AD. The primary activity for this NomCom will begin in July 2020 and should be completed in January 2021. The NomCom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a NomCom member does require some time commitment it is also a very rewarding experience. As a member of the NomCom it is very important that you be willing and able to attend either videoconference or in-person meetings (which may not happen) during 14-20 November (IETF 109 - Bangkok) to conduct interviews. Videoconference attendance will be supported whether or not there are in-person meetings. Orientation and setting of the NomCom schedule will be done by videoconference during the wee
